This is third in a series of posts discussing how project phases as defined in RUP (the Rational Unified Process) can be used in agile software development. My last post covered the Inception Phase. Now it’s time to think about the Elaboration Phase.
If your project made it through the inception phase without getting redirected or cancelled, the team understands what it needs to build and the business understands what it’s going to get. Details remain to be worked out and some things will change along the way, but that’s expected as long as the direction is clear.
Now, in the elaboration phase, it’s time to prove that the software system can be built and delivered as envisioned. If the team is making simple enhancements to an existing system, the elaboration phase will be brief. It could be a matter of simply trying some new libraries or tools and testing a new algorithm.
If the team is building a new application from scratch or making major changes to an existing one, the elaboration phase could extend through several sprints. The core issue is risk reduction — trying out new components, tools and ideas to verify that the end goals can be met.
Most of us tend to be optimists. When asked if a software function can be implemented, we want to say yes. In the face of uncertainty, we lean toward the optimistic and assume we’ll find a way. I’m frequently asked if something is “possible” in the software I build and support. My answer is almost always yes with a qualifier. I let the users know if the “something” the want is easy, moderately difficult or extremely complicated in my opinion. This helps the stakeholders in prioritizing their ideas and requests.
Of course, there are times when something I thought would be easy turns out to be extremely complicated (or vice versa). It’s fine to be optimistic though it introduces risk and it’s important to understand the risks and deal with them early in the project. I try to test my assumptions early so I can seek alternatives, if needed.
That’s where spikes can help. A spike is simply a special type of story that allows the team to experiment, explore and test new ideas. If there are high risk areas in the solution space that need to be tried and tested, the elaboration phase is where they belong.
Software developed for spikes is often tossed whether the spike was successful or not. It’s s done so that developers focus on solving the problem and not on delivering nicely written software. This keeps spikes lean and brief allowing the team to get back to user stories quickly.
By the end of the elaboration phase, the development team should be confident that the software system can be built and delivered using the available tools and infrastructure. If unforeseen problems crop up in later sprints, they’ll be handled along the way.
In my next post, I’ll discuss the construction phase.
RUP in itself is iterative and uses phases. It recommends doing experimental coding in the earlier phases to reduce risk.
If you add phases to agile, doesn’t that mean ending up in Rup?
Thanks for commenting, Anders! In my view, RUP is massive. It contains lots of overhead. I’m focusing on phases — only — because I believe they offer real value. There are many other elements to RUP. If someone else believes that those other elements also have value, that’s fine.
You’re certainly right in that RUP i massive – too massive to even read through the instructions…
So if you compare to full RUP then you are right. But if you compare to a version of RUP where only the relevant pieces are used (which is perfectly allowed by the RUP guide) you would get closer to what you describe. But it would probably still be more heavy weight with more documentation demands than agile with phases added.
So I rest my case and look forward to the next post in your series.
Comments are closed.