IT projects failures are unfortunately not uncommon. We hear stories of projects that never deliver, projects that are either late or well over cost. One of the main reasons identified for this is Scope being out of control.
In waterfall projects all the scope is identified at beginning of the project, when we engage with our customers here the emphasis is on making sure we have all the requirements as it will be expensive to change them further down the process. Therefore the customer imagines all the things they could possibly want out of this project and typically they throw everything in including the kitchen sink, because they know it will cost them if they think of it later. The result of this is we build a lot of features that have little value and/or will never be used.
Also because the customer is often only really engaged at the requirements gathering stage, as the requirements are handed off from one group of specialists to another, defects start to creep in. See tree attachment for illustration of this idea, the clasic cartoon.
Worse still what the customer wants by then end of the project has probably changed, their business has moved on. The end result can be mistrust and blame between the customer and the IT supplier.
Scope Management in Scrum
In Scrum we embrace change, we accept it happens and we try to keep the cost of change down by ensuring a constant flow of valuable software to our customers, using good engineering practices which keep the cost of change low and by involving the customer throughout as part of the team. Yet I still come across Scrum projects that struggle around scope, where the customer perceives they are not getting what they asked for, and that mistrust starts to build up between the customer and supplier.
It is widely accepted that in a software project you can’t fix Cost (people, equipment, etc), Scope (what we are going to build) and Time (when we are going to finish), otherwise it is ultimately Quality that suffers, because we work our team harder, or we ask the team to cut corners, usually both. Yet our customers want to know what they are going to get for their money and when it is going to be finished. Unfortunately this is where as an industry we fail, rather than saying ‘I’m sorry that’s not how it works’, we are all too ready to fix all the corners of the iron triangle, even though we are setting ourselves up for failure or at least a good chance that it is perceived as a failure.
Our customers are so used to getting their demands accepted by their suppliers that it makes it very difficult to get them to see that they would get a much better product if they didn’t fix scope, cost and time. I could talk about what to do if you have fixed scope, cost and time, as many Scrum projects end up that way, but I am not going to because I think we all have a duty to try to change that. Whatever approach you take in software development fixing them all will increase the chances of failure.
In Scrum it is usually Scope that we see as the best variable to be able to adjust. We know we have a big release at the end of July and we have got a fixed budget, therefore scope is the one left open to us. Scrum allows us to Inspect and Adapt so we can always make sure we are building the most important features, this works only if the customer (Product Owner) is involved throughout the project and they understand how to maximize their return on investment.
The Scrum projects that I see struggling with scope are usually those that haven’t got a customer working as part of the team, or they don’t understand how to behave as a Product Owner. The key is education, education, education and we need to start as early as possible. When the contracts are being signed make sure we don’t set ourselves up to fail, engage with the client and do everything possible to persuade them that by working together we can achieve the best possible results. It always amazes me that customers are prepared to hand over all that money and responsibility to the supplier; they wouldn’t do that for any other complex project, so why do they do this in software development? Because they don’t understand it scares them, it is easier for them to hand off all of the risk to the supplier. It doesn’t have to be this way, make it a collaborative venture, play the game together and share the risk. Make our contracts more about how we will work together, possible future blog.
When you have your customer as part of your team, make sure they know what is expected of them. Education is one of the responsibilities of the ScrumMaster. The key thing that teams struggle with is their scope not being managed well; make sure the Product Backlog is in a good shape for planning. In a future blog I will look at Product Backlog farming, the ongoing effort the product owner and team need go through to make sure the backlog is just good enough for Sprint Planning to occur.
If the Product Owner has an understanding of the teams velocity and has an estimated Product Backlog, they will be in an excellent position to make trade off calls around scope. I often find that teams don’t have a Product Backlog Burndown, this is a sign that teams don’t know where they are in terms of burning through the work. We measure ourselves against how much working software we have done, therefore the lack of a Product Backlog Burndown is usually an indicator that we (including the customer) don’t know how much work is left. A dangerous position to be in and one that could lead to the blame game, when it turns out we are not where people assumed we were.
Summary
· Don’t fix scope, cost and time, we need to change the expectations of our customers.
· Involve the customer as part of the team; make things visible to them throughout.
· Educate the customer so they understand what is expected of them, give them training.