Jiri Lundak

Archive for the ‘Team’ Category

Courageously “Kicking Dead Weight”

In Agile, Leadership, Scrum Agile, Team, Values on March 31, 2013 at 2:22 am

This is the first installment of a small series on trimming away fat, that inhibits organizations in realizing full potential, when trying to adopt Agile ways.

First let me make one thing clear: this is also about one value, that often seems to fall by the wayside. I am talking about courage. People tend to minimize the impact agility has on their organization. This is a natural reaction, because we have all the inclination to self-protect, our position, our job, etc. On the other hand we – as Agile change agents – want to maximize the impact of agility in the organization. So, to take action, we must go against our natural inclination. And this is really hard… but usually worth the effort.

“Kicking dead weight” or getting rid of processes, ceremonies, activities and even people, that do not contribute to our goals, is very hard to do, but extremely necessary. It might even be very urgent in your project.

Years of experience show me, that many organizations (especially larger ones) have lost control of their appetite (for “resources”, for regulation and for simultaneously ongoing projects). How comes?

They take on more projects than they can handle. They add external people, because they have not enough themselves. They are not able to control this much people, so they add rules. They have not enough people that check compliance with the rules, so they add more people, making projects heavier and more complex. Then the cycle starts again.

Once people are hired, processes are installed and rules are established, getting rid of them is seen as daunting at best and impossible in all other cases. Why is this so hard? Because many people contribute to the problem (sometimes unknowingly) and only few, if any, try to solve it. Many people joining the company just take existing rules and behaviors as unchangeable company policy and have usually not the courage and/or time to act on it.

Now, let us focus on the people problem. How can we get on top of it?

Here are some basic principles, that come to mind:

  • Think twice about who you hire: First think “Do we really need to fill that position?”, then “Can we just shift forces internally?”, and if you really need to hire somebody “Has this person really the skills to help us?”. Choose wisely with highest possible standards. Put candidates to the test. Do not just let HR decide. Make your teams choose the people they want to work with.
  • If possible, never hire external people: If possible to not overcommit in the number of project you staff can handle. When hiring external experts, you often end up devaluating your own people. The simply do not get any chance to build up new skills. This is a death spiral, leading to even more dependency on exteral help. And what is worse, you even loose the ability to judge the goodness of the external people's work.
  • If you have to hire external experts: Do not create a Troian horse, where the providing company can send you anybody they like. Treat external people like your internal ones. Evaluate them with the same rigour and diligence as you would when hiring for a top notch permanent position. When hiring them, do it only for a limited period of time. Make it paramount, that they teach your own people how to do the job well. It is better to give the complete project outside or buying an off-the-shelf product, than having a pseudo-internal project.
  • People just do not cut it: If you have people on your team, that do not solve problems, but – on the contrary – often contribute to create them, then do not hesitate to try to help them. If they live not up to the chance, remove them. How do you know someone, who does not contribute? If you collaborate closely with your team, you will know. Else ask the team. They know the good people. External people, that are of no help, should be immediately removed.

I know this might sound hard, but it is the only way to improve things. But remember: it takes courage. You need courage to go counter useless policies within you company. You need courage to face a person, that you need to correct or even remove.

In the next installment we will talk about trimming processes.

 

Knowing when to Leave

In Agile Development, Career, Job, Team, Values on January 23, 2013 at 1:02 am

It was a long time with the same company. I nearly became part of the inventory. It was an awesome journey from a disorganized bunch of people, with no real concept on how to produce good quality software, that preferred to depend on external knowledge for managing projects, to a lean and mean software company, that produces 17 releases a year and had more than 135 releases go live during these 9 years.

We made a dent in the universe, for how long it lasted. We introduced Agile development practices and looked for talented people to join us. Self-directed people, good collaborators and able software engineers. We were trying to hire only the best of candidates (we hired only every tenth maybe).

This saved the company from failing. We were successful again.

And now I am leaving. Why that? It is not because of bad technological choices, it is not because of bad customer relationships and it is not because of a hostile business environment. These are problems of daily business life. We can cope with that.

The discussions of the last month have worn me down. I was not able to convince my peers, that we were drifting away from values we all valued.

So here we are. Our people were breathing the spirit of agility. They embodied self-organizing principles. They valued to be included in the decision making process. Sure not everything was rosy. But we never shied back from correcting ourselves. Unfortunately I was not able to counter the building up of positions, of creeping distrust. Though I tried to improve things I miserably failed.

But now there is hope again. People are talking again with each other, about their values, their hopes and their expectations for a better future. That is a good sign. But I am not part of the solution anymore and this makes me very sad.

In this dark personal moment, there remains one wonderful and encouraging thing deeply impressed in my memory: the pure and genuine solidarity with Agile principles, that most of my colleagues have shown, by underlining the value and positive effect the Agile way of doing things had in their lives.

Especially one colleague brought me joy and encouragement. We never talked personally about agility and its benefits in depth, he always seamed not to care much, just doing his thing, taking never any sides in 12 years. And now this… a long email, showing his personal benefits he got from the Agile way and how much he cared. This was very moving for me personally. Agile has reached the hearts and minds of people living it from day to day. This I call a movement!

So now, that I must go, I leave behind people, who for themselves have seen the light, who know what they want and know how to take care of themselves. So my wish goes out to them: be courageous, do not give in and continue to do good work! You know who you are.

 

Closeness

In Collaboration, Leadership, Management, Team, Values on December 18, 2012 at 8:27 am

Here are some thoughts on closeness in a collaborative setting, be it from a managerial perspective, as well as from a purely co-working perspective:

Being very close has surely some downsides:

  • You might have to cope with the intricacies of a quirky person.
  • You see often very clearly the defects of personality in the person you are collaborating with.
  • You may lack some distance to the task at hand.

On the other hand there are a lot of positive aspects to being close to each other:

  • Trust increases between people collaborating closely.
  • You often understand why a person does what she does.
  • You get immediate feedback (emotional, unfiltered) to what you say and do. You can use this feedback wisely.
  • You can influence “in place” the situation, instead of arriving just after the fact.
  • You will know your collaborators so well, you will not need a one-on-one performance appraisal session at the end of the year (if not mandated by others).

For example management decisions communicated via email are more impersonal and open to interpretation than face to face communication, where reasons for a decision can be explained directly. Better yet would be to collaboratively reaching a conclusion. In this case the co-creation of a solution creates a bond of trust and buy-in, that is not possible otherwise.

In the last 10 years this kind of closeness has been practiced in software engineering (think pair programming, co-location of teams and the rise of instant messaging). Unfortunately it did not quite arrive in the managerial sphere above it. There are exceptional leaders practicing it naturally, but most traditionally trained managers are still “managing in a bubble”, disconnected and far away from the people working for them.

 

The Company I Want To Work For

In Team on November 30, 2011 at 8:45 am

As someone, that is working now for over 26 years in software business, I must admit I have still not found the ideal job, though I have already worked for five companies. But that does not mean, I have given up yet.

As somebody, that takes things never lightly and tries continually to improve his surroundings, I have climbed up the ladder of so-called “success”. I went a long way from being a “Junior Programmer” to becoming “Head of Development” in a small company of about 30 people.

Over the years a picture about the ideal workplace has formed in my mind, becoming continuously clearer in recent years. This not only because of my personal work experiences, but also because of all the stories I have heard of colleagues, friends and customers I coach. Sure enough there is also a big influence by two other factors, I would like to mention: First my upbringing in a open, critically thinking Christian family, with strong moral, social and altruistic values. Second the lecture of many courageous, non-conformist authors, that did not hold back with their radical ideas and that often have themselves put them into practice.

Ok, it might also have to do with my own character. I have never chosen the easy ways. I was always asking lots of why’s. And my perseverance – some might call it stubbornness – made me go to the roots of ideas, instead of just repeating slogans. An imminent curiosity pushed me – and does still – to fish in other fields than software engineering for ideas and connections to things I already know.

So, enough of this longish intro. How is the place like, I would enjoy working in?

  • It is filled with people, passionate about what they do.
  • It has no fixed hierarchy, but people take turns as needed in leading others, in the areas they are skilled in and have passion about.
  • It educates its staff in all things they care about and that have to be done, distributing at least basic knowledge to all employees.
  • It welcomes ideas to problems at hand from all employees.
  • It hires the best possible people, gives them all information needed to make informed choices of their own, without formal supervision, and trusts them to act in the company’s very interest.
  • It creates a save-to-fail environment, where collective ownership is taken, of successes AND failures.
  • It makes working fun again. These must not be mutually exclusive.
  • It tries to minimize administrative overhead to a minimum, to help people do really useful stuff, they care about.
  • It does not succumb to pure shareholder interests.

Does this seam to be your typical laundry list of points for the ideal company? That might be. I am sure many others out there have come up with similar wishes and add even some more.

QCon Day 5

In Agile, Team on March 17, 2007 at 11:44 am

As I had to fly back home on Friday afternoon, the report on Friday’s sessions is quite short. Although I wanted attend the planned Open Space on “Reflecting on your Agile journey – How do we reach Mastery?” led by Deborah Hardman and Diana Larsen, I just did not make it. This mainly, because in parallel there was still an Agile track going, with too much of good content. So I had to sacrifice something. 😩

I decided to hear what my friend Joseph Pelrine had to say about “When Agile Hits The Wall – Dealing with the organizational challanges of Agile adoption”. Joseph’s talk was video-taped, so I hope it will be available as Video-Stream somewhere from the conference website soon. At least they promised to make the material available.

In his entertaining and metaphorically rich manner Joseph showed why there are fundamental clashes in an organization, when some part of it (like a team) tries to adopt Agile values and practices. Sometimes all goes well within one team, but as soon as the team tries to reach outside its zone of influence things seldom work out as expected. Actually even resistence and suppression can be the response.

Joseph compared going to fast with Agile adoption with running downhill – if you let go, you accelerate and accelerate until you go to fast and stumble over your own feet – a nice metaphor. Your organization might well feel fear and threat and build “antibodies”.

So the first step for resolving anything is to know the problem space and to capture the force that are at work within the organisation. Usually there is a clash in the unterstanding of “cause and effect”. Often management and an Agile team live in two different worlds. Management often remains stuck in a Newtonian world view, while the Agile team embraces a Complexity Science based approach. These are not compatible with each other.

The Newtonian point of view is that cause and effect are directly linked and can be traced and linked together in advance and with some effort can lead to the predication how a system will behave in the future.

The Agile team instead operates in the Complex realm. In this quadrant there is no direct link between an effect and its cause(s) observable, let it be predictable. Instead things can be only judged in retrospect, knowing how things evolved (this is called “retrospective coherence”).

In this realm we can not know in advance what will influence our system and how the agents within the system will react. Such a system we usually find, where people are involved, because people do not act deterministically. To many factors to influence us.

This is also, as Joseph stated, why a simple Inspect -> Adapt loop does not work. Joseph pointed out, that we need first to act, before in a complex environment something happens and any inspection is possible. So he extended the loop to: Apply -> Inspect -> Adapt.


Technorati :
Del.icio.us :
Ice Rocket :

A Different Team Event

In Agile Development, Team on February 11, 2007 at 3:02 am

Sometimes you make a move out of desperation…and it makes a whole lot of difference.
No not in the spectacular way, as to save the world or make enemies become friends. But I think it still can make a difference by altering the collective and individual perception a bit.

Well you do not understand what I am talking about? So I have to begin from the start. Here is the story:

About six weeks ago a colleague of mine and myself were quite depressed. It seamed as if we – as a development team (togther with our other 20 or so developers and testers) – did not make any progress, when it comes to the quality of our code. Sometimes we just do not get it as developers. We write code, without thinking too much about it. Or we concentrate so much on the solution to our software problem at hand, that we forget about good design, refactoring, test-first development and any other good coding practice.

Even organizing inhouse workshops with well-known patterns guru’s as Peter Sommerland (of Pattern-Oriented Software Architecture: A System of Patterns fame), did not contribute to more awareness about bad code and how to avoid it. Instead in these workshops (although organized as interactively as possible), some people always were passive, maybe even thinking: “What a waste of time! I need to do some important work and we are wasting it here…”.

So as already said, we were heavily depressed. While contemplating the situation an idea sprang to my mind: We would make everybody do something. As many of us as possible should become involved. We decided to organize an event: Done by us developers, for us developers.

Löpa HÀck NÀit Flyer

Invited were all developers and testers (people having to do directly with our code) to participate in what we declared to be the first ‘Löpa HĂ€ck NĂ€it’ (in Swiss-German meaning the first Löpa Hack Night, Löpa being the short name of our small sofware company Löwenfels Partner AG in Lucerne, Switzerland).

We would start at 6 pm with a snack and then hack away until 4 am in the morning. We had 16 people participate. We formed four teams, all in one ‘War Room‘ and would do a coding competition. At 22 pm we would have dinner (one of our colleagues and his wife cared for), then we would see a geeky film together, before continue coding. In the end one additional discipline was to participate in a game competition with the new WII console until 5 am in the morning. On a side-track we organized some music and two girls from the nearby Lucerne School of Arts and Design to paint a big wall sized Löpa HĂ€ck NĂ€it Grafitto on an office wall incorporating ideas of many of the team members.

First I was quite sceptic about the outcome of the event. I expected some people to rebell against the idea. But having some of the more critic people on the organizing comitee helped a lot. From what I can say now, two days after the event, it was a full success. And something has build up I would call team spirit. We had made teams with people that did not know themselves this well, because they usually (in daily life) worked in different teams. But the teams were quite balanced and so the competition was really working out.

It was the first time we worked really in an Agile way, all people working together on the same problem at once. We worked on two problems we had in our real projects: How to write unit tests to check for equality of PDF documents and how to optimize PDF rendering speed at least by a factor of two.

Incredibly enough we were able to do better than we expected. Although the first problem – testing for equality of PDF documents – to prevent alterations, when refactoring for speed, proved to be more difficult to resolve, we all learned a lot about the PDF-format than we ever imagined to know. Interesting in this part of the competition was also to observe, that many team-members were happy to exchange ideas even with the competing teams. In the end we managed to find an approach (with the help of our PDF expert Beat) to write repeatable tests.

The second problem – optimizing the existing code for speed – proved also interesting. All four teams managed not only to double rendering speed, but all managed to increase it by at least 60 percent. The best team topped at 65 percent. When I think that we need to render about 100’000 documents a night, I would say we did very well (and all in about two and a half hours!).

I just heard that evening one voice say, that this was not the most efficient way to use our resources. But I thing that person was wrong. We should work like that all day long. What was our net profit of this night? I would say for myself:

  • Better teamwork
  • Better understanding of a forgein domain for many team members
  • Knowledge transfer between people with different skills
  • Solutions to two hairy problems, we were grappling with
  • Code that was tested and worked (with only some minor rework the other day)
  • Self-organization
  • Reaching of a common goal

…and besides all this: Lots of fun!

I am looking forward to the next Löpa HÀck NÀit!