This is the fourth in a series of posts about using RUP phases in agile software development. (Here is a link to the last post in case you missed it.) Let’s continue.
So you’ve completed the Inception and Elaboration phases. That means your team and the business stakeholders have a good, solid understanding of what the software will do, how it will do it, and what it will look like. While the software will be functional at this point, it won’t be ready for serious business use. It’s still a work in progress. Let’s see how the Construction Phase will take the software to the next level.
This is the phase where the team creates real business value. The construction phase is intended to get the software to the minimum viable product (MVP) or minimum marketable features (MMF) stage. I can tell you from experience that defining the “minimum” for an enterprise application is extremely difficult. There will be many conflicting points of view and a tendency to include something for everyone resulting in a large release backlog.
Hopefully, the inception and elaboration phases will help to focus everyone’s attention on what really matters. Rather than simply day-dreaming about what the software might do and how it might do it, stakeholders can actually see some features in action. This will help them visualize the MVP (or MMF) and crystallize their thinking.
The construction phase is often the longest of the four phases. It may take six months or more for a major enterprise project to get through construction. (Shorter is better in my opinion but the reality of big projects in big companies is that they take time — a lot of time.)
Speaking of Shorter
Agile development teams often set sprint durations to four weeks. This gives them enough time to add tangible value and minimize overhead. That’s fine though I prefer short sprints — two weeks. Things happen faster and everyone on the technical and business teams realizes that they have to keep up or be left behind.
So, if you’ve used four-week sprints during inception and elaboration, consider going to two-week sprints during construction. I know the thought of changing sprint length in mid project will cause some wrangling but the whole concept of using phases pushes the definition of agile development. So why not try it?
If you’ve established a strong foundation through the inception and elaboration phases, picking up the pace during construction won’t be a burden. Clearly, there will be features that are too complex to build out in just two weeks. You’ll need to split the user stories into smaller chunks and use feature toggles to hide features until they’re ready for business use.
There’s Always An Oops!
Inevitably, you’ll discover errors, deficiencies and/or omissions in the software design and implementation during construction. The team will need to back-track and resolve those issues. Be sure to allocate time for those activities and don’t forget about refactoring. Some areas of the code may operate properly but could be re-written to be faster and more easily maintained.
None of this means the software must be perfect. It has to be good enough for its intended purposes. It has to operate reliably and with acceptable performance. That’s where the focus needs to be during construction — good enough. In my next post, I’ll discuss the Transition Phase and going from good to great.
photo credit: @yakobusan Jakob Montrasio ??? via photopin cc
Comments are closed.