Recent comments

If the goal is high utilization of "code monkeys", than definitely it is a bad idea to keep the most valuable monkeys underloaded. Out of the monkey shop, however, I more frequently find situations when you cannot afford to keep the most experienced people overloaded. It is cheaper to let them have some slack (possibly used for work on what they themselves think is important), rather than leave less experienced people without help, when such help is needed.

At the moment I work on the customer side with quite a significant amount of people "rented" from the offshore companies and I don't think there is a significant difference in approaches once externals get the feeling of safety and realize that they are not going to be punished for "underutilization". Even though offshore developers are usually hired by man-days, they are rarely hired for numbers in excel. Usually they are hired for building or supporting valuable products and all the product development lessons apply.

An iteresting reading and definitely food for thought!

For starters, I am coming from offshore outsourcing perspective, where time is literally money, so I believe offshore outsourcing companies can't typically afford their resources (especially senior ones for whom they usually charge more $ per hour) being underloaded.

Still, I fully agree that the scenario when senior people do work that could be done by a junior or at least intermediate developer is flawed. It is way better to have senior devs work either on really challenging tasks, or as technical leads supervising code quality, following best patterns and practices, coaching juniors etc. However this wouldn't make sense for a company renting its resources as "code monkeys" instead of striving to own the product development.

well

Some of the comenters miss a point that is self-evident if you work in agile processes for a while: A User Story is not a large peice of work and you will never complete all user stories. If stories are large or you believe you will complete all stories ... then you won't ship. That was not the authoris argument.

We company limits stories to less than 1-3 weeks of work. That is, in 1-3 weeks, I don't have every feature the product requires, but I have a software that does at least 1 thing very well. We obviously have a number of major features and products that require much more than a few weeks of work, but we still drive at them one small story at a time.

... but it should be renamed to ""How to prevent your crap from ever shipping."

...to "How to prevent your software from ever shipping."

Well, agile development is not a silver bullet. It is not the end-all solution to all our problems, sorry - despite the fact that I like this methodology much more than any other, because it works better in most cases than any other.

There is a vast class of areas where agile development is not necessarily a good fit, at least not in all its full glory.

Say you are designing a satellite. You have exactly one shot to make it right. There is no way to "fix stuff iteratively" later. Upfront specs that *have to* be right. Otherwise you end up missing Mars by a thousand kilometers or cratering into it. Just ask NASA.

Also - I *will* argue that you can deliver *the whole* backlog using agile methododlogies no faster than using traditional ones. It is just the 20/80 rule at play here - the product that you deliver in agile way begins to be useful much sooner than if you used traditional processes.

"Without management there would be *no* incentive for individual teams to optimize for the entire organization, instead of optimizing only for themselves."

Well, what incentives would there be for them to optimize there own project to the detriment of the other project?

"Indeed, a well-run traditional project can deliver the full product feature set faster than the equivalent agile project, when you take into consideration that it is normal for agile projects to redo user stories when the customer decides that what has been delivered is not what they really wanted."

Are you sure about that? Is there any indication that up front design is in fact faster than emergent design? Is there any indication that defining the right requirements up front is any faster than doing so incrementally and iteratively?

Or are you in fact saying that delivering a full product that the customer in fact doesn't want is faster than delivering one that the customer does want?

"Perhaps we don't aren't actually that far from agreement."

@Jeff Santini: Indeed, I think we actually agree.

"If they are setup so that the well being of the whole company is more important to them than the well being of their single project, it shouldn't take more than perhaps a bit of facilitation to resolve such issues by collaboratively finding the best solution for the whole."

@Ilja Preuss: But who does the "setting up" that you're talking about? The answer is: the manager. That's my whole point. Without management there would be *no* incentive for individual teams to optimize for the entire organization, instead of optimizing only for themselves.

"What about two teams fighting for shared resources? The strongest one will win if you leave it up to self-organization, and the weakest team will be the victim."

That only makes sense if the teams are set up so that they are in competition. If they are setup so that the well being of the whole company is more important to them than the well being of their single project, it shouldn't take more than perhaps a bit of facilitation to resolve such issues by collaboratively finding the best solution for the whole.

When implementing user stories, there is normally a section in the story called the "Acceptance Test". In my experience this is the thing that is used to test whether or not the story is completed. If the acceptance test is not met, don't close the story. If it is met and you aren't doing everything people want, create a new story.

The problem is that the acceptance test typically describes what must happen in a line or two, so sometime when you meet the acceptance test there are things that are clearly complete. In this case, have to open a new story or a bug (if a specific case is not correctly implemented).

Saying that we must never have known bugs is a bit of false good thing. We always have to use judgment in whether or not the "spirit" of the acceptance test has been met and whether or not a bug is a stopper.

User stories are not features. A user story means that we have implemented enough code to perform an action. A feature is another thing all together. The scope of such is not so well defined and there is rarely a 1 to 1 relationship between user stories and features.

In our experience, when a client / projectmanager / any obviously technical moron asks to create something it involves making something that actually doesn't work or he/she doesn't want. Meaning that most things made by programmers around the world either don't work or will never be used because the 'client' doesn't like them.

In a lot of these cases 'it's done but doesnt work' is a completely valid statement and not the programmer's responsibility. Easy to say for a client or some lame management type who knows nothing that 'it should work' while programmers built exactly what they asked. And ofcourse that was never supposed to work.

Not saying you are like that, ofcourse your 'user stories' are unambiguous and perfectly logical and leave no possibility for done-but-not-working. But in general...

PS I am a manager and a programmer and I often write bad specs/userstories after which I just have to accept the total garbage that comes back from the developers. Nothing to do about it.

I'm not sure you understand the idea ;) The idea is not to have 100% of user stories done but to define when the story is done. Not the whole software - in one iteration you have to deliver 10 stories in another one it will be 8 stories. It is not the definition of "software done" but the story/feature done.

Hope it helps,
Cheers!

Conclusion: If you're done, you don't have enough user stories OR no software is ever done.

Three quick responses.

1. I am glad I misunderstood the roles of all those managers and that they are actually there to be involved only when the team decides it is necessary.

2. I think as much as we wish they did not exist, Al Qaida's successes do much more to support rather than subvert the argument that self organization is a powerful force.

3. I am not sure how much of a conception it is in the Agile world that "empowerment and self-organization" are enough to grow healthy projects. I don't speak for the Agile world, but as for myself I know it *can* be enough. But since it is not *always* enough, someone who may be a manger is a nice addition to fight admin battles for the team, and perhaps to keep the communication channel open between budget owners/auditing types and the team. But this person should then switch hats and join in the job of creating the software, or stand back and provide the team as much space as possible to get the job done.

Perhaps we don't aren't actually that far from agreement.

Manage Progress with a big, visible task board

Even we had a tough time in our project. Under such situations we followed most of the above mentioned points. I initially wondered why, "Manage Progress with a big, visible task board". Later found that to be really working well.

Yea. Even we have a daily scrum meet and it has proved to be really effective now a days. It may not be a standup meet, but rest of the points mentioned are followed. Especially the sharp timing, 3 main questions to be answered, keeping the meet as short as possible, filling the sprint backlogs (done by the one who conducts it), ... We also extend our meeting if any of us has really a stopping issue --don't know whether we are rite in this. Thanks for the nice post. Came to know how others perform their scrum meets.

Of course it's not really practical to have a discussion about what was meant to be an what wasn't. If you start by saying people weren't meant to have a boss and people werent meant to work in large organisations then it's only a question of time before you end up with discussions about if it was a good idea to leave the trees a couple of million years ago.

Some people like large organisations better and some like small organisations better. If you work in a larger organisation then it's a good idea to have some managers walking around to make sure everyone has what they need to do their jobs. If you have a good manager then having a manager is actually a luxury.

"This study doesn't really provide much evidence for anything."

I did not talk about evidence. I talked about my thoughts. There is obviously a correlation between people's motivation and their judgement of managers. Of course, my interpretation (the causality working one way) is just a hypothesis. But as long as someone else has not been able to falsify it, then my theory stands as it is.

"An empowered team can, by definition, protect themselves."

Not true. What about two teams fighting for shared resources? The strongest one will win if you leave it up to self-organization, and the weakest team will be the victim. That's what teams need management for. To resolve issues they cannot resolve themselves without doing harm.

"And having a service manager/ program manager/ functional manager, and quality manager as enumerated in your Resource Planning entry doesn't seem to leave much decision making space for team decisions"

You misunderstand me. Service managers, quality managers and other "managers" are not law-makers. They are part of the self-organizing teams, just like software developers are. In fact, those developers might have to be called "code managers". They all manage some aspects of a project. And only when they are unable to solve an issue together, then they will escalate to a functional manager, who is the only one outside of the team.

Still, empowerment and self-organization are *never* enough to grow healthy projects. I believe that is the biggest misconception in the agile world.

After all, Al Qaida is also the result of self-organization...
Some people really require protection from such self-organization.

See, this is the common misconception. Agile is not necessarily faster when you are talking about the whole product backlog. Indeed, a well-run traditional project can deliver the full product feature set faster than the equivalent agile project, when you take into consideration that it is normal for agile projects to redo user stories when the customer decides that what has been delivered is not what they really wanted.

However, agile projects have a much shorter lead time for delivering individual features requested by the customer. This makes agile projects much more efficient if you prioritize user stories properly - this is due to the Pareto principle: any product contains 80% of its value in 20% of its features.

I am going to devote the wohle blog post to this phenomenon, as I have interesting practical observations to share :)

I agree with Piccolo Principe. This study doesn't really provide much evidence for anything. And the analogy of employees and lions has gone way off (whatever) track it was on.

Jurgen, you state that, besides protecting their employees a manager should do as little as possible. I submit that most of your blog posts are all about what great things managers can do to and for their teams. Lets hear a bit about what the teams can do for managers. I would like to hear that your team agrees that protecting them from bad people is a good use of your time. An empowered team can, by definition, protect themselves. I don't hear much about how teams make their own decisions in this blogs. And having a service manager/ program manager/ functional manager, and quality manager as enumerated in your Resource Planning entry doesn't seem to leave much decision making space for team decisions.

Jeff

While I agree with you that agile facilitates communication with customers and between team members and that this is an important part of agile. I disagree when you say that agile is not faster.

All the practices of Agile (communication, pair programming, extensive testing, short iterations) are there to keep developers focused on the problem that should be solved. Traditional processes, with large feature lists often resulte in people implemented features that they never need.

Losing focus is what causes us to miss delivery dates and agile methods are constantly reminding us not to lose focus. For this reason, I think that agile *is* faster.

Replace "Java skills" with "software engineering skills". The rest is definitely true.

Communication is the most important (similarly to other factors :)), but what if one guy (or two good friends) is working on their own product? He has vision, He doesn't actually communicate with customers. Indeed, he does not need any Scrum or other agile software process then. Still he may end up with an awesome software.

So there are no golden rules. Including this one.

Sure, you need all of these things you mentioned, otherwise you will fail. The thing is though that you don't need a process (agile or otherwise) if you don't need to communicate. Processes in software development are all about communication. Other engineering disciplines (designing, testing etc.) are tools of the craft that are of different type and I glossed over them on purpose.