Archive for 2010/03/12

How do you know if your sprint delivery will fail?

Sometimes software development feels like when I doing gymnastics in my youth. Just like the boy on the picture, you start your pace slowly, carefully. You know where the finish line is. Then you start to wobble. Trying to keep yourself up, you increase the speed, hoping that you will make it to the other side. Often you didn't and fell down. Other times you barely made it, just to crash on the other side.

To some, this happened sometimes, to others it happened over and over again. Somehow, the repetition did not help in the learning process.

Another example is from when I was taking my driver's license. Here in Sweden you must complete training on icy roads. The teacher used a very clear method. We were instructed to go around the course a number of times. The first time we were told to keep a specific speed, 30 km/hours. Everyone made it. Then he told us to go 50 km/h. No one made it. And then he told us to change whatever we thought suitable to ensure that we would complete the course. 20 out of 21 students decreased the speed and made it. One kept up the speed and of course he didn't make it. As he could see the speed of all the other drivers, one would guess that he would understand but when he was given the chance to again change anything to complete the course, he didn't change the speed and was again the only one not to complete the course.

I really hope that guy never got his license but we all know those guys are out there, those who just speed up, crashes and never learn. And when those guys are into software development, there are failed releases.

Change This is a wonderful little site, dedicated to change and one of the manifests discusses product launches but it can as easily be applied to any software development delivery. There are some handy rules out there and what I like most is the integration of outside stakeholders. In the manifesto, salespeople are mentioned but they can as easily be anyone caring for the software on which they depend. Happy reading.

Posted via email from forss’s posterous

Categories: Agile