Agile Practices Are Not Just About Management

I came across this article by Mike Hadlow via Twitter.  I found that I could relate some of what was described in the article to my own company.  It is well worth a read

“Once the software gets part a certain size and age, it becomes almost un-movable and a real hindrance to the business. Often the response is to start from scratch, but this just makes things worse as the new system gradually goes the same way as the old, and in many cases never fully replaces it. Then there is the additional task of integrating the old and new systems, usually as a ‘temporary measure’”

Agile Practices are not just about management

Tight Deadlines in Scrum

I have found the issue of producing a substantial piece of functionality with a tight deadline an issue with Scrum. I shall set the scene.  We conducted our Quarterly planning and prioritized our work for the Quarter. 

A few days before the Quarter began a new piece of functionality was dropped on us from a great height.  The deadline for this piece of functionality was 1 month away.  We knew that it would hit us soon, but not as soon as it did.  It was a high revenue earner and due to the fact that it was to be completed within one month it took precedence over all.

One problem with this new piece of functionality is that it is deemed to be greater than one months work.  Also it is .Net heavy, so the Flash developers in our team will be light.  So the Product Owner will need to promote stories for them to work on (Cross Skilling was an option, but we have some Flash work that needs completed this quarter anyway).

The second problem is that we have moved to a new 3 week sprints.  We have no idea of our average velocity as we have just made the transition to 3 week sprints.  Our average velocity for 2 week sprints was 31 Points but we have yet to find our average velocity for 3 week sprints.

The Third problem is that we have 1 full iteration and 1/3rd of an iteration to complete the stories that have been identified.  For the sake of visibility and to gauge whether we are on track or not, I have added all of the stories to the Story Wall.

I have a feeling that this has turned into a Mini Waterfall / Scrum method in some aspects of development.  As all of the stories need to be worked on and pretty much completed within this Iteration.   I have to put all of the stories on the wall as I feel that this would give us better visibility of what we have done, what we are doing next and what we have still to complete and will help us as we know exactly where we stand.  Also with all of the stories visible on the story wall, I am able to create my Burndown Chart to map if we are likely to meet our deadline or not.

We cannot really be iterative in development as we have to have the work completed in one iteration.  We have prioritized the ordering of the stories on the wall with the most important at the top of the board so we are completing the stories in a logical order but the main worry for me is the Teams Velocity.  I have always been under the impression that you should use your average velocity wisely.  If you manage to complete more story points you should adapt your velocity to map this and on the flipside if you complete less story points you should adapt your velocity to account for this for the next iteration.  We have a case where we need to complete nearly double our average velocity for 2 weeks, in a 3 week iteration to meet the hard deadline.

How do you guys feel about this.  Is this an effective way of working?