I’m working with a number of companies using agile methods that have between 10 and 20 teams all working on the same product/project/program. They didn’t start small. These aren’t cases of organically growing from one good agile team to many good agile teams. Rather, these are organizations that have grown up in a non-agile approach and now want to reap the benefits of agile with their many teams. What is interesting is that these organizations all have some common problems and then all have some unique problems. There isn’t an obvious prescription for how they should be doing their agile implementations. I hope to write a few articles about scaling agile and scrum, and this one is our starting point: what reading should you do if you find yourself in the situation of trying to build a large agile organization.
There’s a great discussion on the Extreme Programming Yahoo! group where a whole bunch of folks list their blogs out. If you aren’t part of the group, you should probably join it (it focuses on technical practices, and there’s lots of other good agile stuff there too). The discussion starts with a message from James Carr where he asks who else here blogs?
It’s probably still cool to jump in with your own blog link if you have an agile-focused blog (I’m sure Scrum, Lean and other agile methods would be welcome even though it’s an extreme programming list!)
Building software is expensive. I’m not talking about creating software, I mean taking software as written (source code) and running it through compilers and linkers and post-processors and packagers and obfuscators and installer-generators. It might not seem so, but look under the covers and you will find a wealth of costs and potential savings…
Lifecycle of the Developer
The developer has a concept he needs to translate into software. He (or she) does not sit and meditate until it comes to him, then streams it effortlessly into the computer. Rather he tries something, and tries something else, and writes some conditions (tests) to limit the scope of his options, and cycles over and over and over again between four main activities: creating -> building -> executing tests -> discovering. The developer then wraps around, having discovered and learned (found the bug or identified a future direction) and begins to create again.
If you break this down, there are two states – active and waiting – that the developer is in at any point. He is active when he is learning and he is active when he is creating. He is waiting when he is building and executing tests. So the developer’s ability to do further learning/creative work comes from how long he has to wait for building/executing the software.
Mike Cohn has written an excellent article that covers a number of different options that can be taken when someone in an organization desires to implement an agile method.Â These Patterns of Agile Adoptions are described as three sets of contrasting options:
- Start Small vs. Go All In
- Technical Practices First vs. Iterations First
- Stealth Mode vs. Public Display
I just read through this article about Requirements Management in an Agile World.Â It’s a pretty brief article (just the one page), so there isn’t too much there.Â Have a read, and then come back here and tell us all: what is wrong with this article?
J. B. Rainsberger has written an excellent article about the usefulness of planning velocity (and the places where it is not useful as well). I highly recommend reading it, particularly if you are a manager or a project manager.
This course offers ScrumMaster Certification in Toronto. The training is hands on, interactive and highly effective. By the end of the course participants will receive a professional certification in Agile Software Project Management. The dates of the course are January 16 – 18, 2008.