Should we do all our projects using Agile?
Or rather, which projects do Agile approaches suit best, and which do traditional approaches suit best?
Still, the question should really be, ‘What makes sense?’
This is despite the fact that some organisations will go the extreme and say, ‘We can do everything using Agile, from the biggest projects to the smallest’.
But does it make sense for all companies and businesses to think that way?
As Always (Darn), It Depends
First of all, a little bit of context. For some types of businesses, this article is not applicable. For example, website services, app development, and larger software product development. These three business models require a sense of product development flow. These are situations where the product is constantly evolving (hopefully using small changes or ‘batches’).
However, in larger corporate IT environments, things may be slightly different. These environments rarely have flow. Traditionally, they are project-driven environments.
Now back to our dogmatic Agile fundamentalists. They will argue that everything can be done using Agile, and according to their view of the world, everything is product development. Sadly, though, in corporate IT, pure 100% Agile is not realistic. There is too much history, constraint, and frankly, politics.
People, People, People
The culture of such corporate IT organisations is often one of cost reduction. This often results in maximising the efficiency of people and knowledge. Because of this, only one or maybe two people understand one part of the system extremely well, but no one else.
It’s not possible to dedicate these people to projects. In the worst case scenario, I have seen one person dedicated to 15 projects, which made it rather difficult to determine which Agile stand-up she should attend.
These people have to split their time across the projects on which they are working. Corporate IT will be reluctant to invest in a new FTE, because that single existing FTE is enough to do the work, despite the fact that it is not at all effective. Efficient, maybe; even probably. But effective? Certainly not. Let’s not even consider the risk of them being thrown under the bus.
Luckily, the DSDM project management framework does support such a role. This is the ‘technical advisor’. They are called in as a subject matter expert or specialist on demand. However, they are not fully dedicated to the project.
In addition, the portfolio of projects will include projects that are actually just repeated every year. Not only that, but they are done by the same people. And you know something? Those people like it because it provides them with routine and stability.
Of course, there are bigger more innovative projects (or at least there should be). These are the ones where the solution will emerge. The ones that require people with a certain mindset: a mindset of being comfortable in uncertainty. Not everyone enjoys this and it is here where Agile fits well.
So let’s go back to those projects that are repeated every year. What do they feel like? What do they look like? How big are they? Is there uncertainty? Are they predictable? If we have done them for 4-5 years with the same people, then the project is probably predictable. For example, take the insurance business: Every year they have to change the affiliate percentages and goals. It has to be done every year and it’s always the same people making the changes. Do such projects really need to be Agile?
Our projects are so complicated… or complex?
The challenge is to identify the characteristics of the projects. Most Agilists have already come across the Cynefin model by Dave Snowden.
An obvious problem is something simple like ‘I can’t remember my password’. Chaotic problems are like those encountered on a battlefield.
Most interesting for us, though, are the complex and complicated problems. Are our projects complicated, or are they complex? Repeated, predictable projects fall into the complicated quadrant, whereas larger projects that are uncertain and where the solution emerges are in the complex quadrant.
So we have to really think about complex and complicated. What further characteristics do we have?
It Starts with a Gut Feeling
You have to think about the characteristics. This is most easily done using a 2 x 2 matrix: effort vs (degree of) complexity.
But what do the numbers mean?
This is where you have to put a little bit of brains into your work. When we look at complexity, we have to judge a number of things. For example:
- Does the project affect just one team or one department or one division or the entire company?
- Are there certain risks involved, like new technology or other unknowns?
- Are there high levels of political uncertainty?
When we look at effort:
- Are we pretty sure how long it’s going to take?
- Have we done it before?
- Are the people new or do they know each other already?
- How will you allocate the question of external supplier involvement?
So take each project and independently judge its complexity and its effort. Then ask the relevant project manager for their opinion. If there are differences in opinion, then that highlights the need for discussion.
So let’s take a few examples. If we have to change certain parameters in the system at the end of the year like we have done for the last five years, and the same people are involved, then it’s probably low effort, low complexity. So is an Agile approach really necessary?
Then of course we have the other extreme: a completely new technology affecting multiple divisions and involving external suppliers. Clearly this is high effort and high complexity.
So those are the easy examples. More interesting are those that are either low effort and high complexity or high effort and low complexity.
Should these be Agile or traditional? Here, the DSDM project management framework helps us. Clearly, during pre-project, we will not know. At the end of foundations, however, we should have an indication as to whether we want to proceed using Agile techniques or traditional techniques.
It does, of course, fall back to the level of maturity of the Agile skills and the culture of the organisation. If the organisation is more reserved, they may feel like they trend towards more traditional projects and only take the larger projects in an Agile way, which makes sense if supported by the stakeholders. The DSDM Project Approach Questionnaire will help assess this.
Then the individuals involved can be allocated to the types of projects that suit them best. Remember those experts we mentioned at the start of this paper? Well, maybe they can be allocated to the traditional projects as they always have been. And then they can step in to support an Agile project on an as-needed basis in the role of advisor.
I advocate for never holding advisors responsible for delivery, rather allowing them to share their knowledge with somebody who is dedicated to the project. It is that person who then has responsibility for delivery. That way, knowledge is shared, which ultimately results in less risk to the organisation.
As maturity in Agile skills continues to rise, more confidence will be built and the number of non-Agile projects will fall to the bare minimum. Regardless, though, one should always consider what makes sense for the project before beginning.
And You? Have a Think about These Questions (Book 15 minutes if you want to discuss):
- Do you have individuals who specialise in one area, but who are used by multiple projects?
- Do you have repeating projects that are well understood? Are you trying to force Agile on them?
- Where do your projects fit on the 2 x 2 matrix introduced above?