I remember getting my Scrum certification. Back in 2009, I was managing 19 people creating software for state-of-the art portal services. Like everybody else at the time, we worked waterfall/PRINCE2 style. I spent a couple of days in an expensive hotel with Jeff Sutherland and I got my certification. I was over the moon. It was a paradigm shift. I’m an Agile fanboy ever since.
Scrum is great. But it’s not the end-all, be-all solution to do projects. Especially my thinking on creating products evolved and I’d like to share my findings.
I started working Waterfall
The Agile Manifesto was drafted in 2001. At that time everybody (me included, I started my career in 2004) did projects in a waterfall style.
Waterfall sure sounds refreshing. But it’s not so great. What was it again? In short: you do the specification and planning upfront, agree on price and then consecutively design, code, test, deliver your work. With a lot of nasty surprises at the already delayed end of a project.
This approach stuck because it is the natural thing to do. And it works, but just for simple, smaller or really straightforward projects. For everything else it’s backward; basically you make fixed plans and hard commitments to deliver a complex system (the software) at a time you know the least of your project. It’s really so bad that at the start of the project you don’t even know what you don’t know.
And it showed. Usually you would deliver late. And often you’d deliver software that nobody wanted in the first place (“We meant something else”) or that wasn’t relevant (“Yes, that’s what we wanted last year, now we want something else.”). All these disappointments were managed by project managers -like me- discussing big contracts and lengthy requirements documents. You would deliver regardless (because the contract) and then fix it up by additional work packages.
Then there was Scrum, a paradigm shift 🤩
The Agile manifesto mainly calls for living up to 4 values to have a better way of working:
- Best have direct and face-to-face interaction,
- working software is the main measure of progress,
- partner with your customer,
- welcome change at any time.
There are many Agile frameworks. You had XP, Lean and maybe EVO, but Scrum really took the cake. ScrumAlliance says that 94% of the companies doing Agile uses Scrum. Jeff Sutherland was one of the creators of the Manifesto. For his teams going from waterfall to Scrum, he mentions a performance gain of 4~5x (yes, that’s 400%).
That’s more or less in line with my experience. The teams I coached in working Scrum usually had a gain of 2~4x. So Jeff does a better job than me. Bummer. But either way, it sure is impressive.
Let’s look back what I learned and how I see the ideal way of working now.
It’s helpful to see what problems Scrum solved for us. There’re 2 big changes in the approach of projects that really makes all the difference.
Scrum welcomes change, anytime
The main issue with the waterfall approach is that you fix agreements on forecasts of work. But the work is unpredictable by nature and you do it at a time you don’t know much. Risky business.
Scrum welcomes changes at any time in the project. And even has a way to deal with the associated cost. Every 2 weeks you can divert from your plans. So, it truly is Agile.
And it’s more fun. It makes that you don’t spend time and energy fighting the rules of a contract. Instead you try to deliver the most value for your customer, whatever that turns out to be.
How I look at it: Scrum is simply a much better way to model your work. You run your project, in the mean time the world changes. This happens all the time. But instead of fighting it, you cater for it.
Scrum breaks down silos
Before Scrum, people making software really had no idea about the world beyond their desk. Not inside or outside the company.
In cases they didn’t know what the other programmers were doing. Or how the backend would handle their call. How interfaces really worked. Or when the servers were in maintenance mode. Only at the very end of a project all systems would be tied together. Fingers crossed 🤞
Scrum’s solution for this is to make a multidisciplinary team; all work should be done by this one team. And everybody needed for the work should simply be in the team or the team should have autonomy to do stuff themselves. Putting in a ticket and wait for the Ops guy to deploy a new version? No, the developers should deploy themselves.
Another big issue was the vast distance between people describing the work (Sales, Business Development, a client) and people doing the work (programmers). This devision of labor yields funny cartoons like this, but otherwise it’s not really productive.
One of the clever approaches in Scrum is to institutionalise ’the customer’. The Product Owner represents all stakeholders. He makes the final decisions on where the product should go. Balancing requirements, wishes, opinions, facts and a vision for the product. He listens to internal stakeholders and represents the end user to the team. It’s a very tricky role. And very hard to do it right. If you want to read up on this role I recommend the excellent explainer video of Henrik Kniberg. Nothing to add.
First this:
Dear Scrum lovers, don’t get angry now. I’m with you. I know the situation I describe here is not strictly described by the Scrum Guide. But I do know that in often in practice it turns out like this. So strictly Scrum is not to blame, but we have a problem nonetheless. Bear with me and read on!
a letter from me to all scrummers ❤️
Problem: Scrum’s solution for The Customer is not good enough
You have to know the Agile Manifesto was largely written by software consultants, and so this ‘customer’ they wanted to have close to the development team was the paying client of the software, not the end user of a product.
So, if developers where in their own silo, end users where from another planet. What a user wanted, how they used the product. All unknown.
Around 2001 software was developed from a technical point of view. Remember, this is how the leading sites of the internet looked at the time and there was no such thing as UX design:
The bigger concern at the time was: Can we build it? And not: How should we make it work? Around this time Scrum came up, and put the Product Owner forward as the voice of the customer. Again, the paying customer, not the end-user.
So, the end user has a voice now, but only by proxy. Your client who knows precisely what his end-users want. A sales rep who brings back quotes from his sales meetings. A requirements engineer who used similar software in his previous role. They’re all stakeholders to the Product Owner, he filters it and takes it to the team. It sure was an improvement, but not good enough.
It’s time for a new Paradigm: One that puts the end user at the centre.
One of the fundamental aspects is that Agile is not about working efficient. It’s about working effective. And I found out -the hard way- that the best way to work effective work is mostly upstream in the development process.
Even if you build your software very lean and efficient, the largest performance gain is building products people actually want to use and keep on using. Products that make them happy and make you money. I think the only way to do that is to build for the end user directly.
Back in 2015, being Agile Coach, I analysed the performance of software teams. We managed to speed up the delivery by 400%. Everybody happy, or so you would think. It was true, we delivered the software faster, and everybody was happy. And the end user? We simply didn’t check it. We never did. So I looked what happend after delivery, when the software was actually put to use… no customers really used it, so it was decommissioned 4 months after go-live.
When we tried to combat this, there was this wonky site about Design Sprints (the book wasn’t out yet). It promised a way to test products before you’d build them in just 5 days. It was too good to be true… so we gave it a go. But it was true. It solved our problems and I had the same revelation as when I started Scrum. Now we were able to filter out the project that would work and just spend our time on useful stuff.
Design Sprints test assumptions about your product before you start building. They’re easy to do and versatile -you can adapt them to test virtually any problem. Design Sprints have a really good uptake. If you do them with the development team they learn if new features will work. But on top of that, they’ll get an unparalleled insight in the end user. I don’t know other ways to get such a broad and deep understanding of the end user in so little time.
The future combines best of all
When I look back on the ways of working there is no definite solution. But remember, you started working Scrum for a reason. You didn’t want to work Scrum, you wanted to work more efficient, more user-centric, with shorter lead times, more fun. Whatever it was for you, Scrum is a means to an end. Not the end itself.
The ideal way of working combines all the best methods out there. And you should keep refining it. For everybody working Scrum, I propose 2 things to improve:
1. Really know your end user
Everybody in the team should talk to end users on a regular basis. Observe them interacting with your product. Why and how they use your product. If you’re in a backend team, go visit the front-end programmers using your API, reading your documentation. If you’re part of a front-end team, go see a customer. Record them using your product. If you make FMCG products, go to a retail outlet to observe the buying decision.
Only this will make that you create really good products. That convince both your end-user and your customer.
2. Define success as User Goals Achieved
Also we should stop defining success as software shipped. But rather as user goals achieved.
An example: You run an e-commerce site. To make checkouts faster, you add Credit Card payments. Now, don’t mark your work as done when the story or epic is coded, tested, deployed. Say you’re done when customers on average spend at least 1 minute less in your payment screens.
Only this way we stop fooling ourselves that features or software is something users want. They want solutions to their problems. This’ll keep you focused on the end-user and you break down Business-IT silos at the same time. Powerful!
Design Sprints for Scrum Teams
An easy way to make this change happen is to give teams more autonomy.
I’m an advocate of giving teams -or maybe the Product Owner- more responsibility. And so I think teams working on software should do their own user research. To shift focus from stakeholders to the end user. Because ultimately, only when the end user is happy, the stakeholders are happy.
User research is easy to learn for any team. Perhaps not PhD-grade research, but fast and good-enough research. I do Design Sprints for Scrum teams which do exactly this. It’s a special format where we use 1 Scrum Sprint (that’s usually 2 weeks) to validate assumptions and quickly execute what’s possible. Without disturbing the established Scrum rhythm. And you’ll be amazed what you can do in just 1 Sprint.
If you want to know more on that, DM or mail me.
Be Brave
Some final words of encouragement. This approach doesn’t clash with Scrum per se. But it does require a change in your current Agile/Scrum practice. And as such it requires bravery to do things different.
I hope you will, though. Because other Product Owners at other companies will do it. And whoever does, will take the cake. Yummy 🎂.