Imagine you're driving from one side of the city to the other with a friend and you're in a big hurry. You're running really late and you're desperate to get where you're going. To your amazement, your friend sets off down the road and puts the pedal to the metal in first gear. He's gripping the wheel, concentrating fiercely, the engine is screaming, and you're being overtaken by every car on the road, doing about 30kph.
You say to your friend, "Hey, don't you want to go into second gear?"
But your friend says, "Don't interrupt me, man, I'm going as fast as I can and I really need to concentrate here"
You try again. "But we'll get there faster if you change gears!"
But your friend says, "No we won't! I tried that before and putting in the clutch __definitely__ slows you down, silly! And the last thing I can do now is slow down when we're running so late!"
The problem with development teams is that you can't actually hear the engine screaming and see the car shaking and feel the lack of speed. But it seems to me a lot of development teams are flat out in first gear. Agile development has a lot of practices that are all about changing gears.
Subscribe to:
Post Comments (Atom)
I've been thinking a lot lately that development is all about feedback processes. Not just the feedback in terms of the feedback cycles, but the nature of the positive and negative feedback.
ReplyDeletee.g. writing code is a positive feedback cycle for features, but also for bugs. Diverting effort to testing gives the necessary negative feedback to keep bugs under control, and allow for features to continue to grow. Delivering features, in turn, is a positive feedback for new features - this needs to be reined back (negative feedback again) via prioritisation and planning.
The important aspect here is that you can't just try to go straight ahead. You need to both put and take energy out of the system to get it where you want it to go.
Oh, and of course, if you say that your software development process is chaotic, everyone agrees. :)