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 Magical Three Year Strategy

“Most people overestimate what they can do in one year, and underestimate what they can do in ten years”
— Bill Gates
  • How long does it take to replace an antiquated system that has been around for decades? 3 Years
  • How long does it take to build a strategic system that could leap frog the competition? 3 Years
  • How long does it to take to transform your organization to Agile? 3 years
  • How long does it take to do anything that requires large strategic investment? You guessed it, 3 years.

What gets presented is a Gantt chart that looks something like this:

Phase 1: Will be delivered 9 months after the money is secured and will deliver something called the "framework"

Phase 2: Will be delivered 6 months after Phase and will delivery the first valuable delivery

Phase 3 (where the magic happens): Will get delivered at the end of the three years and will deliver all the value

What actually happens:

Phase 1 gets continuously delayed until a senior manager threatens that heads will roll.  In order to meet said manager’s expectations, Phase 1 gets rebranded to Phase 1a and the scope is cut by 30 percent.

After 2 years, Phase 1a eventually gets delivered and drinks are had.

Discussions about how this is not working and about how to wrap it up nicely begin to replace other discussions.

One or two PM casualties later the project is shelved and another system remains to be decommissioned by another 3 year strategy.

I understand now why the answer is always three years. It looks great on a deck, and is neat and tidy. That's not what interests me. What I find fascinating is how intelligent, well-paid managers can sign-on to something they know is not possible over and over again.

Do people really believe it? Does it take three years to forget? I know the people presenting the three year strategy don't really believe it. So what is their motivation? Simple: They want the money. They are not going to get millions in investment if they tell the simple truth: it will probably take about a decade to do what we promise on page one of the deck. So they promise the impossible.

My assertion is that major banks are part of a system that is beholden to share price and providing shareholder value. CxO’s don’t have a long shelf life, 3-5 years. Their attention span is, understandably, 3 years. They are not going to sign-off on a very expensive program that will last longer than their perceived tenure.

Don't get me wrong, you can build lots of stuff in three years. It just takes far longer to realize the benefit, which is often the reason you start the project to begin with.

If your plan is to replace many systems with one system, or build a platform that will leap frog your competitors, chances are it will take at least twice as long as you have quoted on paper.

“The tyranny of the waterfall; The illusion command and control; The belief in magic; and The era of opacity.”
— Ken Schawaber discussing the four obstacles

If any of the above rings true to you, your project is doomed to fail before you begin, and your time is better spent tidying up your existing infrastructure.

Make it last...Toilet paper financing

Money is like toilet paper, if you have too much you will waste your resources and run out very quickly. Give a person an allowance of one roll of toilet paper and they will make sure they use their limited resources appropriately. Give them too much (e.g. 30 million in the first year) and they will waste it on cleaning up spills in the kitchen.

Give the team as much toilet paper as they need and no more. Down the line, they may have Mexican and need twice as much toilet paper. That’s fine. But the key is to make it last the 5-10 years that will be required to actually execute on the strategy.

You can also avoid the above by going "tactical"...

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).


Nothing is getting done...

When agile/scrum is introduced into an organization one of the side effects is a perceived or real lack of urgency. I have seen this on a number of occasions, where teams seem to be losing the sense of urgency. Estimates feel too high, not enough "stuff" is getting built.

"enough of this hippy B.S., we need to crack the whip"

I want to share some of my observations regarding why this happens and some suggestions.

The traditional model of getting things done is referred to as the authoritarian model by Peter Senge (the 5th discipline). In this model, one person understands the problem and shoulders the sense of urgency and tells his “team” what to do. That person is the information bottleneck. He/she cracks the whip when he needs to be but many also reward a person for a job well done. The sense of urgency comes from the fear of this person and not from the “real problem. Let’s call this model, the Lewis model.

To a certain extent the Lewis model actually works and “stuff” will get delivered. Lewis will get rewarded. He works hard and shoulders most of the stress.  As a side effect of the stress and the whip cracking, few people want to work for Lewis.

Another model is one where the team feels and understands the problem. Rather than the sense of urgency stemming from the fear of a “person” it stems from understanding the real underlying problem or business opportunity. This will result far more creative solutions to the problem.  Teams working under this model will usually work harder/smarter than under the Lewis model. Let’s call this model the Harvey model. Everyone wants to work in this model.

A big part of the product team’s role is to translate the opportunity/problem to the team and protect the team from Lewis. The team in turn must seek to understand the problem/opportunity and deliver results.