Six Steps of the Scalable Agile Framework
Agile methodologies make a lot of sense for small work groups, but can agile scale?
The Agile Manifesto declared that there are better ways of doing things than waterfall, and that it is actually detrimental to have everything planned out in advance for a software development project. But on larger project where a lot of money is being spent and a lot is expected, there still needs to be a lot of planning at some level.
So it's a key question, if you are working on a large project, of how you will balance long range planning with agile-style development. After all, you still need to accomplish the goal of implementing a large system - but want to do it the most efficiently and effectively you can.
The key to Agile is that it does not involve all of the planning up front. It employs a sort of "rolling wave" type of planning and scheduling. However, that rolling wave is most significantly used at the scrum team level, and not at the overall project management level, where there need to be longer term targets.
There is an approach for scaling Agile development call the Scaled Agile Framework. It's not that there should not be a longer range plan, but that the scrum teams need to be insulated to a large degree from it in order to gain the benefits of Agile.
Here are the key areas of execution for the Scaled Agile Framework and how they play with long-term planning:
- Ready - The Product Owner and team are still charged with preparation and do regular sprint planning.
- Plan - It is important to focus on what to build - stories based on target capabilities - and a way to test if it is achieved - acceptance criteria.
- Commit - The team needs to set specific goals - at least for sort-duration (probably two weeks - sprints, and needs to commit to delivering int those short timeframes.
- Execute - Execution on the team requires all of the basics of good team management - good collaborative relationships among team members, focus on the user stories and testing, and feedback regularly from the product owner.
- Demo - Regularly delivering, at least by demoing, is critical, as delivering early and often is the hallmark of agile.
- Retro - Continuous learning via conscious retrospective sessions promotes incremental improvements with near-term benefits.
That's at the scrum level.
As for the planning, there needs to be a capability map and overall schedule above the scrum team level that monitors and steers progress. This includes having capabilities, or requirements, that map to the scrum backlogs, and that prioritize for the scrums.
In my opinion, Agile is very scalable. It allows for the est of both worlds - high productivity and output at the production level, and achievement of overall and long term targets. the key is to utilze sound project management principles at both levels - collapsed and for short duration well defined sub-projects at the scrum level, and sufficiently defined but not overly restrictive planning and scheduling at the top level.