Your Subtitle text
You’re Just Going To Fail, So Why Bother?

Are you too busy failing to learn how to succeed? It’s alarming how many of us seem to be. In fact, polls and studies conducted over the last 10 years show a remarkably bleak picture. Depending on sample set and how the question is posed, somewhere between 60% and 70% of all teams or organizations in the United States that attempt the shift to Agile will fail or back out before the transition is complete. Let me put a finer point on that because it’s a critically important concept: If you were aboard the Titanic when she sank, you would have had about the same chance or surviving as you do of changing your company from Waterfall to Scrum.

Is that because Scrum is defective? Overly-rigid? Or unrealistic? Well if it were because of shortcomings in Scrum, we wouldn’t see the remarkably predictable success rate when organizations apply it completely as defined. Plus, we have to remember that Scrum was originally extracted as a set of best practices of highly successful teams!  Further analysis yields another culprit as the clear killer of Agile attempts. Just talk to some people who have participated in failed implementations and you’ll begin to see where it goes wrong. They’re not hard to find and they are almost all happy to pay for their own cup of coffee just to have an audience to hear their tale of woe. “Scrum just doesn’t work,” they will announce with certainty and an air of wisdom.

    “It is completely incapable of dealing with the complexities of an organization like ours. And as for complex projects? Forget it. We actually found that our productivity went down, morale hit the skids and defects in production went through the roof when we shifted to Scrum! Some of our most senior people quit because they refused to be treated like sheep. Ultimately, we had to get rid of it to save the company.”

As a coach and speaker, I am often confronted (both in person and electronically) by people with this type of experience. With just a few questions beyond their statement of Scrum’s absolute failure, I find out that it wasn’t Scrum that failed them. It’s pretty easy to figure out that they failed to use Scrum. It’s so common that the Agile community has developed a couple of very clever “insider” nicknames we give those implementations: “Scrumbutt” (“We’ll do Scrum, BUT… we won’t use Story Points”, etc.) or “Murcs” (“Scrum” spelled backward). The hazards of hybrid models are well known to experienced Agilists but are deadly catnip to the uninitiated, who regularly set out to navigate this strange terrain without investing in quality training or coaching. Maybe they buy a book. Maybe they buy books for everyone. And maybe a few of them actually read part of it (though some will invariably try to get through the first few meetings by having glanced through the Wikipedia version instead). Or maybe they even find some poor saps who have never heard the word “Scrum” but want a little resume candy, and ship them directly to a Scrum Master Certification course. These are well-worn paths through the woods, my friends. And they all converge at nearly certain Failure. Again, let me be direct:

    If you’re wondering if Scrum will work in your current environment, let me save you a little time.


    It won’t.

But if you’re looking at Scrum, it’s probably because there’s something that isn’t working now. What needs to change is your environment, not the framework of Scrum. And that’s a big, huge, hairy deal.

The model we use for evaluating a new engineering tool – bringing it in house, having a few of your best people dabble with it and watching for smoke – simply doesn’t work when you’re talking about organizational change. Before you go yanking the rug out from underneath your company, you need to first invest in gaining deep, effective understanding of not just the benefits but the pain points of becoming Agile as well. That’s right, kids, it ain’t all sunshine and roses. If you have an effective Scrum implementation, you will be struggling to cope with the pains of organizational change for months or even years. You should know where you’re going and what the ride will feel like on the way. When Scrum comes into the building, it isn’t going to be “someone else’s problem” to manage.  It will invariably land on your desk, and demand changes in how you do business — but with great reward if you adapt.  Sadly, though, the state of Scrum in Corporate America today is akin to a couch potato deciding that he wants to ride the Tour de France, so he invests tens of thousands in equipment yet only trains by watching DVDs of previous Tours. If you’re serious, you’re going to have to peddle up some very steep hills while your muscles cry out to turn the bike downhill and coast back to sea level where breathing was easy and the paths were wide and flat.  It takes serious training, and no organization or member of the organization gets a free pass.

There are a host of misunderstandings and misinformation floating around. Here are six hard truths that everyone considering Scrum should know:

    1. Scrum is not for everyone.
    Achieving the results that attracted you to it in the first place requires a tremendous amount of discipline, initiative and motivation. Most companies simply won’t do the hard work to achieve a sustainable, expanding implementation. It’s a lot like organizational psychotherapy. Sometimes, you uncover something horrifying and, once the elephant is in the room, you’re stuck dealing with it. The most common coping mechanism is to blame it on Scrum, revert to old behaviors and have coffee with lots of friends so you can tell them how Scrum failed you. Denial is so comforting – for a while. My advice to anyone considering the move to Scrum is to first list the reasons you think it is right for you. If you have only gotten as far as the “whiter teeth and fresher breath” sales pitch, back up and ask some deeper questions before you drag your company on an expensive and sometimes lethal boondoggle. If you’re getting pumped up on Scrum by a Coach who cannot address some of the pain points you’re likely to experience, you may well have a charlatan on the line. Remember, if your current system is not giving you the results you need, something – perhaps lots of “somethings” – will have to change. If your understanding of Scrum is all benefit and no pain, your implementation will most likely be all talk and no action.

    2. Scrum is not an org chart.
    I frequently have people ask me, “If I become a Scrum Master, what is that going to do to my career?” or “What is my path for promotion from Scrum Product Owner?” But the much more common form of the question is, “I’m a Development Manager. Do I not have a job in Scrum?” The honest answer is that the early years of Scrum were riddled with calls to fire all people with the word “Manager” in their titles – Product, Development, QA, Project, Program, etc. That is (thankfully) no longer the common wisdom and certainly is not my advice to anyone. Good Management still has a vital role to fill but we do need a particular breed of Manager. Command-and-Control, authoritarian types will not thrive in a Scrum company unless they turn over a new leaf. Micro-Managers, however successful they may have been under the old system, will need to be retrained or replaced under the new one. You should go into this decision knowing that serious organizational change means being serious about changing the organization. But it doesn’t go so far as eliminating everyone whose title falls outside the three Scrum Roles. Leaders who have never been interested in facts and prefer to just bully and threaten people are not going to suddenly start responding positively when Scrum paints an even clearer picture of the reality they wouldn’t acknowledge in the first place. So, while companies still need leadership, just be sure you have the right type. If your corner offices are clogged with sacred cows who refuse to learn new behaviors, know up front that this will dramatically (perhaps mortally) wound your attempt at change.

    3. Scrum has nothing whatsoever to do with software.
    While it is true that the overwhelming majority of Scrum adopters are software organizations, it is equally true that none of the Twelve Points of Scrum directly or indirectly addresses anything particular to software engineering. Scrum is about human beings. It is a framework that allows people to effectively solve complex problems. But it is the people who solve the problems, not the Scrum. Try this on for size: many churches use Scrum. So do non-technical, non-profit organizations. And perhaps the most heroic use was when the rescue workers at the Twin Towers on 9/11/01 rapidly re-invented a way of working together that almost perfectly mirrors the Twelve Points of Scrum. Remember Scrum’s origin?  “Best practices of highly effective teams”?  But if you have been looking to Scrum for a rule about code reviews, stop. It isn’t there. If anyone demands that you cannot have specialists on a Scrum Team, make them tell you which of the Twelve Points made them believe this. There isn’t one. If someone tells you that Test Driven Development is required to do Scrum, correct them. They are wrong, and you can tell them I said so. And if you think I have said that to you, please come see me right away. I’m a tremendous fan of TDD, to be sure. It pairs well with Scrum – like chocolate and peanut butter. But Scrum only cares that you finish a Sprint with completed, working product. How you achieve that is entirely up to you. Use Magical Quality Gnomes if you have them. I certainly would. There are several best practices emerging – like combining Scrum with LEAN, XP, TDD and so on. But don’t be sold a lot of religious zealotry, however well-intended, under the guise of following a Scrum mandate. Scrum is about taking a group of humans and achieving a series of goals. Period.

    4. Scrum will not fix your company.
    Scrum will relentlessly and remorselessly identify your company’s problems. It will point a finger as easily at the President of your company as it will at the most junior member of Engineering. But the Scrum framework doesn’t tell you what to do about the problem. You and the Leadership have to sort that out yourselves. It’s why you get the big bucks. You will have to make some tough, uncomfortable decisions. Sometimes, you won’t be popular. Consider, for example… What would you do if that Founding Architect just can’t stop meddling with teams and constantly causes Sprints to fail? Will you correct the Architect’s behavior, or order the team to cope as best they can? And what if your Sales & Marketing Department refuses to deal in realistic dates? Will you press your teams into long, late hours, ignoring the skyrocketing defect injection rate and mountain of technical debt? Or will you make the necessary changes in Sales & Marketing to improve the situation? What if Scrum tells you that your own behavior is counterproductive? Scrum will tell you it’s happening. But will you take responsibility for fixing that problem? If you will stand up to these challenges and more, you may be well suited for Scrum – and let your competition beware.

    5. Scrum eventually changes everything.
    There is no office in the building that won’t eventually see change with Scrum. There is no institution, division, process, architecture or tradition that won’t eventually feel its impact. “Inspect. Adapt. Iterate.” It sounds so simple – and it is. But simplicity and ease are distinct notions for a reason. If you’re going to make a success of this transition, you need to understand that you are slowly rebuilding your company from within and every truss and rivet will be touched before you finish. In one of my previous positions, I was the Engineering Manager for a core component that changed very frequently. We often referred to our releases, which auto-installed directly to production, as “changing the wheels on a moving bus”. It’s an apt analogy for shifting to Scrum. You have to keep the business moving while you fundamentally change its structure and essential functions.

    6. Self-organization does not mean “go do whatever you want to do.”
    I have worked with scores of individuals who saw the Scrum ethic of self-organization as a warrant to defy direction and just work on whatever made them happy. I’ll try to be as clear and uncomplicated as I can be: If you do that, you will probably be fired. Self-organization applies to the team, not to individuals. The company has (or should have) a distinct, well-defined set of goals that they need you to achieve. Empowering the team to decide how the problem gets solved is an overdue extension of respect for the professionalism and intelligence of the team who are doing the work. But be very clear on this critical point: The solution and coordination is up to the team, but the choice of which problem to solve is not.

Now if all of this sounds like I’m trying to discourage you from trying Scrum, then you probably scored high on all of your reading comprehension exams. There are enough hucksters out there whipping the hopeless masses into a failure-bound frenzy. Candidly, there was a time in my career when I was one of them. When you first see the elegant brilliance of an effective Scrum implementation, it is natural to brim with enthusiasm and try to light the path clearly so other travelers can follow. And I did – but no longer.

Too many uncommitted companies that amount to little more than giant, incorporated couch potatoes have been jumping aboard the Scrum bandwagon for all the wrong reasons. And, frankly, hanging out with that crowd is starting to tarnish our reputation. We all know that their predictably mangled corpses will just clutter up the pathways for the more committed competitors who are gladly enduring pain for gain’s sake. So with a bit more wisdom and the benefit of better hindsight, I no longer believe in “Scrum for All”. I am now a Zen Master in art of “Scrum for the Elite Few”. After all, if everyone was doing Scrum well, where would young Scrum companies find slow, bloated adversaries on which to sharpen their hunting skills?

So go ahead and invest your time buying more comfortable chairs. Have a couple of Executive off-sites, re-org yourselves without changing anything too complicated and use the term “game-changing” a lot. Maybe licensing a few new engineering tools will create an illusion of progress and keep the troops placid. Besides, we all know that if you start Scrum now you will still be arguing about which of the Twelve Points don’t suit your remarkably unique environment by the time a serious Scrum company enters your market. So why bother? Who needs all that pointless stress? There is a lot to be said for a peaceful life lived among familiar surroundings. And aren’t you at a point in your career where you should just be able to coast based on the knowledge and certifications you’ve amassed so far? New systems are just a bother. So just sit back, put your feet up. Wrap yourself in the warm blanket of past achievements, pop open another cold one, grab the remote and check out what’s on ESPN.

One of our representatives will be by to see you before you know it.

It’s All Just A Little Bit of History Repeating…

The software industry fell into civil war.

A technical firestorm had erupted when a long smoldering spark was fanned to flame by a comparatively unimpressive innovation.  Adversarial camps – Supporters and Deniers – were quick to form on opposite banks of the revolution.  Supporters made promises that sounded unrealistic and full of hype.  They assured us that this innovative approach would make our work cleaner, clearer, more accurate and more cost effective in the long run.  Deniers, on the other hand, painted it as merely a passing fad – hardly an “innovation” at all and really more a novelty that was appealing only for novelty’s sake.  Supporters were cast as wild-eyed, gullible zealots by the Deniers while they were themselves accused of being stodgy, out of touch kermudgins and relics of a previous age.  I, being new to the industry at the time (nearly 20 years ago), vacillated between camps unsure where my fledgling loyalties should lay.

Tempers flared as the status quo was challenged.  It was an entirely new way of approaching work that, if it were to succeed, meant re-evaluating everything: hierarchies, organizations, responsibilities, tools, processes – even roles, titles, positions might have to change if companies were to reap the benefits of the innovation. Worse yet in the eyes of some was the fact that seniority, established based on prowess with the Old Ways, could be lost if the New Ways did not come as easily.

To many, change represented a grave threat.

My company, which was a very large CAD/CAM organization with over 10,000 employees, was quickly convinced by the technical leaders steeped in the Old Ways that the innovation only represented bloat, slowdown, overhead and imprecision.  They raised the specter of project overruns and uncertain deliverables.  One closing argument I recall from a Denier was this: 

“We are not a research firm.  Leave that to Universities and think tanks.  We are an Engineering firm and need to build our solutions quickly and with proven approaches that have worked well for us since the company was founded.  After all, isn’t it really all about just getting the work done?”

Management was persuaded.

I arrived at work one day to find my keyboard (and all of the keyboards in the office) draped in a memo from the office of the Senior Vice President of Software Engineering.  Though it was passionless and brief, the point was clear:  anyone caught espousing, promoting or exploring the new approach would be immediately terminated without further warning.

And so with that memo, C++ and Object Oriented  Programming were banned.

Now I won’t go into the differences between C and C++ here – there are many well written articles and blogs available to you through Google on that subject – but what I find fascinating is the parallel to how Scrum has been treated as it enters the American market today.  

Years later, I recall reviewing a co-worker’s first attempt at C++/OOP wherein he had created an object containing three methods, each essentially a C-style function. All variables were at global scope.  He instantiated the object, called the methods in sequence and let the object go out of scope.  He mused aloud as he stepped me through his code, “I don’t see what all the hype is about.  It’s just a different way to organize code and I don’t see how it helps anybody.  But, oh well.  It works!”

Well… yes, and no.  He got the syntax but had totally missed the point!   He was so busy going through the motions that all he accomplished was creating a larger executable than he might have done with C.  His interest in learning OOP was minimal and his focused effort was dismal.  Because of that, his results were horrible.  No wonder he thought it was pointless!

When I am sitting through a meeting with a team that is still in this mode with Scrum adoption, I often think what it must have been like for the fellow who built the first bicycle in the world.  He must have spent many long hours crafting the machine only to climb aboard and immediately crash into something.  What made him keep picking that bicycle up, putting himself back on it and go crashing around until he got it right?

Much like C++, Scrum comes with a syntax:  Sprint, Product Owner, Backlog, Story Points and so on.  And just like with C++, it is so easy to get the syntax right but still miss the benefits altogether.  But unlike the poor chap with the first bicycle in the world, we have precedent on which to base our hope and studies that show us what will and will not work.

 Standing with your team for fifteen minutes each morning will not improve your situation if you turn it into a project status meeting or a hang-out session.

Having a Backlog populated with micro-managing tasks that are disjoint and have no business value attached will not improve your team’s ability to deliver value to the company’s bottom line.

Getting yourself a Scrum Master will not change the dynamic if s/he is just the directive, controlling Manager of the team and continues the old behaviors in a new meeting.

For any of you who lived through that C-to-C++ transition with me, you’ll recall that “ah HA!” moment when you suddenly realized that OOP, event driven, multi-threading development was fundamentally a new creature – as different as monkey and man.  You, too, found that only a small percentage of the neural pathways in your brain that worked for procedural coding still served you well after making the change.  The shift to Scrum is no less demanding, as we have to rewire our brains if we are going to succeed.

As an Agile Coach, I get to see how many times people in crisis fail to the familiar and jeopardize all of the progress we’ve made.  It is sometimes disheartening but then I remember that changing minds is first a logical act, but then very much a physical one.  The brain literally has to rebuild itself to establish new behaviors, and that just takes time.

Many years ago, I found myself standing on the snowy slopes of a ski resort in California waiting for the start of my first snowboarding class.  The ruddy cheeked instructor blasted downhill into the waiting crescent of students, spraying us with snow as he ground to a standing halt.  His first words to us were these:

“How many surfers do we have in the group?”  No hands were raised.

“How about skateboarders?”  Again, no one moved.  I started getting worried that I’d never get snowboarding if those skills were required.

“AWESOME!” he exclaimed.  “It’s SO HARD to un-teach that stuff on the slopes!  But with no surfers or skaters, you guys are going to be awesome!  Follow me!” 

In no time, we were off on our first run.

Self-Organization: Ants Can, But Can We?

We’ve long admired the ability of the lowly ant to organize without central command and achieve remarkable feats of engineering and collaboration. But I have often heard people say, “That’s fine for ants but humans won’t do that!” Their argument seems to be founded in their evaluation of our intelligence — which, most would argue, is superior to that of an individual ant.

Consider the following two videos — both of intersections and traffic congestion in Hanoi, Vietnam. Although they have many lines on the roadways, the thing two things that first strike the Western eye are the fluidity of movement and the complete absence of signs, traffic signals, barriers and other traditional necessities for dangerous intersections.

Keep your eye on the pedestrians and cyclists who move through the frame. Because of their steady, confident and precisely maintained pace, drivers can confidently predict where that pedestrian will be at a future point in time and calculate how to avoid them — which they do with sometimes uncomfortable precision.

But this behavior is not unique to Hanoi. In fact, the city of Drachten, NL has famously created what they call Naked Intersections with remarkable success. It seems that they had a particularly dangerous intersection that had seen 8 serious accidents in the previous 4 years. As people of a command-and-control mindset do, their first instinct was to put more regulation, more signs, more signals, more rules and more gridlock into the intersection which was already brimming with all of those items. But instead, they opted to go a different way. They eliminated all signals, signs, lanes and barriers and replaced them all with one simple rule: cars must yield to pedestrians and cyclists. And when they did, something amazing happened!

Drivers approaching the intersection slowed down because they believed that the deregulated intersection was perceived to be much more dangerous than the over-regulated version had been. Then, traveling at lower speeds, they began to do another amazing thing. Instead of looking for signals, signs and stripes on the roadway — all of which had been removed — the drivers were looking at the other people passing through the intersection and making real-time decisions about their acutal situation rather than following some complex, prescribed ruleset. This greater awareness and connectivity to their fellow travelers did something that the city planners had not dared to hope: in the subsequent 4 years after the intersection became a self-organizing thoroghfare, not a single serious accident had been recorded, while the throughput of the intersection skyrocketed.

In these examples, we see several principles of Scrum applied. Self-organization is obvious. But we also see the importance of a Predictable/Sustainable Pace. Notice that when the travelers change direction, the other travelers just flow effortlessly around them with a minimum of congestion or delay. But the reason they have the freedom to change directions is specifically that they maintain a steady pace as they cross. Can you imagine how this would snarl if a car entered the intersection lurching and braking unpredictably? Chaos would ensue. And what about the importance of communication? Eye contact, signaling intent with body posture and, of course, the horns to announce their presence are all key to entering and exiting unscathed.

Self-organization. Communication. Predictability. Success!

We often forget what Scrum is and is not. Because the majority of Scrum adopters work in the software industry, many take it for granted that Scrum simply tells us how to create software. It does not. Some even make the mistake of referring to it as an SDLC. But it is not.

Scrum was never focused on what we were trying to produce. Instead, it focuses entirely on how we try to produce it! Scrum teaches us how to organize ourselves as a group of intelligent, human animals who share a goal. It teaches us to play to our natural strengths and depend on our evolved skills to maximize our successes as social animals. And as it turns out, when we are caught playing to our strengths and actively engaging our environment, we are also found reaching higher, running faster and more confidently attempting tasks we otherwise would not have considered.

Tuesday, August 19, 2008

Product Backlogs and You

I just received this question from one of my co-workers and, because I get it frequently, I thought I would post both the question and my response to it. She is on a project that has been going for some time now but which was being driven through old/traditional PMI techniques. Because it was failing, as those techniques do about 85% of the time, we recently transitioned them to Scrum. She writes:

One thing that everyone wants to know is “when will we be done with the project” – and that would mean that we go through every story – spec out every task – assign points/owners to each. So I am confused about two things :

1. Where does the team find the time to do this for every post-it on the backlog wall? I am assuming the whole team needs to be involved in this exercise.

2. Points do not translate into time taken. So let’s say even if we did do 1, all we would get is points. How do I convert this into “this project will be done by date xx/xx/xxxx”.

Any help you can provide will be great.

My response is below:

You’re right to be concerned about the size of the task in front of you. It’s going to be a bit dicey and time consuming to get things set up, but it will be well worth it.
You are correct that the entire team needs to come together to create estimates in Story Points for every card (User Story or Story Card) on the Product Backlog. While it would be excruciating to break each card down to the task level before estimating, that is thankfully not necessary.
The first thing to remember is that up to 5% of your Sprint length should always be allocated to helping your SPO get better visibility/estimates on the Product Backlog. For people on a one week Sprint, like yourself, that is about 2 hours per week of estimating effort. To do the estimates efficiently, you’ll want to subdivide your Product Backlog into three zones.

Zone One, at the top of the Product Backlog, should always contain approximately two Sprints (two weeks) worth of work broken into adoptable cards and estimated. Zone Two should contain slightly more detail (but not fully actionable cards). Zone Three contains raw, undigested User Stories.
Zone One needs to be estimated in detail, with negotiations when estimates vary widely and thorough discussions to reach consensus. Zones Two and Three should receive quick/rough estimates where you, as the Scrum Master, may choose to either average the votes or select the high vote from the first ballot. Because Zone Two is slightly more digested than Zone Three, this will provide more accuracy in Zone Two than in Zone Three. Expect the team to protest this behavior but assure them that they will get to re-estimate each card as it moves between Zones and is broken down.
So how does all this result in a date? Once you have a rough estimate on the length of your Product Backlog, you use the team’s calculated Velocity to estimate how many Sprints worth of work remain to be achieved. So, for example, suppose you go through this exercise and find that you have 612 Story Points of estimated work on your Product Backlog. If your team’s Velocity is 72 Points per Sprint and Sprints are one week long, then you know that you have (612/72=8.5) Sprints worth of work to achieve, or a little over two months. Because the boundaries of the Sprints are all firmly fixed (no sliding or changing begin/end dates!) then you can translate this number into a date.
Now what if 8.5 weeks is too long? The first thing you’ll want to do is to be sure that you are only pursuing mandatory work during that time. Remove any unnecessary User Stories from the calculation and re-estimate the delivery date. If it is still too long, see if you can outsource some of the work to another team. If that is not possible, and because Scrum is the only framework ever proven to scale linearly, you can ask them to give you more resources. The trick here is that you have to continue to respect the “7 +/- 2” rule on team size and may have to make multiple Scrum teams.
I hope this helps but let me know if you have further questions.
Yeah, it’s simple. But it sure ain’t easy…

Transitions are hard.
Change is scary.
Uncertainty is… well… uncertain.

Dealing with the human and emotional reactions to change is the hardest part of implementing Scrum effectively. Especially in an established organization where people already have established behaviors, expectations and domains, these changes can feel overwhelming, frustrating, inefficient or, in some extreme cases, even insulting.

The good of the many outweighs the good of the one,” a famous Vulcan said (hey, I made it this far without a Star Trek reference… it was tough!). In general, most of us agree with that most of the time. But in corporations, our ability to apply this bit of wisdom is often limited. Whether based on fear, politics or a loyalty to “the way things have always been”, this kind of rigidity coming from the upper eschelons of a company usually foretells the end of its growth phase and the beginning of its decline. But, with Scrum specifically, the multiplicity of concerns are generally not from the Executives, who are sold on the ability to achieve hyper productivity. It more frequently comes from people at the mid- to lower-layers of the company.

People who have built their careers around being superheroes are suddenly asked to become team players. Managers are turned into servants — an easy transition for some, but a very difficult one for those who are more authoritarian. The familiar tools are usually judged inadequate or counter-productive for an effective implementation of Scrum, and that can frustrate the career plans of those who have spent years amassing skills and certifications with those tools. When a company stops communicating in the old language of hours, projects, assignments and the “QA cycle”, formerly composed professionals can feel adrift, bored or demoted.

A person’s reaction to change depends in large part on their general outlook on life. I was once chatting with a fellow — sort of an Eeyore kind of guy, if you know what I mean — about the changes that come with a Scrum adoption. “If nothing changes,” I said enthusiastically, “how do you expect anything to ever get better?” He turned to me, completely stone-faced, and said, “I don’t expect them to get better. I just don’t expect them to get any worse either.” It’s a fair concern.

When you try new things, the likelihood of failure increases. Suddenly, people are broken out of their established patterns and are asked to engage the company’s business in a brand new way. I was recently told by a Manager that, before Scrum, a certain employee had been happy to sit idle in his cube for days on end without uttering a word. Those kind of people don’t do very well in an effective Scrum company. Scrum will simultaneously add work to the plates of those who have been coasting while taking away the busy work from those who believed that simply being busy creates value. Being busy is great, but only if you’re busy heading in the direction identified by the company — and most busy-work workers aren’t.

But for every naysayer or Eeyore you’ve got in your company, you’ll have 10 people who are enthusiastic, open-minded and embracing the positive changes they see Scrum bring. They’re just not usually as vocal as the people who feel that they are suddenly engaged in a fight for their very careers, and that’s a shame. Almost all of the employees in an established company have a good and purposeful home under Scrum but many close their ears after the briefest of overviews. The chief blessing of Scrum can also be a curse — its simplicity.

A description of Scrum comes in twelve bullet points: Three Roles, Three Artifacts, Three Ceremonies and Three Best Practices. But that’s just a description. A real understanding of Scrum comes from a deeper study of self-organization, emergent behaviors and human nature. People who scan a book and develop an opinion or an implementation are likely to leave out some of the most fundamentally powerful components of Scrum simply because they are uncomfortable to implement.

There are a few truths that sound blasphemous to most Engineering minds. For example:

– To generate more value, write less code.
– Multitasking is value embezzlement.
– Never implement more than 40% of your requirements.

Too many people who start picking and choosing from Scrum’s twelve points do so without the basic understanding of why the points were there and how they play into the achievement of hyper productivity. They stand before several methodologies and fuss over items from each like my Grandmother looking at vegetables in a market, picking some and tossing out others. Now if your company makes money and generates value by building a methodology, then more power to you. But if your company’s product is other than a methodology, maybe it’s time to buy a proven, tested and well exercised methodology off the rack and focus your energies, instead, on building product.

Compromise is not always a virtue — especially when the compromise is between a few noisy people clinging to the old methodologies, and an energized plurality willing and eager to make the quantum leap.

Prioritizing your backlog can be one of the more confusing exercises when your team first attempts to shift toward Scrum. It’s all too easy to wave your hands at it and say, “That’s the Product Owner’s problem, not mine” — but no matter what your role is on the team, you’ll likely get involved at some point in time so it’s a process worth understanding.

When you properly feed a Product Backlog, it will actually prioritize itself. The problems most of us encounter come from not feeding it correctly. We stick task cards in without estimates. We adopt cards that fail to state business value. Or sometimes we attempt to dictate solutions with the cards we enter. So let’s start from the beginning and see if we can’t all get on the same page.

First, User Stories must state a goal instead of a solution. The reason that Scrum leads companies to hyperproductivity is because it removes the Command & Control model that artificially limits a team’s intelligence and speed to match the intelligence and speed of the Commander. A multiplicity of intelligent people pursuing a clear goal will always yield a quicker and superior result to having a central controller directing multiple workers. So job one is to state the problem, not the solution.

Next, you need to be sure that all work considered by your team has a clear and stated business value. Any work that doesn’t seek to generate value should be discarded as wasteful. Now some people will read that sentence and object that Engineering Initiatives and bug fixes are important, too. I agree. Just keep in mind that some work is an indirect value contribution — like refactoring a module, for example. At first glance it looks like an expense but the ROI comes in the form of improved performance, increased stability or greater speed and accuracy when modifying that module for future feature support. So even infrastructure work and bug fixes carry Business Values, and they should be clearly stated just as with new feature requests.

So now you’ve got a collection of User Stories that state the problems instead of the solutions, and each has a statement of Business Value attached. You’re almost done. The last missing component is the statement of complexity from Engineering (a.k.a. “the Story Point Estimate”). This will likely lead to a long negotiation between the Product Owner and Engineering, during which they will mutually examine and modify the proposed User Story. Once it passes muster, the User Story can enter the Product Backlog and easily find its place in the queue.

Now there are a few sorting algorithms that you can choose to apply to your properly populated Backlog. You can choose to organize your backlog strictly by financial opportunities, but that may be short-sighted for your longer term goals for the company. You could organize your backlog to pursue a sequence of themes, but you may leave money or business opportunities on the table if you do this blindly. Or you could sort by desirability — must-have, nice-to-have and optional. Personally, I think you should sort your backlog in each of the three ways and look for overlapping patterns to emerge.

No single method of sorting your backlog is likely to be right 100% of the time. This is why each team needs a dedicated Product Owner who can spend time analyzing the backlog to be sure that the team is heading in the best possible direction from each of the three perspectives. But before there is any hope of success, you must have a Business Value and a Complexity Statement on a card that conveys the problem, not the solution.

The ScrumMaster-Go-Round

I’m not sure why, but there seems to be a significant portion of the population out there who believe that Scrum Master duties should rotate from person to person each Iteration. It’s usually touted as a “share the pain” policy, with some even saying “nobody should have to do that all the time – they’d go mad!”

Scrum Masters are specialized resources in an organization, just like Architects, Developers, QA and Managers. I doubt anyone would think it’s a very good idea to have each team member take a turn as Architect, rotating once per Iteration. They should be equally uncomfortable suggesting that about Scrum Masters, and I’ll tell you why.

Getting a team comfortable with a Scrum Master takes some time. Just like introducing a new sheepdog to a flock (the often-invoked image of Scrum Masters and their charges), it’s difficult in the beginning. Not only will the new Scrum Master fumble and falter initially but the disruptions will ripple through the team and reduce your value contribution until everyone settles into their new surroundings.

A Harvard study reported that more than 3/4 of all project failures are ultimately attributed to personal problems or issues between team members. If your Scrum Master, who is responsible for helping you resolve that issue, is almost always your peer except for one magical Iteration per quarter, odds of success plummet.

Becoming an effective Scrum Master takes more than just running the meetings. It’s about learning the team members, building a trust relationship, establishing paths of communication with the external resources the team utilizes and spending a significant amount of time analyzing and tracking metrics to discover how to tune the team to higher targeted value contributions.

Further, an Engineer doing a “rotation” as Scrum Master will almost certainly fall into the following traps:

1. S/He will not surrender personal contributions to the Iteration, which creates a conflict of interest when the Scrum Master duties interfere with the potential success of the card s/he adopted.

2. Not every Engineer on the team will have the respect and authority to adequately facilitate the meetings and correct behaviors on the team during the iteration.

3. Someone serving as Scrum Master for only one Iteration every few months will be at the absolute mercy of a Product Owner who holds the post almost permanently. One of the greatest values that the Scrum Master provides to the team is keeping the Product Owner in check.

4. Most team members don’t have (or need) a deep grasp of what the Velocity metric is trying to measure. But to act as an effective Scrum Master, they would have to understand that Velocity is the averaged commit achievement against targeted value contribution, and that adopted, found and punted work have to be handled very differently when calculating the team’s actual work capacity so they can guide them toward a safe commitment. Is this really what you want your Engineers thinking about for a whole Sprint?

I could list several more reasons but hopefully you are beginning to see that the role of Scrum Master is a specific and specialized organizational need, not to be equated with whose turn it is to take the trash out. It’s also valuable to note that, while the role of Scrum Master might sound horrific to the well-meaning Executives who suggest a rotation, there are those among us who love the role and will happily perform the duties without complaint. Frankly, though I started my career as a Software Engineer, I think I would rip my own eyeballs out if forced to return to it, even for one week per quarter.

Ultimately, Scrum is about creating a sustainable pace with a reliable outcome. If the team dynamics are in constant flux, the team will never settle into that rhythm that results in hyperproductivity. You might continue to do as well as you had done before trying to use Scrum, but you’ll never do better. And isn’t doing better the point?

Why not let everyone play to their strengths, individual interests and skills? Please, stop rotating the Scrum Masters! It only makes everyone queasy…