“Scrum is Hard and Disruptive” - Ken Schwaber

If you didn’t read the first part, I would suggest that now would be an excellent time to do so.  It’s certainly not required, but it will provide context for this post.

Go ahead, I’ll wait.

So here we are, in the throes of a soul-killing transformation to Scrum that wasn’t actually one.  The general feeling in the Development team was to throw Scrum out as a total disaster and go back to what we were doing.  Even when we knew that waterfall was evil, it was at least kind of functioning, and we were putting out working software sometimes.

But there were rebels.

Rebels who were familiar with how Scrum is supposed to work, or who spent some time with Google and learned, knowing that something was terribly, terribly wrong.  Many a blog was read, many a book was purchased and consumed.  And a plan was slowly concocted.

Before I lay out this nefarious plan, a caveat.  I don’t actually recommend this plan.  It worked for this group of rebel scum, but we got lucky.  And yes, I was most certainly one of the aforementioned rebels.  While we were sure it would work – and ultimately it did – it could just have easily exploded in our faces.  

In order for the nefarious plan to succeed, there first needed to be a critical sea change.  At the top of the management chain.  A new executive joined the company, and brought new energy along with him.  This forced the VP oft mentioned in the first post to back off, and paved the way for change.  (The VP was, in fairly rapid order, no longer with the company).  A true Agile transformation needs to have buy-in vertically throughout the organization.  It’s not necessarily top-down, but top level management has to be on board.

We didn’t actually do that, instead deciding that we would rather ask for forgiveness than permission, and we acted. The words “Agile” and “Scrum” were poison, so we had to spin it and take a different approach.  How to get the team to embrace Scrum, without ever telling them what they were doing?  Almost every term associated with Scrum was out.  We needed to be stealthy and get everyone on board with the idea of just being awesome again, and let’s try things to do that.  But this time, rather than coming from a VP with a decree, it was coming from two or three peers who just wanted us to be great and have fun.

We liked the idea of Sprints.  That’s literally the only thing we kept completely intact, setting a consistent two week cadence.

We recognized that the one ceremony people felt was at least sort of useful was the Daily Scrum.  Our first step was to just call it a stand up, which is not uncommon, and to change how it was run.  Hours were obviously gone.  We moved to an actual board, and we suggested that we change the conversation to a story by story basis, rather than focusing on individuals.  The Three Questions were history.  This took the pressure off people and refocused the conversation on the actual work, and how things were progressing.  I became the Scrum Master, but to the team, I was just the guy facilitating the meeting.  There was to be no mention of the word Scrum.

The 20 person Dev team was divided into manageable sizes.  Some of this was done from management (definitely a Scrum anti-pattern), but for now, we were fine with this compromise.  The teams weren’t in a place to self-organize at that level yet.

Retrospectives had to be completely overhauled.  For a long time, we didn’t do them.  When we started to notice that the teams were starting to talk about how to improve, we jumped.  We started post-mortem ceremonies at the end of every sprint, before we did any planning.  We stopped just going around a table and asking people what they thought, but started to make things more open-ended, giving team members a chance to have a discussion, and asking thoughtful, leading questions to steer the discussion toward arriving at SMART goals on how to adapt going forward.

Sprint Planning became a real thing, and the team became engaged and involved with the work they would be doing.  To begin with, estimates were out the window, because we wanted to break the habit of trying to break down everything into hours.  We simply asked the question “What do think the team can complete during this Sprint?” and built the backlog accordingly.  Burndown and Burnup charts weren’t important.  All that mattered was that the team agreed on what they could do, and that they got it done.

At the same time, we started to preach two important things to the teams:

1. It’s okay to fail.
2. It’s better to under-commit and over-deliver than the reverse.

We did shorten to one week Sprints for a long time, to help establish cadence and the discipline of limiting work to what could realized during the sprint.

The energy began to change, and the team was feeling like they could do anything.  Everyone was talking, instead of building silos and sulking.  People were excited about what they were accomplishing, no matter how difficult the work.  Our Product Managers became actual Product Owners and were integral parts of the teams.

We were learning together, and helping each other along the way.  If you fell, there was someone there to pick you up and help out.  The basic “Cover Your Ass” mentality stopped, and the teams began thinking of themselves as teams!  This was the breakthrough we were waiting for!

Somewhere around here… we let the cat out of the bag.  The team was (mostly) doing Scrum.  We just weren’t calling it that.  But this was now a good time to start using the right language, and to look how far we had come as a group!

We might have been called sneaky bastards.  We might have high-fived immediately after that.

Somewhere during this process, we introduced CI builds.  We introduced nightly full staging builds for QE.  We started writing unit tests, and showing them to everyone like we had just made a new discovery.  Not everyone bought into unit tests right away, but they saw how they could be awesome.  (We also got heat from a senior engineer/team-lead type for bringing unit tests into the picture without asking him first.  I suspected it was because he was afraid testing might uncover how fragile his code was, but have no proof of this).  We got people thinking about how to refactor code, and that spending time writing clean code up front was better than writing something quickly and ending up with a code base more unstable than a house of cards.  Tech debt started to slowly get paid down, and engineering practices leveled up!

All that said – this was not easy!  There was a lot of work that went into making these changes, and it had to be done with care.  We were met with resistance on many levels.  We were challenged on almost everything.  Some people just didn’t get it, others didn’t see the value in what we were trying, others probably saw through our thinly disguised charade and declared there were shenanigans.  You know what?  All of those people who resisted were right to do so!  We barely had permission to do what we were doing, and the approach we took flew in the face of any so-called conventional wisdom.  There were many days when we were just making it up and seeing if it worked, and sometimes it showed.  But we eventually got there, and created high-performing Scrum teams out of actual chaos. 

Don’t be afraid of tumult!  Instead, see how you can harness it within your organization to push toward your ultimate goal.  We recognized the chaos we were left with, came up with a plan, and worked slowly and calmly to create something awesome out of that initial chaos.  Use the energy that lives in the tempest to create your own awesome!