Agile Transformation is hard.  It takes commitment from the entire organization, and a long term plan on how to get there.  Getting everyone to Agile isn’t just a matter of flipping a switch and making it happen.  It can take years to get there.

Makes sense, right?

You would think.

This is not a case-study, or a scenario I made up to illustrate a point.  This is a real world tale of watching a failure happen before my eyes, and the impact it had upon the company.  The name of the company and any individuals involved have been eliminated, but everything that happened is essentially as described (some things have been omitted for the sake of relative brevity).  Those of you who know me and worked alongside me may recognize what follows.

Want to make sure your Agile transformation succeeds?  Take heed of the many mistakes herein.

In the beginning, this was a 100% waterfall shop.  Not a line of code was written without a detailed requirements document, nothing was tested until it was completely coded.  Spending large amounts of time doing nothing but bug fixing prior to a release was not uncommon.  Why?

“That I can tell you in one word: Tradition! (Tradition, tradition… tradition!)”
Yes, it was as shaky as a fiddler on the roof.

Then one morning, everything changed.  That morning, the entire development team was summoned into the conference room.  The VP of software development told us “We are an Agile shop now”, and gave a basic Death by Powerpoint overview of how Scrum works.  We were now a Scrum team of ~20 people, and the VP was the Scrum Master.  There was no coaching.  There was no servant-leadership.  It was a textbook example of “What is thy bidding, my Scrum Master?”

The Product Backlog was a spreadsheet that he maintained.  Oh, did I neglect to mention that he was also the Product Owner?  He didn’t say that…but he was.  There was no Sprint Backlog, we worked completely off the Product Backlog and he guarded it rigorously.  The items in the Product Backlog were not actually user stories, they were line items from a larger requirements document.

The only ceremony that was regularly held was the Daily Scrum.  We were told there were three questions that we had to answer every morning:

• What did I work on yesterday, and how long did each thing take me?
• What am I working on today, and how long do I think each thing will take?
• Do I have any blockers?

As you answered the first question, he would add up the hours, and if you came in anywhere less than eight, you got the added bonus of “That isn’t a full day’s work.  What else did you do?”  If you took longer to do something than he had estimated in the master spreadsheet, or didn’t finish something, you would be held accountable immediately for the missing time.  This also applied for the 2nd question.  There needed to be 8 hours of work, or you were clearly slacking.  100% utilization was required at all times, and there was no room for any deviation.

Impediments were not addressed in a meaningful way by the VP Scrum Master.  His method of removing an impediment was to tell the developer to “call that person on the phone after this meeting”.

Work was routinely assigned by the VP (or one of his designees) to individuals.  Because there was no actual Sprint Backlog, the team was expected to just do absolutely everything.  There was no commitment, there was no feeling by the team that they were in any way in control.

The Daily Scrum – time boxed to 15 minutes – would routinely take 45 minutes to an hour, as 20 people gave a detailed status report.

Nobody walked out of a Daily Scrum feeling empowered.

Sprint Planning?  Nope.  The VP used the estimates in his spreadsheet and decided what we would work on that week, based on a fully loaded 80 hours.  He would have a border line on the worksheet to indicate what he expected to be completed.   Work items were routinely carried over, because it was literally impossible to complete everything during a single sprint.  We didn’t plan, we just kept working down the never-ending spreadsheet that was planned for us.  Sprints were routinely extended by a week or more.  To make it worse, a sprint that was extended would often be extended again.  Timeboxing meant nothing.

Quality Engineers were invariably running a sprint behind, if not more, because coding was happening right up until the final hour, if not beyond.

The Sprint Review?  That didn’t ever actually happen.  There would be the occasional demo, but that’s as far as it went.

Retrospectives?  We held those about half the time.  They weren’t meaningful in any way.  We would go around the table and talk about what we did well and what we didn’t do well.  The VP spoke last, and used the retrospective as a forum to tell the team how we messed up.  For every thing the team felt they did well, he would often have two things that he felt were just horribly wrong, and would take advantage of the captive audience to harangue the team.  There were no action items identified, there was no opportunity to inspect and adapt.

Nobody walked out of a Sprint Retrospective feeling empowered.

In addition, there were routine defect triage meetings.  Every single defect that was logged would be reviewed, discussed in detail, and the person assigned to that defect would be asked about the status and when it could be complete.  This was separate from the Daily Scrum, and team members were responsible for both.  These meetings could easily take up to two hours.

Nobody wanted to attend the triage meeting, and absolutely nobody walked out of one feeling empowered.

The mindset on the Development Team became “Cover Your Ass”.  Because estimates were all in hours, padding your estimates became automatic, just to protect yourself.  If asked why your estimate was so high, it became routine to make up some nonsense about not being familiar with the code, not able to reproduce a defect, or just that there could be downstream effects that you need to make sure you take into account.  The padded hours became a way to account for time that you couldn’t otherwise account for, just burn off an extra hour here and there, and it would balance out.  Engineers seemed to be viewed not as professionals, but as mere code monkeys, any of whom could be easily replaced.

The VP definitely had favorites, and he protected them.  He also had people who he regularly singled out as being problems; those people could do the most amazing work in the world, but they would be expected to do more, and the smallest defect became a showstopper.

It wasn’t safe to fail.  Failure meant you were bad.  Period.  There was no room to experiment.  There was no time allocated for that, you had to stay on task and on your estimates.

There were no unit tests.  There was no time for that.

There was no build automation.  A full build took a day, and there was no QE work until a build had been completed.  Obviously, it follows that QE spent long periods of time with little to do, followed by days of being completely buried as all the development work hit them at once.

Morale was the lowest I have ever seen, anywhere.  People stuck around because we truly enjoyed working together, or in some cases simply because they needed a job.  Everyone wanted to do great things, but felt like it was impossible.  Everyone knew waterfall was awful, but everyone would have gone back to it in a second, given the chance.  Getting up and going to work in the morning was hard, and PTO was routinely suspended.

Obviously, reading this, it’s clear that the company was not doing Scrum.  This was a bastardized form of Scrum; using the Scrum terminology, mixed with a bit of waterfall, and a lot of micromanagement, all in the hands of someone who needed to be in total control of everything.  The VP may have had the right idea in trying to start a transformation, but how it played out was just short of full disaster.

The mistakes above are so numerous that were I to get into detail on each one, this would be a novel-length post.  In future posts, I anticipate that every single problem there will be touched on in some way.  There are a few, however, that are so egregious they must be touched on while in context.

• You can’t simply become Agile by saying “We are Agile”.  That’s the equivalent of your child telling you “I’m a monster” and making growling sounds at you.  It’s amusing, and it gets annoying after a while, but nothing has actually changed.
• There is NO place for the evil “how long did X take you” question, or any inference of it.  Not in the Daily Scrum, not anywhere.  Hours are not actually important.  Tracking time for accounting purposes is different, and has nothing to do with Scrum.
• Every Sprint should have a Goal, and everything done in the Sprint should be working toward that goal!  Without a goal, the team is just doing stuff.
• A 20 person Development Team is at least two times larger than it should be.  We should be aiming for Development Teams of 3-9 people, with a number somewhere in the middle likely being the sweet spot.
• The Development Team owns their work, and self-organizes to get it done.  The work is not assigned by upper management to a particular developer, and the Development Team works with the Product Owner to determine what work they are going to take on during a sprint, in order to deliver the maximum value.  This isn’t an endless list of work that is unmanageable!
• Repeating the above: the Development Team owns their work.  This includes design and QE.  Everyone is responsible for getting User Stories to Done.
• Retrospectives should never be about berating the team on everything they did wrong!  This is the most powerful opportunity the team has to identify ways they can be even more awesome.
• Bugs and User Stories were tracked completely separately.  There were, in effect, two different backlogs.  The two would overlap from time to time, but not always.

To end this post on a positive note:

Eventually, this situation was turned completely around, and resulted in some of the strongest Scrum teams I have ever seen.  The way it was done was highly unorthodox, but it worked.

But that’s another story.