Big companies like highly-structured approaches to software development. Why? They’re trying to control and reduce risk. Despite the fact that their real-world experiences clearly demonstrate lack of success, they keep trying. Some of these companies are adopting approaches that apply more rigor and structure to agile development.
The two most discussed (and controversial) approaches are Disciplined Agile Delivery (DAD) and the Scaled Agile Framework (SAFe). Both systems are founded in the Rational Unified Process (RUP — now owned by IBM). While I agree that building enterprise-scale software requires more structure than building small systems, a real danger lies in wait for those trying to adapt RUP. Let me explain.
I was a Principal Consultant and Service Delivery Manager at Keane, Inc. in the 90’s. We used RUP on a variety of projects and I was even quoted on Rational’s website. (This was before IBM bought them.) So, I have quite a bit of RUP experience and I can tell you that RUP is complex — there’s a lot to it.
The DAD and SAFe proponents have done a good job of adapting RUP to agile principles. They’ve reduced RUP to its bare essentials so software projects can be delivered iteratively and quickly. The danger I see is that enterprise adopters with RUP experience won’t be able to resist the urge to simply make RUP more agile by adding daily meetings and deploying software more often.
That won’t work. They’ll end up with water-Scrum-fall.
I prefer to keep things simple — when in doubt, simplify. Forget all the documentation and controls that RUP espouses. Here’s a proposal for applying the concept of RUP phases to story backlogs — just phases. The idea needs refinement but let me put the concept out there and see if anyone can help me clarify it.
RUP has four phases — Inception, Elaboration, Construction and Transition. Sounds like waterfall, right? It does because it is. I won’t go into a detailed explanation of RUP here. For that, I’ll direct you to Wikipedia. Here’s how we might apply RUP phases to a Scrum project. I’m assuming we’ve got a product/release backlog of epics/stories to draw upon.
- Inception Phase – Sprints in this phase, focus on epics/stories that demonstrate the high-level functionality of the software. It’s critically important to get everyone on the same page with regard to what’s being done and why. This is critical because if the stakeholders and power users don’t agree on major features and functions, the project is doomed.
- Elaboration Phase – Focus on epics/stories that prove the system can be built as described. Any uncertainties in the areas of technologies, inter-system communications, frameworks, databases, etc. need to be resolved in this phase. Spikes are a good way to test out ideas and eliminate unknowns. Use them liberally.
- Construction Phase – Focus on epics/stories that build out the major elements of the software and deliver real value to the business. This is the phase that delivers the minimum viable product (or minimum marketable product).
- Transition Phase – Focus on epics/stories that improve the user experience (e.g. search, sort, print, export, import, user personalization, etc.). In this phase, the software goes from being good enough to being great.
Make sense? Clearly, there’s a challenge in deciding which epics/stories fit into which phases. I’m sure there will be many vigorous discussions around that topic. Regardless, if you think about the development effort in this way, it should help the business stakeholders and the software developers to synch up.
I’ll expand on this concept in future posts (starting with the inception phase).