Agile focus on flexibility and the ability to change directions during the project, but it is not the same as working unplanned and rushing to do anything that comes up. For some people new to agile methodologies, this might be a bit of a surprise.
An experienced project manager, that at the time was new to agile processes once said to me:
I thought scrum was supposed to be agile, but the fixed sprints makes it a loss less flexible than what I’m used to. When something new, urgent comes up, I can no longer go ask someone on the team to fix it.
At the time, I was mostly upset with the comment, but with some spacetime distance to the project I can now look back and learn something from it.
The first thing that was obvious was that the project manager was not at all as used to plans and following plans as he thought. Of course there had been project plans before, but only on a high level. There had not been the detailed plans that are prepared in a scrum sprint planning meeting, where the team and the product owner negotiates a deal on what to commit to for the next sprint.
The second conclusion is that the project manager was not used to self organizing teams, that do their own planning. In an agile project, the role of the project manager and product owner is to give the team a clear goal and then let the team work in the best way they see fit to reach that goal. To do that, plans are indeed required, but that’s a different kind of plans than the normal project plan.
Working in an agile team the days before a sprint demo is an intense experience. Everyone is extra focused. Test cases are run to find bugs. The last loose ends are tied up to make sure the entire sprint is finished. To me, a sprint demo is not only a way to show the progress of the project to the stakeholders, it is also a major success factor of the project itself.
First week results
When a project is first started a plan is made (this is an agile project, but there should still be a plan). There are five major feature areas that are to be developed in parallel. The team starts happily developing, writing code in an exploratory way while learning the business domain and the technologies involved in the solution.
After a week, work has been started on four of the areas. So far everything is looking great. One of the features is obviously easier to implement that the others, but work has at least commenced on four of the five areas.
An experienced project manager I used to work with claimed that he took the programmers’ time estimates, multiplied by pi and converted to the next time magnitude to get the true number. 1 day converts to 3.14 weeks. He had learned the hard way that programmers are bad at estimating times. To get a more precise conversion, I’ve created a translation table for programmers’ time estimations, trying to narrow down where things go wrong.
In my latest post in the Scrum series I finalized the picture of the parts required to produce a shippable product. However, the project doesn’t end there. One more step is requried and it is the business implementation of the system.
In the consultancy business where I work we develop custom systems for customers, to support the customers’ unique business processes. If we’ve done everything right, the system developed is based on the correct processes, has the right users stories implemented and has the right quality thanks to testing. That’s the end of the project, isn’t it? Not quite. There is one important step left: the business project to adopt the system and take it into active use.
Why does system X not include feature Y?
That is quite a common question. I think that Eric Lippert has en excellent standard answer to that kind of questions on C# at Stack Overflow.
Features are unimplemented by default; C# does not have that feature because no one designed, implemented and shipped the feature to customers.
Being a developer of custom business applications, I’d like to expand on Eric’s answer a bit.
Features are unimplemented by default; the system does not have that feature because no one listed it as a requirement, prioritized it, payed for it, tested it and deployed it.
What it all boils down to is that there is a lot of work and communication required to ship a feature and nothing is done without effort. To get good results, both the customer and the developers have to take responsibility for their part of the effort.