How do you lead change in your software organization?  How do you get your teams to care about doing a good job?  How do you get them motivated to try new things and/or improve?

It's been 14 years since the Agile Manifesto and Scrum's not so young anymore.  The idea that Agile and Scrum are the crazy ravings of sandal-wearing hippies has faded.  Scrum and Agile have clearly had a huge impact on the software development world.  They're mainstream.  They're accepted.

That acceptance comes with its own set of problems -- especially when it comes to leading organizational change and staying motivated.  When you're trying to lead/drive change in an organization, it helps a lot to have a good story because stories are such a huge part of how humans think and organize in order to accomplish something.  A good story describes the mission -- the quest -- that we're all on.  And every good, compelling story needs a villain -- something to be challenged and overcome.

In the Scrum/Agile world, that villain used to be the Waterfall process with its tyranny of Gantt charts and arbitrary deadlines.  You could talk about all the clear and present dangers of Waterfall and the near infinite number of failed projects that had collapsed in Waterfall's wake and that was enough to motivate an organization to (at least start to) change.

But really, how many people actually even do Waterfall anymore?  Not many.  In fact, I'm not sure that I can remember the last time that I saw someone working in Microsoft Project.  The War on Waterfall has been won.  But what took Waterfall's place?

Nothing in particular.

Nothing in Particular

When I help teams adopt Scrum or improve their Scrum process, usually what we're battling against is the "nothing in particular" school of project management.  They don't use Waterfall because "everyone knows that Waterfall doesn't work" -- but what do they do instead?  Nothing in particular.

Nothing in particular isn't a particularly inspiring villain though.  It's tough to motivate people by saying "we have to adopt Scrum to combat the scourge of 'Nothing In Particular'".  It just doesn't ring.  I mean, entropy is eventually going to lay waste to the whole Universe but who lays awake at night worrying about entropy?  Answer: nobody.  And nobody worries about the scourge of "nothing in particular" either.

Why Should I Care?

It used to be enough to say "we're doing Scrum because it's not Waterfall" but without Waterfall as the bogeyman, a lot of organizations have lost their focus on Scrum/Agile.  They've lost touch with why they should care and need new ways to be inspired.  In organizations who have been doing Scrum/Agile for a while, it's a matter of remembering why they went to Scrum in the first place.  For organizations who are new to Scrum/Agile, it's about helping them understand what the benefits are and could be.  For both types of organizations, it's essentially reminding them about the benefits so that they can internalize why they should care.

It helps to make a positive, affirmative case as opposed to a negative case.  Identify what you do, what you are, and who you are rather than what you are not.

Five Reasons Why We Do Scrum (aka. Five Reasons to Care)

Here are five suggested reasons to care:

1. We're doing Scrum because it helps to keep ourselves honest and notice when things are not going well. You know the "check engine" light on your car?  It doesn't tell you what's wrong with your car.  It just tells you that there's some kind of a problem.  In Scrum, your "check engine" light is whether or not the team delivered done, working software at the end of the Sprint.  No done, working software at the end of the Sprint?  Well, that's a pretty clear indication that something went wrong.  And now that you've noticed that something went wrong, you'll probably want to have a discussion about why.
2. We're doing Scrum because it helps us to focus on real, actual data. Let's assume you made it to the end of the Sprint without the "check engine" light coming on.  In other words, the team delivered, done working software.  Ok.  Great.  How much done, working software?  Was it the amount of done, working software that they forecasted that they'd deliver?  In short, what was the Velocity for the Sprint?  Velocity gives you the vital information so that you can help predict the future.  Rather than 'what did the team wish that they could have gotten done', Velocity helps you to focus on what they actually *DID* get done.  From there, you can start to use their actual historical performance to predict and forecast what they're likely to get done in the future.  That's real, actual data as opposed to guesses.
3. We're doing Scrum because self-organization helps ensure an engaged, intrinsically motivated workforce. If someone tells you exactly how to do your job right down to the last micro-managed detail, you're not going to feel all that creative.  If you don't have the chance to solve your own problems and use your own natural resourcefulness, you probably aren't going to feel all that inspired.  If you're being forced to hit a bunch of arbitrary dates rather than meeting the goals of your organization, you're probably not going to be overflowing with intrinsic motivation.Scrum thrives on self-organization.  Give the team a goal and let them figure out how to meet those goals.  Humans thrive on that, too because it helps them to feel invested in what they're doing.  It gives their work meaning.  Work on something meaningful and the motivation to get it done well flows naturally.
4. We're doing Scrum because it helps see The Big Picture of our organization and our delivery process. The Sprint Retrospective Meeting at the end of each Sprint gives the team time to discuss what went well and what didn't go so well.  An effective and productive Sprint Retrospective doesn't constrain itself to just what happened on the team -- it will likely examine and discuss how the team interfaced/interacted with other teams and with its organization as a whole.  What went wrong or what went well might not have originated with just that team and because of that, a good Retrospective will tend to broaden the awareness of the team members so that they're thinking more holistically about the needs of the organization and how they deliver software in order to meet those needs.And if you've got multiple teams in your organization and you're using Scrum itself to manage Scrum at scale (see Nexus & Scaled Professional Scrum), you'll be using your Nexus Integration Team to help keep a handle on all those inevitable cross-team dependencies and integration problems.
5. We're doing Scrum because it help us to focus on continual improvement. The Retrospective Meeting typically ends with a list of things you'd like to improve and a small handful of items that you intend to improve on the next Sprint.  You're not going to change the world in a single Sprint but you are going to acknowledge that there are things that can be improved.  That list of things that can be improved will tend to get longer.  There are always things that you can work on to get better at how you all work.  Chip away at them.  Work on the improvements gradually.  Strive to continually improve.  Strive towards mastery and getting just that little tiny bit better at your job day over day.  All those little pieces of improvement really start to add up over time.

-- Want to adopt Scrum but you're not sure how to start?  Trying to get multiple Scrum teams to play nice and deliver together?  Need a Scrum tune-up?  We can help.  Drop us a line at info@benday.com.