The following is an Experience Report I presented at Agile 2009 in Chicago (Part 2 of 4)

Weaponizing Scrum

Which brings us to our fourth Workstation Scrum project: a sub-revision which would release in tandem with the first-ever Scrum Firmware project.  This project kept the same project manager, but ran with a different product owner and technical lead—both of whom were subject matter experts on the key deliverable.  For this project I was going to get to join one of the teams as a contributing member.

This project would involve products that were going to be shared internationally, so we were going to be subjected to scrutiny from higher management; many of whom had no other exposure to agile.

Loading the Weapon

Unlike the piloted Scrum projects in which management sought only to define two of the three variables of the Iron Triangle¹, this combined Workstation/Firmware Scrum project was falling prey to management’s attempt to define all three.  We knew how many resources we had.  We had been told our ship date.  And our new product owner handed us a list of requirements right out of the old waterfall days.  Every requirement in his list was marked as a critical, non-negotiable feature, or a high.  Resources, time and features would have to be in perfect alignment for the project to succeed with the expected level of quality.

The team set about the task of turning the requirements into User Stories, and then sizing the critical stories so we could give some sort of estimate for an end-date.

This was one aspect of the Process that our Agile projects have not been able to escape.  A waterfall gate stood guarding the transition from design to development.  Even though we were using Scrum we still needed to define our project commitment (dates/features/costs) before resources would be allocated for development.  Pressure was mounting for the project to go through the gate as soon as possible.

The team was hoping to show that the number of story points on the backlog, combined with the velocities of the teams would align with the schedule.  But as the story point totals started to climb, it quickly became apparent that the July deadline was not achievable.

Applying the weight of three successful releases using the method, the team sat down with the new product owner and asked him to reconsider the criticality of features on the backlog.  Could some of them be eliminated?  We assured him we’d still try to get to them if we had time, and he would still be able to control the order we addressed features.

The product owner wasn’t going to back down.  He believed that if he conceded on any of the features, he was going to lose them.  He was not about to give them up this early in the project.  Especially because he believed that based on past waterfall experience, the estimates of the developers must be padded.

We did not fare much better when presenting the schedule information to management.  Because all the key players had been entrenched in the waterfall negotiation loop for so long, it was an easy pattern to repeat.  They assumed our Scrum project was presenting the same sort of bloated schedule as waterfall, so they treated our estimates the same as they would any other.  They pushed back, expecting we would reduce the estimate at the first sign of resistance.

They did not expect us to be so certain about the accuracy of the estimate.  They didn’t expect us to try to back up the numbers instead of backing down.  We had run the charts, applied the team velocities and projected the end date.  The projections said October, not July.

The hand had been called.  The cards were all on the table.  A bullet slid silently into the chamber.

Taking Aim

In our euphoria over our own prior project successes using Scrum, we mistakenly allowed ourselves to believe that if management was endorsing the use of Scrum at the global level, they must believe it worked.  It was a fatal mistake on our part.  Remember, the cycle of padding and negotiation didn’t just happen overnight.  It evolved over time.  So when Agile estimation techniques are suddenly injected into that loop – estimation techniques that we had been using with remarkable success in the Scrum pilot projects – techniques that we had grown to trust.  Well, can we be blamed for forgetting that the audience wasn’t expecting us to play straight?

I admit it.  I’m an idealist.  I believed that we had amassed enough successes to at least deserve a fair hearing on the subject.  If you want to restore trust, you have to give trust.  We laid our cards on the table.  And they told us we were wrong.

So we realized, we’d have to prove it to them.  We ramped up the teams on the new material.  We started sprinting, and burning things off the backlog.  And before long, we had what we thought was evidence that our estimates were good.  The stories were taking about as long as we predicted.  The team velocities were keeping track with our past performance.  And the release plan was stubbornly backing up our predicted end-date of October.

Unfortunately, for business reasons October was not an acceptable answer, so management approached the team leads and told them in no uncertain terms that the date of the project was fixed.  The features were fixed.  The teams were fixed.  And they challenged us to find a creative way to achieve the goal.

Pulling the Trigger

We were somewhat shocked by the request.  For three revisions we had shown that our estimates meant something.  For three revisions we had achieved what had previously proven to be impossible.  And now we were being treated like none of that had ever happened.

Our first solution was to stick to Scrum.  Scrum said you can’t expect a quality product by cutting out quality activities.  Scrum said you gained trust by being open.  So we were open.  We showed them the sprint burndown charts.  We talked about how the teams were performing.  We showed them how every member of the team was working at a reasonable pace.  And if they wanted to bring in that date, they either had to find more team members, or figure out which features they could live without.

It’s sad how we can be blinded by our own successes.

With the evidence laid out before them, they asked for clarification on the concepts of reasonable, sustainable pace and velocity.  We told them.  They looked at the burndowns, and commented that it only looked like the team members were spending about half their day working on sprint tasks.  We explained the difference between work tasks that produce deliverables, and overhead tasks that support the delivery.  The burndown would only reflect the former.

Suddenly a light dawned.  Faced with this incontrovertible evidence they realized there was something management could do after all.  They pulled out the waterfall playbook, and declared a death march.  Based on the velocities of the team, the July date could not be achieved with anything less than sixty hour weeks.  And mind you, it was only January.

We were victims of our history.  In past projects, when the going got tough, the death-march got going.  When the death march started, it was time for the teams to get serious.  It was time for everyone to really focus and push toward the goal.

In an agile project, the intensity of day-to-day sprint life is higher than the intensity of a standard waterfall day.  In waterfall, the team paces themselves to complete a large workload at a time that is months in the future.  Unless your team members are extremely disciplined, they don’t generally start feeling the need to ‘get serious’ until later in the project – and then it’s usually at the prodding of the project manager who has just figured out that the actuals are rapidly consuming all the padding she helpfully placed in the schedule.

But in Scrum, the team has a near-term deadline and a commitment to deliver fixed functionality every sprint.  The intensity level is already higher.  Scrum had identified the schedule conflict at the project beginning.  What we now had was five teams already operating at a self-imposed intensity level, being told to crank it up by 50% and maintain it for six months.

Death March

The first ‘enhanced sprint’ was begun the very next day.  The technical lead unveiled a ‘new’ strategy to help optimize our progress.

Tasks would be assigned to the teams with the most expertise in the given area.  Whenever possible, the subject matter experts were to work on each task.

Even though we were now planning more stories into the sprints, the sprint planning meetings were shortened.  Since the experts were on the job, taking time for cross-functional understanding of the features would be an unnecessary luxury.

Sprint demos would be brief, with fewer attendees to cut down on questions.

By employing these strategies, we were able to end a sprint and plan the next one all on the same day.

As expected, the first enhanced sprint gave us an initial boost in performance, although nowhere near the level management expected.

What was most interesting and tragic from my perspective was watching all the team-building of the last two years evaporate before my eyes.

When stressed, we harken back to our base instincts.  We rely on muscle memory to keep us going.  And so it was that the team members slipped into the old waterfall patterns again.   The first sprint came to an unceremonious end.  Not one team had completed all tasks within the sprint successfully.

The incomplete tasks were rolled forward onto the next burndown chart, and the next pile was assigned from the backlog.  The long hours started taking their toll on the team.  People’s schedules became erratic.  Some people worked late nights at the office.  Others made up the extra time by working weekends. Team members were no longer operating on the same schedule so coordination became difficult.  The toll on their family lives and health was staggering.

There was no longer any commitment as a team to completing the sprint work.  Since people were assigned work in their own area of expertise they just focused on completing their own tasks.  They stopped thinking in terms of completing features.  All they were worried about was punching the time-clock.

After two months of sustained overtime, morale on the teams tanked.  The velocities of completed stories made it appear that the teams were operating at the same speed as before the overtime was imposed.  They were just spending a lot more time doing it.  The team members were convinced the project was doomed.  Daily scrum meetings became exercises in futility.  Everyone was focused on reporting their own time.  They weren’t listening to each other as they spoke, so questions were often repeated.  Tempers grew short.

In the third month, arguments between team members were happening on a daily basis.  We were three months from the drop-dead date, and everyone was dug in for the long haul.  Occasionally, one of the team members would get dangerously close to snapping.  So the managers started granting a day or two to go home and just decompress.  It was during one of these reprieves that a miracle happened.

 

Next: Weaponized Scrum Part 3 – Countermeasures