In this article, part of my series explaining better ROI from software development, I’ll be looking at the individual ROI benefits of component parts of Scrum. If you are not familiar with Scrum, please refer to my primer here
A brief note on intended audience; this article is not intended as a training guide for Scrum. There are a lot of resources out there. Much better than I could every produce. This is much more an introduction from a Return On Investment perspective aimed at business leaders.
As discussed in my previous article, be careful not to fall into the trap of cherry picking the “best bits” from Scrum.
Greater minds that you or I have produced the work and it is firmly intended to be used in its completeness.
Only when you have battle tested experience would I recommend stepping off the beaten path.
Ok, with that disclaimer out of the way, let’s look at some the ROI sources.
One of the biggest dysfunctions I find within team is trying to cope with multiple competing priorities. The demands on the team far outstretch their capacity, which will generally result in the team bouncing between different work.
Multitasking is inherently ineffective. The cognitive overhead for a developer to switch between two subject is surprising high. If you interrupt a developer deep in thought for a “quickie”, you will destroy their cognitive flow – which will take time to re-attain. So while interruption was literally 30 seconds, the impact to the developer is likely to be between 15-30 minutes. That is obviously a huge impact on their productivity, and thus a direct hit to ROI.
One of the key roles I see of the Product Owner is to provide that insulation between the business and the development team. The Product Owner can establish if your 30 seconds request is of appropriate value to impact the team now … or if they can be handled at a more appropriate point.
This insulation extends probably more importantly to the projects the team are working on.
The Product Owner should be making sure that the project up next is of the highest value to the organisation (basically best ROI). Without that it is common for a team to be working (or shuffling) between who shouts loudest at any given minute.
The Product Owner should act as a gate keeper to ensure that projects are ready for development. While I’m an advocate of evolving a project while it is being developed, there will be ideally a good sense of what is being developed and the dependencies are available. If that isn’t the case, then putting the project to the development team will just be hugely ineffective (and thus poor productivity) because they are waiting on answers/ dependencies.
And if a team is waiting, then it isn’t uncommon for them to try and pick up other work (if nothing else to look busy). When the original work becomes ready to do, they are then committed to two pieces of work. Again causing a lot of cognitive flow and productivity issues.
The Product Owner roles is one of my favourite parts of Scrum.
Imaging you buy a sports car. It’s great it goes fast.
Now imagine overtime, the more you drive it, the more the car is refined to go even faster. It becomes more fuel efficient. It is much more than it originally was.
How great is that?
This is very much like the Sprint Retrospective.
Your team have a level of capability and competence. That could be great. It could be poor. Most likely it is somewhere in the middle.
Now imaging every couple of weeks an F1 pit crew turn up, look over the work the team have done, then make some tweaks to the team. Maybe they change the fuel mix. Maybe they adjust the suspension. Maybe they purchase superior tyres.
The pit crew send the team off, and then repeat a couple weeks later. They find that some the tweaks produced positive impact, some negative, some no change at all. They rethink and make some more tweaks. And round-and-round the cycle goes.
This is what the Sprint Retrospective is (just without the pit crew - and the rather tenuous F1 analogy).
The team are actively looking to improve and become for effective … and thus more productive. Which of course has a positive impact on ROI.
Ok, you are investing a few hours per Sprint in them having that time, but the pay-outs can be considerable. It is isn’t uncommon for an improvement to come out that maybe saving your team minutes to hours per week. That soon builds and provides a really a very rapid return – sometimes within a single sprint.
Ok, some of the changes coming out may involve spend (new software, hardware, etc) – but again generally these will be fairly short returns on any outlays.
Once a team feel empowered to improve they will constantly be looking for improvements and refinements. Motivational wise, this is a winner as they feel that they are being put in control of their destiny. As I’ve said before, self-motivation is one of the biggest keys to greater productivity.
Again one of my favourites
Ok, let’s take a step back on the Scrum Master role.
The Scrum Master is possibly an unfortunate title. It is easy to get images of someone banging the drum at the back of the slave ship.
A Scrum Master is not a project manager. They are not a “chaser”.
They are a “Servant Leader”.
And if I’m honest, the Leader part of that can itself be misleading.
They are there to help the Scrum Team be the best they can be. That is through training, advice, guidance and assistance. It is not through prescriptive micro management.
They should be that servant to the team.
As an aside; I read about one Scrum Master taking this metaphor too far and being the person that always made tea and coffee for the team. He was trying to help the team by removing the need for the distraction. This is ultimately a dysfunction because the team is reliant on the Scrum Master for the tea & coffee. The Scrum Master should have been training them how to make tea & coffee, making sure that the tea & coffee supplies where provided in a timely manner.
Make a developer a coffee, he drinks it. Teach a developer to make a coffee, then they will always have coffee.
Ok, so that was a little contrived, but hopefully I’m getting the point across.
The one place that the Scrum Master should be banging the drum is adherence and adoption of Scrum and its principals. The Scrum Master should cheer-leading the team to be better and better. They won’t be able to force the team to be better and better.
And with better comes self-motivated, enabled doers. With that comes greater productivity.
The definition of Done is an easy one to bypass.
But take a look at the growth of “charters”. Public promises being made by an organisation committing to certain behaviours.
Ok, putting aside the obvious marketing angle, these define what should be expected.
Within software development, it is very easy to have ambiguity. It is not uncommon to reach the tail end of a project to find tasks unplanned as nobody believed it was their responsibility.
At which point, you are instantly losing productivity resolving it AND the inevitable bun-flight over why the problem occurred in the first place.
Factor in a fair amount of animosity between teams over a period of time which makes every engagement much harder than it should be … and voila, lots of productivity down the drain (you can almost see the cash float away).
I have personal gripe over blame cultures. The short version is that they help no one and provide exceptionally poor ROI. The longer version I’ll maybe blog about in the future.
Ok, so back to the point in question.
The definition of Done is a clear charter of what is provided. A lot of ambiguity is gone.
That same charter is also then a focus for improvement (coming out of the Sprint Retrospective). This will, over time, lead to better and better quality.
The Scrum Review is providing you with great means of breaking down barriers between teams (especially the stakeholder and the developers) and a means of making course adjustments relatively quickly.
Let’s first look at that breaking down of barriers.
It is very easy to make assumptions and mistakes when there isn’t a built up understand and empathy between two parties.
If you are removed from your development and the only updates you get are through status updates – all you know is if everything is fine or not. No levels of granularity. More often than not, the only time anything will come to your attentions is when it is considered Red on a RAG status. At which point you’re engaging from negative place.
If however you are meeting with the team and letting them show you the work they’ve done over the past Sprint, along with any problems – then you are in a much better position to have empathy for their day-to-day work. The same is true that they will have much more empathy with you if you are able to engage with them.
Empathy helps towards motivation. Motivation helps towards productivity. Productivity helps towards ROI.
How often have you dealt with people based on pre-conceived conceptions, only to have to alter once you can see the whites of their eyes.
This is a real helper to make a “team” feel with everyone brought in.
What would you prefer – you have to have all the ideas? Or you have a team of motivated & engaged idea generators?
And then there is the second point, the ability to make course adjustments.
I’m reminded of an anecdote that I hear once;
This father picks his young son up from school. The traffic is terrible and it taking a long time to get home. His son remarks that he wished they were on the other side of the carriage-way, where the traffic was flowing freely. The father comments that in doing so they would be going the wrong direction. The son, somewhat disgruntled, remarks “Yes, but we’d be going fast”
How common is it for a project to focus on speed rather than going the right direction.
The Sprint Review actively pushes the wider team into that conversation of if they are heading the right direction. If they are, great, keep going.
If not, great, let’s make that course correction.
This is one of the fundamental ROI impacts of Agile development – fail quickly. Much better to accept that it’s wrong after a 2 weeks sprint than 12 months development project.
And let’s be fair here; the project maybe going the wrong direction for any number of reasons:
Again this all comes back to making sure that the development team are working on the most valuable projects for the organisation. That can (and will) change over the course of time.
The Sprint Review helps with that process by providing that scheduled review, produce feedback and act on it.
And finally (although I could probably write a lot more), the Sprint timebox itself.
I’ve pretty much covered the benefits of rapid reviewing, feedback, act above.
The Sprint timebox helps maintain some structure round that.
If you have a two week sprint – great, then you have all the necessary activities scheduled in every two weeks to handle that review, planning, act loop.
Without it, you can either become too lax in your approach (too busy, don’t have the time) or too zealous (paralysis by analysis or poor productivity through very fast changing of priorities).
At the end of the day, it helps you control that investment.
Ok, I’ve said lots of nice things about Scrum. Now we need to think of some of the pitfalls to consider. As I’ve said in previous articles, it is not going to solve all your problems.
I’ll look into that in the next article.