Or ask yourself “how did we ever lived without a mobile phone” ? Same kind of question …
Before
Before we have all been Agilize’d, we were still conducting projects, after all. Typical move was to fire MS Project and start aligning rows. Put duration, resources. Then we were linking everything together, the screen started looking like a spaghetti … but the Gantt Software did manage that nicely.
At some point of time though, there was so much dependencies that everything was tied all together. One day shift in whatever line was immediately bubbling all the sheet up. Then you or the program manager was spending his day arranging everything. Projects eventually shifted but this was OK, they always do, don’t they ?
The problem with this approach was the reporting and the deliverables. Reporting couldn’t do much better than producing a list of task on-schedule, lagging, completed. Deliverables ? Well, that was really the weak point of it, as in essence, the plan was encompassing the project in its entirety, so it was not easy to define partial deliverables.
Resource management was also a nightmare (and vacation management ..). Overloaded people at 200-300-400% rates were not uncommon.
Enters Agile …
From my small experience, Agile (and Scrum methodology) has the immense advantage of looking at the project from a completely different angle, which is
- What are all the sub-components elementary tasks that make up the project ? (the backlog)
- For each task, what “weight” (effort) does it represent. This is not duration yet. Weight is expressed in points … in a first approach, assuming 1 point = 1 man-day is reasonable.
- How can we group together bunch of tasks so that it makes up a clear delivery ? This has to represent something doable in a manageable period of time: the Sprint.
- How many “points” can my team handle during one sprint ?
so in essence, the project is segmented in sub-components, this goes down recursively. The beauty of this Agile approach is that, once a Sprint has been setup, the resources for doing it are necessarily available …. and if managed correctly, the Sprint can be viewed as an interim deliverable !
At the same time, Agile approach also enforces things like continuous delivery, smoke test, etc …. These concepts are not very new, Extreme Programming was also emphasizing them. Nevertheless, at any given point of time, we have
- A working deliverable: the previous Sprint
- A clear view of what feature will be available and when
- Dedicated resource working on the current sprint
Managers value that a lot, you can imagine :), for the following reasons:
- They usually have clear and documented answer to the dreaded question “give me something I can show”, at any point in the program !
- As the Team tend to know how much “points” they can handle (this is refined overtime), then the next deliverables are more predictable.
- Day to Day status can be grabbed just buy looking at the project board (if using SCRUM)
OK, this sounds maybe almost too beautiful … but the reality is not very far from that. Recent projects I have worked on were delivered on time, interim deliverables as well. One project was small (2 months, 3 deliverables, about 6 sprints), the other was much bigger: 1.5 year, over 20 deliverables. Both were achieved and delivered on time, which is probably the first time I see that.