Blindingly Obvious Demand Management Part 3: Traditional or Agile?
What’s sensitive about your project? Educating the Business in methodologies.
So you’ve confirmed that a project is strategic for the organisation, you have the capacity to address it, and now it’s development time.
As we know there are only three variables we can control when we run a project:
- Time – duration of the project;
- Cost – usually this means the number of project members;
- Scope – sometimes linked to quality.
It’s a three-way balancing act: If you’re given more time, you can probably complete the project with the people and quality required. If you have scope creep, you’re going to need more people or more time. If you are on a tight budget, something’s got to give: usually scope or quality.
What’s important about this simple and well understood principle is that we can use it to help business people articulate the sensitivities of their proposed projects, and thus help everyone, (development group, governance committee and other stakeholders) to decide what’s the appropriate development methodology: traditional (or waterfall) or iterative (or Agile) for the project.
What just happened then?
To clarify: it’s unreasonable to expect a business person to explain the criteria for why their project should be directed through to the SAFe (iterative) team, or indeed why it shouldn’t be directed through established software engineering processes in the traditional way. Clearly they just don’t have the expertise to do this. They’ll walk out of your planning meeting saying what just happened then?
But they are extremely well qualified to point out the relative importance of time, cost and scope for their proposed project. For example, if Finance wants to revamp accounts receivable processing, they know that time is not so important, but there’s no compromise on scope/quality – it just has to work first time. Unless of course the project is in response to mandatory corporate reporting standards for the new financial year – in which case time is critical, so we may have to allocate more money for additional resources. Maybe it’s a one-off project to try new technology in the market – we could be flexible with scope but time to market is critical. And finally if it’s critical that the budget not be exceeded, then maybe they’re prepared to talk about reduced scope, or a less sophisticated architecture rather than the latest and greatest.
The power in this conversation is in the shared meaning that both the business and the development team understand here… we’re not talking Agile, or architecture, nor even technology, just the three variables of any project.
The result is that applying your governance rules to these three factors around the project allows you to make the call on flexibility of resourcing, duration, team makeup and importantly, development methodology: Traditional or Iterative.
Before you scoff at me, I know there’s more to it than that. However in my experience the problem usually stems from that lack of shared understanding of priorities between the business and the development team, and this gives you a common language to discuss priorities and thus an agreement where all parties actually understand what just happened then.
Comment, call or email me to discuss.
Rob.
