My last five posts have covered the topic of using phases in agile software development similar to the phases of the Rational Unified Process (RUP). So why phases? Neither the Agile Manifesto nor Scrum make any reference to phased development. If you use phases, are you really doing agile development? (If you haven’t read the prior posts, they began with Project Phases Can Be Used In Agile Development Too.)
My focus is on mid-sized to large-scale software projects. I’ve found that small teams building small systems can operate any way they like. Whatever works for them is usually good enough (assuming they have the right skills, experience and leadership). Large teams are a different matter and that’s where phases can help.
Large teams building large systems need more project planning and guidance. They require more software architecture and design work. It’s much tougher for a large team to figure it out as they go. There will be too much confusion and too many arguments to get anywhere fast. The additional structure that RUP phases offer can help.
Plan It. Design It. Build It.
One of the major criticisms of agile software development is the lack of project planning and software designing at the outset of projects. There really is a lot of planning and designing in agile projects. However, those activities are spread throughout, not tightly grouped at the beginning.
The concept of doing a little planning and a little designing every few weeks is difficult for many to grasp. They simply aren’t comfortable with the concepts and find it difficult to make commitments and push ahead with software deliveries.
Phases can build a bridge between the traditional linear development model (plan -> design -> build -> test -> deploy) and non-linear agile models (plan <-> design <-> build <-> test <-> deploy <-> repeat). There aren’t any fundamental differences between standard agile development and phased agile development. It’s a matter of focus.
Focus On What Matters — Now.
In a phased agile approach, most of the high-level planning and design work is done during the inception phase. Detailed plans and designs are left for later. This helps to align the business teams and the technical teams. It gets everyone moving in the same direction with same goals.
Most of the detailed design, process flow, and algorithm decisions are made during the elaboration phase. This gives everyone confidence in the solution being built. At the end of this phase, the software is well-defined and the team is ready to pick up the pace and build out the solution.
While the inception and elaboration phases create some tangible business value, most of the effort is focused on intellectual capital offering intangible value — setting up the project and the team for success. The construction phase shifts the focus to delivering real, tangible, business value in the form of working software.
Finally — last but not least — the transition phase transforms the software from good enough to great. While some teams may decide that good enough is sufficient for what the business needs, in most cases, great software is the goal. Never under estimate how hard it is to go from good enough to great. If a software team takes too many shortcuts and makes too many compromises in prior phases, the transition phase may last as long as the other three phases combined!
I hope this series of posts inspires you to try using phases in your next large software project. Drop me a note and let me know how it goes.
photo credit: davidyuweb via photopin cc