One of the biggest challenges for me when I discuss Agile concepts with peers in the large corporate environment is the stonewall that is built up that prevents change. I think this story of NUMMI and the decline of GM is a story that most people can relate too and will help shed light on the big picture. In some ways software development is a very young field where we are still finding best-way practices. Certain fields have had decades of time to develop best practices. As developers we are given expectations in most cases by people who are not familiar with the software development process to turn out products quickly and with minimum defects, but yet through contract negotiations we are placed into environments that use strategies like the Waterfall because in the past that is how it was done and the customers can relate to it. I am probably preaching to the quire about the benefits of agility when it comes to software development, but I think this podcast is great because so many similarities can be drawn between the production of cars and the production of software.

According to the podcast GM knew that the techniques of continuous improvement at NUMMI was a winner, but they couldn’t replicate it elsewhere because among other various reasons they didn’t have the entire company buying into the Lean process and consequently the groups within GM that were trying to be Lean were not supported in the same way by the non-Lean groups. It is an interesting case study. For anyone who wants a good overview of NUMMI this podcast is really great.

http://www.thisamericanlife.org/radio-archives/episode/403/nummi

Agile allows great latitude when it comes to the mechanics of process, as does Lean. What it does seem to require, however, is a different context surrounding people. And I’m not really talking about specific projects. I’m more talking about the management and people context. If you want to do Agile and you treat it as a simple set of practices, like an exercise regimen, then you won’t get it right and you wont’ get all of its benefits. If you want to do waterfall or some other method that is primarily a set of practices, then you can certainly do it and you can mix them. What is most difficult to do is to change the human context when you change the practices.

It’s just not likely that self-organization will be supported in a context where command&control is used freely.

I know a lot of organizations which work in mixed project environments. Companies which deliver projects both agile-way and old-school-way. If these projects don’t interfere with each other and people are allowed to follow principles they believe in I see no problem. And, believe it or not, many companies work this way.

Another example is working on agile projects where client (and management) requires some high-level commitments regarding schedule, price and scope. Whether the project will be a healthy agile one or just agile-in-the-name-only depends on management approach and practices the organization employs. Agile doesn’t say “you’re forbidden to prepare project plan.” If you’re able to create reasonable project plan, and you should know how to do it if you use reliable estimating techniques, I don’t see how it makes you non-agile.

And coming even further, you can live in completely bureaucratic organization where process is the king and you can still cut off a bit of it and replace it with a piece of agile. One of my favorite Scrum stories is the one from local branch of Motorola. This office is known to follow dramatically bureaucratic process (stories about 1 day of coding followed with 2 weeks of documenting aren’t very rare there), but some agile enthusiast were able to implement regular Scrum in one team and achieve better results then before. I wouldn’t say them they aren’t agile only because their managers believe in formalized process and their organization isn’t agile to the last bit.

I can agree that the agile team should be fully agile – you can’t have a team leader who doesn’t really get this whole agile thing and enforces the old process on the rest of folks. This doesn’t work that way. But as far as there’s commitment within the team and it is possible to build a reasonable interface with the rest of the organization simulating behaviors expected by both sides it can, and most of the time will, work.

Interesting idea, and one which I’ve never considered. What if a self-organizing team chooses a waterfall process? I suppose it’s possible. I want to think about that some more.

Still, that case is the flip side of the case I was trying to discuss, which is the one where the benefits of agility are desired. What I was saying is that you don’t get all the benefits without self-organizing teams, and that it’s hard to have both self-organizing teams and command&controlled (we really need a better phrase than that) teams under the same management.

alan

I agree. Takes more language to include this case when you’re writing, but I think in really large companies it is possible for this to happen within a business or a division.

Good point.

alan

‘”We’ll never be totally Agile in this company. There will always be waterfall projects.” I smile because what that really means is that they’ll never be Agile at all.’

I believe you are mixing up two separate points. One point is about the structure of a project, the waterfall being a planned project with all steps mapped out up front. The other point is about agility and fostering self-organizing teams. The implication is that the former is incompatible with the latter.

This isn’t inherently the case. Some projects work well when organized along waterfall lines, because it is possible to plan all the steps up front in a reliable fashion, and organize the work efficiently. These projects may not often need to be very adaptive, because the work is predictable.

This is a separate issue from whether the company fosters self-organizing teams. They may do this, and still organize a project along waterfall lines, because this makes sense for that project.

So the company may be totally agile and have waterfall projects. I suspect this happens fairly often, but perhaps less often in the software industry than (say) painting.