There is a painfully funny Dilbert cartoon that shows a project manager proudly stating that his project will ‘come in on time and budget’ because he is going to do it just the way it has always been done before. Dilbert makes the point that no-one has been successful using these methods, but the PM declares that they are confident of being the first.
One of the many parts of the Agile philosophy that I really like goes something like this:
- It is almost impossible to get the 'xxx' aspect of managing our project right first time, so let us not waste time trying; we will do it some other way.
There are several 'xxx' aspects within Agile, but the one I want to talk about now concerns estimating how long it might take to satisfy the users’ requirements.
Obviously there is one place in the project timeline when we know exactly how long this might take (and therefore how much it might cost), and that is at the end. Not many management teams can tolerate such an approach, so (in traditionally-shaped projects) the PM is asked at the outset ‘how long will this take’, and its inevitable companion question ‘how much will this cost?’
As Dilbert observes, this is almost never accurate, but we persist with the process, thereby creating the proverbial tablets of stone that will be rammed up the PM’s nose at the (eventual) completion of the project.
In order to arrive at an accurate estimate of the development effort in a traditional project we need to complete about 30% of the requirements management work; the Feasibility Study, Requirements Definition, Business System Design and Computer System Design. Again, most management teams will not lay out 30% of an unidentified budget just to find out how much it might cost to finish.
Actually this approach reminds me of the Function Point Analysis premise: if you tell me how big it might be (in function points, arrived at after the same steps as above), then I will tell you how big it might be (in development days required to get to project completion).
Agile takes the Dilbert approach; we can never get it right, so let us not even pretend to do it like that; we will do it another way.
The other way, in Agile terms, is NOT to analyse to death at the outset (outset = 30%, remember), but to identify the user requirements at very high level (as User Stories, in Agile-speak). We can thereby gain an idea of the relative sizes of packaged functionality (measured in Story Points) in order to package the development into a series of Sprints (the Release Plan). Story Points do not have any calendar or financial units associated with them, but give the development team (and Agile includes the users in this team) an opportunity to prioritise and package desired functionality, and produce a plan that shows when useful functionality will be delivered.
Each Sprint will contain its own analysis, design and development, so the start of each sprint (the Sprint Planning Meeting) is the opportunity to identify the real time and money dimensions of each small package of functionality. These figures will be accurate, as they will be arrived at as a joint effort of all team members, but also, as these team members are responsible for planning and managing their own time in each sprint, the durations (development time, measured in ‘ideal days’) are likely to be accurate as well.
Now, from a management point of view there may be alarm bells ringing here. This scrum approach differs from old-fashioned (sorry, traditional) project management in many ways, with several of them being:
- There will be no definitive estimate of time and cost at the outset
- Users and developers will be allowed to make instant decisions concerning acceptability of their own work.
- The cost of a sprint may be easy to establish; the number of sprints will be difficult to identify until detailed Release Planning has been carried out.
- Control over the development team’s time is delegated to the team members
I think the technical challenges in most scrum projects are relatively minor; the success of an Agile project is linked mainly to management support of the new process, and by that I mean management acceptance of the philosophical point of not trying the same old thing over and over again. Let us do it differently.
© Mike Watson 2015