English | EN 
There’s no getting away from it, I have a terrible confession. There’s something about Waterfall I really like, and all too often I think the adoption of agile leads to throwing out the baby with the bathwater.
Well, a bit of the baby at least. But that’s frowned upon.
I still recall joining my first agile project, having to work in this new and super way with limited experience. There was a lot to learn and, once I got over my initial trepidation, it was pretty neat. Here’s the thing. I like agile. I really do.
What took me a while was getting my head around how it works for big projects, as my previous experience was on big projects, working on big things. Big things which can not be split into smaller bits easily, rather like the much sought after prime numbers upon which BitCoin depends.
Frequently I see projects which are arguably only Agile in name: where the ceremonies have been adopted as an almost tick-box exercise; sprints are implemented, and the result is delivery becomes a can which gets kicked down the road. In terms of Waterfall, this would be the plan shifting right, being delayed. This would lead to a re-planning exercise, and possibly seeking additional funding or resources. But agile can seemingly rumble along, the can tumbling along at its feet.
What I specifically miss about Waterfall is the over-arching plan which is used to hold the delivery to account. And it seems to get lost through the process of task breakdown, working in short time-frames on tiny tasks. The over-arching view can be lost.
The thing is this does not need to be so. Agile provides a fantastic mechanism for managing a long term plan. One such version of this looks rather like this:
- Tasks – things which can be done as part of a time-boxed delivery (Sprint)
- Sub-tasks for when you need more detail or to split the task between different people
- Stories – Short requirements or requests, written from the perspective of an end-user
- Epics – Large bodies of work that can be broken down into smaller number of tasks (calls stories, just to add unnecessary confusion!)
Even limiting ourselves to these definitions a pattern is emerging, one of a hierarchy of activities (especially if you include sub-tasks) based on their expected duration. Yet there are two more levels to consider:
- Initiatives – collections of epics that drive towards a common goal
- Themes – Large focus areas that span the organization
And here’s the thing: Like it or not we can apply estimates to each of these which will generate milestones and a rough timeline. To help this process we can apply larger factors of the error to estimate for larger activities, with these estimates being updated as tasks are broken down, and further refined as estimates become actuals.
And voila! We have a program plan! Something to report progress against!
What it boils down to is that there is clearly still a requirement for Project Management, and this is something we are in danger of losing because it is not explicitly stated as belonging to one of the fames Three Amigos: Product Owner, Developer, and Quality or Testing. With experience of delivering large scale projects spanning all methodologies, Sogeti is well-placed to understand not only the benefits of each but also the pitfalls of each, and to ensure successful delivery through our experience. Beyond this our involvement in large scale transformation projects has led to us working with clients to deliver agile at scale, on time and against the plan.
