Self-managing and self-organization in software development teams

Ed Gibbs in his blog posts a comment on self-managing teams that deserves some additions.
He mentions that "[he does] have fears that some stuff gets left behind by making everyone a developer [self-managing team]".

He specifically mentions that

Most organizations just have a lot of administrative stuff that someone has to take care of to keep everything rolling along. And someone has to focus on things beyond the project at hand. In a team of developers [self-managing team] who does one-on-ones, fills out the purchase orders for a new build box, or makes sure time sheets get signed off and approved?

I would beg to differ on these statements. The point with self managing teams is not to change the process of defining a leader (which is nominated by management in non-self managing teams), the point of "self managing teams and organizations" is to do away with the need to name a leader all together, the team is it's own manager, which in practice means that everybody is a manager, not just that everybody is a developer.

Everybody is a manager

What I mean to say with this statement is that everyone in the team has responsibility over the organizational integration of the team, not just "a manager" (named by the team or not). If you need to buy hardware the team is responsible for buying that hardware (or starting the purchasing process, depending where you work). If a room needs to be designed then the team designs that room, not management. If someone needs to go to higher management with some proposal/request, then the teams define that proposal/request but they can name one or two (or more) people that go there and represent the team.

The goal with self-managing teams is not to make everybody a developer, it is to make the team fully responsible for it's results, and this includes tasks that would normally be assigned to a manager.

The Evaluation pitfall

There is one problem however with the current traditional "MBA/old school" style of evaluating performance in self-managing teams: MBA's and old schoold managers forget that people are intelligent enough to evaluate themselves! In a case described in the book "Maverick!", Ricardo Semler states that they actually asked people to name their salary. What happened? Most people actually asked for a salary lower than what management was ready to pay (in some cases they actually had to say "no, you deserve more!"). Those that asked for crazy salaries (very few) eventually left the company anyway so problem solved.

Of course a self-managing team needs to be able to self-evaluate also (I have some experience with that which I could share in another post). Management needs to take the leap of faith if they are to rip all the benefits from self-managing, self-organizing teams.


Find this story interesting? Let others know: Digg it!

The Feedback Cycle is king!

Agile software development methods are organized around an important concept: the feedback loop.

The idea is that whatever you do - coding, attending a meeting, doing a full project - you must have a way to gather feedback about what you did so that you can analyze it and improve based on that analysis.

While coding you use Test-Driven Development (TDD) to build a fast feedback cycle about the algorithmic quality of the code. When attending a meeting you ask at the end of the meeting: "was this meeting useful? How can we improve it in the future?", when doing a full project you have a "retrospective" meeting where you analyze the project and learn from it to improve future projects.

The Freakonomics people have now written an article in the New York Times exposing academic studies that prove that the best way to be good at what you do is to include regular and quick feedback into the process of learning to do it.

Agile teams know this already: quick feedback cycles are at the core of the values in the Agile manifesto.

1. Working software over comprehensive documentation - Working software is seen as the ultimate feedback on the progress of a project. By showing the working software to your customer (see below) you will be able to assess whether what you are delivering is a)what the customer needs or wants, b)finished or something is still missing to complete a feature.

   Working software provides you feedback at these two levels:
   





• Quality of the developed software (as perceived by the customer);


• Completeness of the developed software (as perceived by the customer).




2. Customer collaboration over contract negotiation - Collaboration with your customer builds a feedback cycle that can improve the results of your work in terms of "fit-for-purpose" and "completeness". Customer collaboration can happen at the software review level as discussed before but also at the level of requirements eliciting and problem solving. Many times a set of requirements is set for a product, but as the software is developed the customer understands better the problem being solved by the software and may change his mind about what is relevant in that context.

   If you are tied to a contract and the customer is not actively involved in the project that adaptability to the context disappears, and the feedback cycle is no longer used or even useful - I'm sure you know of the impossible change-request processes that have been created to avoid this exact feedback cycle.

Agile methods thrive on feedback. Build a feedback cycle into everything that you do and you will become better at it.

The complete software process needs to be agile

As a software project manager some of the problems that most puzzled me are related to how we can change the way the development team works with Agile methods to adjust for the parts of the software development organization that are not yet ready for Agile (localization, delivery, documentation, training, support, sometimes even testing).

To start solving that problem, a colleague of mine has started, after a conversation that we had some months ago, working on making the localization process more Agile/Lean. Mika Pehkonen of F-Secure went on to implement an Agile/Lean method for his localization team and their work and he will now present it at a localization conference in Barcelona, Spain at the end of May.

Excellent work Mika, I just hope we in development can take full advantage of the changes you brought to the localization process.

For a software project to rip all the benefits from the Agile methods and Lean techniques it requires that all participants in the project are in tune with the methods and techniques. This change in the localization process has already helped F-Secure to fulfill extremely tough time-to-market requirements and will indeed in the future make our work at F-Secure a lot more productive and fun! :)

The new CEO of Qentinel Oy, a privately owned Software Quality consulting company here in Helsinki Finland, stated in an interview to the local IT weekly paper that:There is a lot of promising stuff in the Agile-side, but Agile works better for software product development than software delivery projects.I guess that by "delivery projects" he means integration of existing software products in a live environment.I would like to respectfully disagree with Mr. Hannula. Agile methodologies work equally well for product development and delivery projects. The core of Agile is that it is focused on solving the biggest problem with software development/integration: the unpredictability of the huge number of possible interactions between the many moving parts in a software product.Software is complex, that's why Agile is a better approach than the predefined process approach that the Waterfall-process prescribes.I must conclude that Mr. Hannula - even though he states that he has been thinking and using Agile methods for at least 20 years when he was 20 years old (that's from the article, no kidding) - is not really familiar with Agile methods, but rather is using the hype created around Agile to get some newspaper space for him and his company.This is sad, more so because he actually makes some good points elsewhere in the interview:Buying cheap software-labor is not a guarantee that the final product will produced cheaper.Agile development methods tend to lead to better software quality Posted by

The new CEO of Qentinel Oy, a privately owned Software Quality consulting company here in Helsinki Finland, stated in an interview to the local IT weekly paper that:

There is a lot of promising stuff in the Agile-side, but Agile works better for software product development than software delivery projects.

I guess that by "delivery projects" he means integration of existing software products in a live environment.

I would like to respectfully disagree with Mr. Hannula. Agile methodologies work equally well for product development and delivery projects. The core of Agile is that it is focused on solving the biggest problem with software development/integration: the unpredictability of the huge number of possible interactions between the many moving parts in a software product.

Software is complex, that's why Agile is a better approach than the predefined process approach that the Waterfall-process prescribes.

I must conclude that Mr. Hannula - even though he states that he has been thinking and using Agile methods for at least 20 years when he was 20 years old (that's from the article, no kidding) - is not really familiar with Agile methods, but rather is using the hype created around Agile to get some newspaper space for him and his company.

This is sad, more so because he actually makes some good points elsewhere in the interview:

1. Buying cheap software-labor is not a guarantee that the final product will produced cheaper.
2. Agile development methods tend to lead to better software quality
   

Sometimes I ask myself how people lived without e-mail before. Some other times I ask myself how other people can live with e-mail now!Talking to a colleague at work we ended up talking about inbox overload and he confessed receiving 100 emails per day, out of which maybe 20 require answers and 5 require long and detailed answers.Now imagine this. Assuming you actually work 8 hours per day (no toilet breaks; lunch? You're too fat anyway!) and receive 100 e-mails, you will have (again assuming no meetings during that day) 4 minutes and 48 seconds to devote to each e-mail. Not bad you say. Not so fast...Since 20 e-mails require answers and assuming you are quite fast and are able to read and understand the e-mail in 2 minutes and answer it in 1 minute you will have read 75 emails (100-20-5) in 150 minutes (75*2 min to read) and answered 20 e-mails in 60 minutes (20*(2 min read + 1 min to answer)).So, you've spent 210 minutes handling 95 of the 100 e-mails that you got, that's a whopping: 3,5 hours. Half your day was just used reading and answering 95% of your e-mails, but wait, you have left the best for last, you still have 5 e-mails that will take you some real time to answer.The long and detailed e-mails that require answers that we often have to search for can take up to 20-30 minutes to answer each. Let's be optimistic and assign those e-mails an average of 15 minutes to read and reply to each. Fifteen minutes times five e-mails mean that you will spend a full 1h 15m reading and answering those last 5 e-mails. This gives us a grand total of 4h 45min for e-mails per day!But that is not too bad, right? You still have 3h 15min for real work! Well, not quite. You see, those e-mails arrive at random intervals and they take your concentration away from other important work that you should be doing, therefore they actually have a much bigger impact on your performance. Every time you switch from doing something to reading/answering e-mails you loose time trying to catch up with what you were doing before, that's the task switching overhead.Not answering e-mails is not the solution. Talking to people directly is the solution. If someone sends you an e-mail with a non-trivial question don't even bother trying to reply in writing immediately. Call the person or better yet, walk over to the person and talk to her, the 15 minutes you spend talking to her will be much more productive than the 15 minutes you would spend answering her e-mail. Posted by

Sometimes I ask myself how people lived without e-mail before. Some other times I ask myself how other people can live with e-mail now!

Talking to a colleague at work we ended up talking about inbox overload and he confessed receiving 100 emails per day, out of which maybe 20 require answers and 5 require long and detailed answers.

Now imagine this. Assuming you actually work 8 hours per day (no toilet breaks; lunch? You're too fat anyway!) and receive 100 e-mails, you will have (again assuming no meetings during that day) 4 minutes and 48 seconds to devote to each e-mail. Not bad you say. Not so fast...

Since 20 e-mails require answers and assuming you are quite fast and are able to read and understand the e-mail in 2 minutes and answer it in 1 minute you will have read 75 emails (100-20-5) in 150 minutes (75*2 min to read) and answered 20 e-mails in 60 minutes (20*(2 min read + 1 min to answer)).

So, you've spent 210 minutes handling 95 of the 100 e-mails that you got, that's a whopping: 3,5 hours. Half your day was just used reading and answering 95% of your e-mails, but wait, you have left the best for last, you still have 5 e-mails that will take you some real time to answer.

The long and detailed e-mails that require answers that we often have to search for can take up to 20-30 minutes to answer each. Let's be optimistic and assign those e-mails an average of 15 minutes to read and reply to each. Fifteen minutes times five e-mails mean that you will spend a full 1h 15m reading and answering those last 5 e-mails. This gives us a grand total of 4h 45min for e-mails per day!

But that is not too bad, right? You still have 3h 15min for real work! Well, not quite. You see, those e-mails arrive at random intervals and they take your concentration away from other important work that you should be doing, therefore they actually have a much bigger impact on your performance. Every time you switch from doing something to reading/answering e-mails you loose time trying to catch up with what you were doing before, that's the task switching overhead.

Not answering e-mails is not the solution. Talking to people directly is the solution. If someone sends you an e-mail with a non-trivial question don't even bother trying to reply in writing immediately. Call the person or better yet, walk over to the person and talk to her, the 15 minutes you spend talking to her will be much more productive than the 15 minutes you would spend answering her e-mail.

Meetings are a fundamental part of any software development project. They seem to be even more important to people that are not directly involved in the software project itself.If they are so important why are they so often boring, too long and unproductive?I'll resist the temptation of trying to write here how a good meeting should be held, but I'll try to describe here a meeting I was in today that was a clear textbook example of a failed meeting.First off, the people involved where 5 product managers (?!?!?) and 2 business owners. In total 7 people. In a meeting where you should try to reach an agreement to have 7 people is asking for trouble. Even though having 7 people in the meeting in itself is not a reason for failure it is an indication that the organizer of the meeting was not able to focus the problem he had (5 product managers?!?!?!).Then the meeting started without any statement of context, at least half the people in the meeting were not told why they were called into the meeting, and at least I, heard about the meeting 20 minutes before it started, which left no time to prepare anything for the meeting.Again, not being prepared for a meeting is not a sure failure, but you have to agree that it does help a lot...Since no context was described and most participants did not have any time to prepare we started immediately "solving" the problem. When I asked why we were in that meeting I received no answer (to this point I don't know, for the life of me, why the meeting was called).Trying to go for a problem solution without explaining the problem (or indeed listening to the different views on what the problem really is) is not a sure indication of failure, but it usually leads to that.As the discussion went on several different problems were stated, none of them was defined clearly, and none of them was tackled. When this happens you know you have a bad meeting. No productive outcome can come of a meeting where no one agrees on what is the "single" problem that we are trying to solve.Let's recap the anatomy of a failed meeting. If you want to have a failed meeting make sure that you:1- Call as many people as possible to the meeting, to the point of calling in people that do not know or could not care about what you are about to talk about.2- Don't explain the reason for the meeting (context), and especially notify attendants of the agenda only a few minutes before it starts.3- If someone asks why they are in the meeting and what is it's purpose: ignore them4- Raise as many unsolved problems as possible during the meeting so as to avoid concentrating in one problem.5- If someone tries to state the problem in clear terms change the subject (at this point it is a good policy to use the technique described in point 4).6- At the end of the meeting don't summarize the discussion, don't send meeting minutes to the participants and especially don't describe what will be the next steps to try to solve whatever problem you were supposed to solve.If you follow these simple steps you are sure to have a long and happy life inside meeting rooms without ever having to reach any conclusion or solve any problem.For even better effect complain to your boss about those other people that were in the meeting and tell her/him that they are utterly incompetent and that you could have reached a conclusion/solution a long time ago were it not for those morons.These "rules" go a long way explaining why in the Agile software development model we try to avoid meetings. Most (maybe even 99%) of all problems or difficulties can be solved by having a few people (2 to 3) talk to each other over coffee and then go back to their workplaces and solve the problem together.In Scrum there is one meeting that can have up to 11 people (10 + scrum master), that's the daily scrum. But don't worry! That meeting is carefully choreographed (the 3 questions) and is usually over in 10-15 minutes once you get the hang of it. Posted by

Meetings are a fundamental part of any software development project. They seem to be even more important to people that are not directly involved in the software project itself.

If they are so important why are they so often boring, too long and unproductive?

I'll resist the temptation of trying to write here how a good meeting should be held, but I'll try to describe here a meeting I was in today that was a clear textbook example of a failed meeting.

First off, the people involved where 5 product managers (?!?!?) and 2 business owners. In total 7 people. In a meeting where you should try to reach an agreement to have 7 people is asking for trouble. Even though having 7 people in the meeting in itself is not a reason for failure it is an indication that the organizer of the meeting was not able to focus the problem he had (5 product managers?!?!?!).

Then the meeting started without any statement of context, at least half the people in the meeting were not told why they were called into the meeting, and at least I, heard about the meeting 20 minutes before it started, which left no time to prepare anything for the meeting.
Again, not being prepared for a meeting is not a sure failure, but you have to agree that it does help a lot...

Since no context was described and most participants did not have any time to prepare we started immediately "solving" the problem. When I asked why we were in that meeting I received no answer (to this point I don't know, for the life of me, why the meeting was called).
Trying to go for a problem solution without explaining the problem (or indeed listening to the different views on what the problem really is) is not a sure indication of failure, but it usually leads to that.

As the discussion went on several different problems were stated, none of them was defined clearly, and none of them was tackled. When this happens you know you have a bad meeting. No productive outcome can come of a meeting where no one agrees on what is the "single" problem that we are trying to solve.

Let's recap the anatomy of a failed meeting. If you want to have a failed meeting make sure that you:
1- Call as many people as possible to the meeting, to the point of calling in people that do not know or could not care about what you are about to talk about.
2- Don't explain the reason for the meeting (context), and especially notify attendants of the agenda only a few minutes before it starts.
3- If someone asks why they are in the meeting and what is it's purpose: ignore them
4- Raise as many unsolved problems as possible during the meeting so as to avoid concentrating in one problem.
5- If someone tries to state the problem in clear terms change the subject (at this point it is a good policy to use the technique described in point 4).
6- At the end of the meeting don't summarize the discussion, don't send meeting minutes to the participants and especially don't describe what will be the next steps to try to solve whatever problem you were supposed to solve.

If you follow these simple steps you are sure to have a long and happy life inside meeting rooms without ever having to reach any conclusion or solve any problem.

For even better effect complain to your boss about those other people that were in the meeting and tell her/him that they are utterly incompetent and that you could have reached a conclusion/solution a long time ago were it not for those morons.

These "rules" go a long way explaining why in the Agile software development model we try to avoid meetings. Most (maybe even 99%) of all problems or difficulties can be solved by having a few people (2 to 3) talk to each other over coffee and then go back to their workplaces and solve the problem together.

In Scrum there is one meeting that can have up to 11 people (10 + scrum master), that's the daily scrum. But don't worry! That meeting is carefully choreographed (the 3 questions) and is usually over in 10-15 minutes once you get the hang of it.