Hackers and Slackers (Guest Post)

By Lynette A Cain (Scrum Master, Former Actress, Improv & overall awesome human)

Think back to the old Waterfall Days - not so long ago - and imagine the office at 5 PM. Most of the staff is packing up their bags, shutting down their computers, and has their minds on dinner. At 6 PM a handful of people remain, trying to finish up that last email or task. By 7 PM, only three are left: Molly, Evan, and Linda. Molly has been in the department for over eight years. She knows the most complicated rules engine code inside and out, and everyone knows it. The whole team runs their client-related tests through Evan. He has a dozen polite ways to tell the client that the problem is on their end without making his executive director nervous. Linda is the only person the department trusts to break down an intricate client request. Molly, Evan, and Linda have a bit of running banter, when they see each other at the water cooler: they’re the heroes, the ones who can fly through dozens of tasks after the slackers go home. They enjoy the rush of putting out fires and rescuing projects. Their peers quietly acknowledge their prowess. The heroes’ managers know they’re saving the day. It all seems to work.

Now let’s come back to the present time, in which Scrum has replaced Waterfall. Molly, Evan, and Linda each chose a different Scrum team. As usual, Molly, Evan, and Linda still rescue the department, while their teammates do…very little. Their lack of delivery is clearer, now. The “slackers” have little to report at daily Scrums while the heroes have a long list of what they completed and what they have in progress. The managers, and their own managers, wonder how they can get everyone else to work with the same sense of urgency. The Scrum Masters see waste, an unsustainable pace, and other symptoms something is very wrong here.  The heroes don’t want to hear the Scrum Masters’ observations.  Molly, Evan, Linda still know they are carrying the department and feel the Scrum Masters add no value - where are they at 7 PM while the heroes are still working? Long gone.

It’s clear the heroes are valued team members. But what if, in fact, they’re also bottlenecks? The Theory of Constraints tells us the entire team can only work as fast as they can. The knowledge and experience Molly, Evan, and Linda have is limited to them. If Evan gets hit by a bus tomorrow (and he could, since he’s so tired he’s barely aware of his surroundings), so much for the client testing. So why, knowing that Molly, Evan, and Linda are so valuable, isn’t anyone learning from them? They’re endlessly busy executing, with no time to mentor or teach new employees. Other team members are bored and frustrated because they want to do more than busy work.  They aren’t slacking; they’re frozen assets, unable to reach their potential.

Something has to change. The Scrum Masters propose an experiment: for a sprint, Molly, Evan, and Linda are not allowed to take on sprint deliverables – they are reserved exclusively as teachers and mentors. In the short term, this experiment is incredibly painful. The Product Owner sees a sharp temporary drop in velocity. The heroes sit on their hands, willing themselves not to take over and save the day as they have so many times before. Theirs is, in many ways, the biggest leap of faith. Surrendering knowledge and expertise makes them feel vulnerable. Who are they, if they aren’t always SMEs? Can they learn something new, becoming humble beginners again? The frozen assets, the people who weren’t previously meaningful contributors, are also forced to step outside of their comfort zones, unable to vanish into the background. They now carry responsibility for delivery. They fear, what if I can’t learn fast enough? The Scrum Masters observe, encourage, facilitate…but mostly worry that the results of the experiment will not come fast enough to make the sacrifice worth it in the eyes of the Product Owner and managers.

The experiment runs for a sprint, and then another. The product team gets benefit from starting to relieve the bottlenecks, and decides to continue in this manner. They document everything the heroes have been doing, so the next time that Molly fixes an obscure rules engine bug, someone else knows how to do it. Molly’s mentees are accountable for retaining and spreading their new knowledge; they are now the first responders. Linda and Evan take similar approaches, so that they are able to spend more and more time anticipating ways to add value instead of reacting to problems.

For a while, everyone works as if this is temporary, and some day Molly, Evan, and Linda will all return to their former habits when the team is up against a tough deadline. But somewhere along the way, Molly takes a vacation. Evan gets to learn performance testing, and it’s a nice change of pace. Linda feels a little exposed, since the teammates that never used to touch client requests have learned her tricks of the trade. She may doubt her value, but they don’t. They’re impressed by what a great teacher she is.

The truth is there are many experiments that could allow the teams to break through the bottlenecks. All of them come back to control, though: the heroes must surrender their burdens to both lighten their own loads, and give the others a chance to be meaningful contributors. Molly, Evan, and Linda aren’t the whole department. Once they don’t have to be, they will get to (or have to) turn to their coworkers and see true peers: equals, partners, and the reason they go home for dinner on time tonight.

The Agile Mindset

During a retrospective with a client, we did an exercise called 5-whys to try and uncover the underlying reason behind the lack of focus on production. One enlightened developer provided a valuable piece of insight when he noted that we *may* still be in a “waterfall mind-set,” hence the lack of urgency.

This is natural after living under the tyranny of the waterfall deliveries for many decades.

Why does getting to production every sprint matter so much? Why won’t I just shut up about it?

In my experience, the greatest two barriers to a meaningful agile adoption are the waterfall mind-set and the belief that everything will magically come together at some point in the future.

Nothing has a more profound impact on changing the waterfall mind-set than actually getting to production at the end of every sprint. It will change the way you think and operate.

If the teams and the product owner do not insist on getting to PSPI (potentially shippable product increments) every sprint here is broadly what will happen. You basically end up with scrum-fall (scrum+waterfall) (devolopment sprints->line up environments-> integration test -> uat-> production). Estimates start to become meaningless as you will need an equally long time for the “release sprints”.

The net result will be a failure to deliver and ultimately blaming agile: e.g. “Agile does not work.” “We need to go back.” “If we stayed doing things the way were doing things, we would be live by now”.

As if to say that we delivered so wonderfully in the waterfall model.

But the product owner is not pushing for production

It is the job of everyone (feature team, scrum master, product owner). To date, the push to production has been coming from people outside these three groups. This should be discussed in PBR (product backlog refinement). The scrum master should keep the production tension alive. 

But there is no business value going to production every sprint

That is probably true during the first couple of sprints, but going to production every sprint will change the nature of PBR. The team/PO will start thinking about what useful things can be built to drive revenue. (e.g. if we do X can we start generating a subset of the revenue).