Don’t Crash the Ambulance

Here’s what happened.  There was a waterfall project that seemed to be going well, and when it came time to deliver the first big block of code for review, everyone found themselves staring into an abyss.  The code was of horrific quality; it didn’t match requirements, and the Business had no confidence that the remaining work could be delivered with success, no matter how it was measured.  Dates had been promised, but no one had good visibility on what the remaining work really looked like.

Then someone suggested that we try and tackle all remaining work, whatever it might be, using agile practices.  This seemed like a great chance to show the business what agile teams could do.

But there was a catch–we would spread our existing high functioning team out amongst all of the waterfall developers in hopes that the new contractors would , I guess, pick up agile through osmosis.  Essentially, we were tasked with bringing some 20+ developers up to speed in. . . 1 week.  After protests and explanations that it takes longer than that for the teams to come up to delivering at full capacity, we were told hat we didn’t have that option and that we just needed to get it done.

I will say this in our own defense.  The very first thing that Agile did do to benefit
the company was to clarify the massive volume of work remaining on the project.  For the first time, the Business had clarity on what was required to build what they were asking for

 
What didn’t work so well was that with all of that new-found clarity, the business demanded a date–not a date range as we had suggested–but a date.  We gave them one–with a delivery date a year longer than the waterfall team had promised.  The Business then de-scoped the project, (a feat they could only accomplish thanks to our agile release planning activities).  We gave them a new date range, but they demanded a date.  We gave them an estimated date that had 70% certainty, and told them we would adjust once the teams starting developing.  As you might guess, the Business locked on to that estimate and called it a commitment

So here are the lessons learned:

1) Make sure the Business really understands what agile means and what it requires–particularly in the context of implementing it mid-project.

• It is not a silver bullet that will kill the werewolves tearing at the throat of a project. 
• It will require time and effort up front to train new practitioners–time where no code is getting delivered and no waterfall “milestones” are being hit.
• The person doing the management briefing on how the teams will be doing Agile needs to be the person who will be acting as the chief agilist for the remainder of the project.  It needs to be a consistent and passionate voice.  If not, the Business may be given a watered-down version, or worse, non-agile concessions may be agreed to that will endanger the Agile effort.

2) Do not agree to a date on initial estimates. The bigger and more complex the project, the more a date range needs to accepted as the only responsible estimate. (see #1 above–“understand what Agile means”).

3) A Waterfall project that shifts to Agile will not get all of the benefits of Agile.

Our status bar says “In Progress.”

4) Watch out for Design or documentation tasks getting added to user stories during planning. Waterfall teams often rely heavily on color coding and % complete bars on tasks or milestones in the Gantt chart.  Calling design work and documentation part of code delivery obscures the actual progress of getting the code developed and tested. This often leads to what I call “In-Progress Bliss”–a virtual state that looks great but may not actually mean anything.

• Teams that are used to working in a waterfall fashion will likely add design tasks to a user story in sprint because that is how they are used to doing work.  They are not used to the concept that design comes up front prior to the code being committed to completion during a sprint.

• They are used to the kudos that come from showing that work is “in progress”even though that status is completely arbitrary
• Design is very much a part of Agile; however, the work should not be part of the sprint; it should be completed before the sprint planning sessions and preferably before the grooming session.
• Documentation is also important, but it should be just enough and just in time.
• Teams that are used to working in a waterfall fashion will likely hold off doing any development until the design docs are completed; therefore, no QA or Dev can happen in parallel.  That creates a sprint that is more like a mini waterfall.
• If design decisions cannot be made during the course of the sprint, the team appears to have missed its commitment.

5) If you need an additional 2-3 days to break things into smaller pieces so you can provide a more informed estimate for a date range, insist on them.

6) Insist on smaller teams. If you need to spin up more teams and get more scrum masters, do so. Don’t let the availability of scrum masters be a limiter. Find more. This may require getting buy-in from a broader group within the organization.  Also, with larger teams–especially on large teams of people new to agile,– there are opportunities for many, many, many bad behaviors to be hidden.

7) Likewise, (and I would say more importantly), do not let the number/availability of Development leads or tech leads dictate how many teams you have—GET MORE! If none are available, then you MUST either look at ways to break the work into smaller deliverables, or spin up people who can act as the dev or tech lead.

8) A hurry up and start approach to spinning up multiple agile teams does not make the project hurry up and start

9) Having highly specialized developers on teams with generalists creates problems with capacity driven planning.

• It’s hard enough to balance the work between Dev and QA. Throw in 1 or 2 people who can only work on one specific area of the code but be tested by the QA that multiple other areas are using, and you will have idle people
• Idle people compounds the problems you might have with respecting sprint boundaries—they decide they will move ahead on work, unchecked and with no code reviews, resulting in people being very busy at doing the wrong things
• The idea was to have any stories that have developers from multiple areas with tasks in teh same stories. It appears that this proved to be the exception rather than the rule.
• Having a large number of smaller teams working independently would mean that the scrum of scrums becomes a far more important meeting requiring far more expertise from each team. –this could be a very difficult issues to resolve

10) Don’t crash the ambulance.  Yes, that’s great a Mark Knopfler tune, but what I mean by that is this:  remember that you were brought in as an agilist or as an agile team to rescue a project that was failing. Don’t fight so hard as an agilist that the project fails anyway.  You can’t fix it all at once.

• The odds are  very high that your preferences around the agile framework will take a serious beating, but hold on to as many as you can and use failures, mishaps, and painful points to coach how adhering to the agile principles would have been more helpful.  
• If the new teams and Business decision makers refuse to follow your recommendations, take note and talk them through the lessons learned.  
• If the project still fails, the odds are good that someone will try to blame it on Agile.  Don’t let them. Coach them. 
• Finally, absolutely positively, without fail, hold a project retrospective.  That is the only way you will help them learn from the mistakes they made in the first place