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 video of an intersection in Hanoi, Vietnam. Although they have many lines on the roadways, the 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.

Watch it again, keeping 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 actual situation rather than following some complex, prescribed rule set. 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 thoroughfare  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.

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 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 echelons 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. 
• Implement at least 80% of your Sprint Backlog each Sprint, but never implement more than 40% of your product requirements in any given Sprint. 

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.

Backlog-o-Matic

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 hyper-productivity. 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…

A History Worth Repeating

"Never doubt that a small group of thoughtful, committed citizens can change the world. Indeed, it is the only thing that ever has." –Margaret Mead (1901-1978)

In the last decades of the 20^th century, some Engineering veterans began to discuss the perils and pitfalls of their industry. As they shared data with one another, they began to see that traditional projects were failing industry-wide more than 80%[i] of the time. Rigidity and expense were increasing even as customers were demanding more flexibility and lower costs. But while most of the industry was failing to deliver in this changing landscape, some teams rose to the challenge and even exceeded expectations. The study of these remarkable teams sparked a cultural wildfire that has been sweeping around the world, increasing productivity, flexibility and accuracy for the last twenty years.

It all began with two simple questions: How does a single organization give rise to both "rock star" and "average" teams? And can average teams be coached toward rock star performance? In order to answer their questions, this group of researchers undertook a series of studies that would evaluate the highest performing Engineering organizations around the world. A few of the more recognizable names among those studied were DuPont, Toyota, Nokia, Intel, iRobot, Borland, IBM and Xerox. The researchers collected and combed over data for years, reaching back in some cases as far as fifty years. Eventually, behavioral and cultural patterns began to emerge for those projects deemed most successful by the sponsoring organizations. The data, interviews and observations also began to suggest a surprisingly short but consistent list – just twelve points long – that defined the roles, ceremonies, artifacts and behaviors shared by these teams. Though deceptively simple in its brevity, and having been confirmed by real world observations, the publication of the twelve point list in 1986[ii] sparked controversy throughout the industry and inspired a flurry of competing studies around the world.

Among the most controversial points suggested by this brief list of best practices was the notable absence of some traditional roles, practices and artifacts. Even the original researchers had taken these for granted as essential when they began the study but there was no denying the evidence. More than just "missing", they found that these roles and artifacts actually shared an inverse relationship to the team's ability to become hyper-productive. Regardless of the product scope or duration, the more present they were on a team, the less likely the team would become hyper-productive. Project Management, Program Management, traditional project tracking tools and the ubiquitous command-and-control structure of most corporations had been either eliminated or distributed across altogether new roles as these teams evolved toward hyper-productivity.

It wasn't immediately clear to the researchers how the organizational needs were being met with these surprising omissions but understanding this would be essential if they were to develop the truly portable set of standards they hoped to describe. So, as Scientists do, they undertook a series of trials to test not only the portability of the list but to simultaneously test the necessity of each of the points. Could the list be reduced to just nine points? Were six sufficient? To find out, the researchers approached several organizations that were using traditional methodologies and, showing them the data they had collected, convinced them to participate in the experimental application of these best practices to their teams.

The first trial included only teams with an established reputation as reliable producers. From their ranks, a few were defined as control teams that would continue business as usual. The largest subset would be asked to apply varying subsets of the twelve point list while only a few were asked to strictly adhere to all twelve best practices. At the end of the trial, the results were even more astonishing than the researchers had hoped.

Not surprisingly, the teams who continued business as usual had their normal rate of value contribution. The teams who had used subsets of the twelve point list had maintained or only slightly improved their productivity. But the teams who strictly applied all twelve points were found to be, on average, 240% more productive[iii] than they had been just six months before. What's more, employee turn-over had plummeted, customer satisfaction had risen dramatically and employees noted a remarkable improvement in corporate culture for those organizations that complied fully.

In the intervening twenty years since the first studies were conducted, thousands of organizations around the world have adopted the twelve rules and built additional best practices on top of them. Some of these organizations are now achieving five to ten times the industry standard in productivity, while hybrid models and traditional methodologies top out at their original level of productivity.

The researchers, by the way, included Deming, Takeuchi, Nonaka, Ogannaike, Beck and, of course, Jeff Sutherland and Ken Schwaber. This set of best practices distilled from their collective research was first published in 1986 by Takeuchi and Nonaka in a Harvard Business Journal article titled "The New New Product Development Game", wherein they were first referred to collectively as Scrum.

---

[i] Using traditional Project Management methodologies and artifacts, projects of one million lines of code or more fail to meet expectations and customer needs between 70-85% of the time. See PA Consulting Group, 85% of IT Projects FailStandish Group Report on www.SDTimes.com. and the

[ii] The New New Product Development Game, Harvard Business Review, January 1, 1986, Hirotaka Takeuchi, Ikujiro Nonaka.

[iii] See the Softhouse paper, Scrum in Large Organizations

The Metrics Monster

Some people are scared to death of metrics. Over the last several decades, attempts to measure throughput or quality have almost always been a harbinger of layoffs, performance improvement plans or taking a significant percentage of the company’s staff overseas. I have been burned on more than one occasion by ISO, CMM, TQM and the other TLAs so I, too, have been conditioned to loathe metrics. They are usually painful to collect, complicated to compile and always seem to fall somewhere along a continuum between Counterproductive and Punitive. But it goes deeper than attempts to measure project ROI or individual value contribution. Our loathing for metrics, regardless of our role in the organization, actually springs from the heart of the daily business in old style Engineering teams.

Although traditional Project Management insists upon the mythical Unchanging Specification, everyone knows that Product Managers can’t think of everything in advance when writing a PRD. Our playing along with the fantasy doesn’t result in eliminated churn but instead forces Product Managers to be creative about how to get changes in without being punished – things like inclusion of vague sections that they can later “clarify” to include forgotten requirements. Of course, Engineering knows Product Management has to do this so they inflate their estimates even more than they already had to account for their own unknowns. Then Management, who has been through this many times before, cuts the delivered estimate by half – effectively insisting that everything go perfectly the first time. Management dictates a short date to a Project Manager, who grabs a Gantt chart and sets out a series of milestones that become millstones nobody wants to support, and the self-delusional project is underway. It’s an unhealthy cycle that is based on an assumption of malice, stupidity and laziness though nothing is usually further from the truth. And it’s an approach that gives a false feeling of control but increases surprises and disappointments even as it tries to eliminate both.

The truth is that most employees genuinely want to contribute value to the organization but their varied skill sets mean that they have to work together to identify where that value is and how best to achieve it. The inherent contention in a traditional Project Management organization prevents that collaboration from even being a point for consideration. Now that’s not to say that traditional Project Management is incapable of delivering. Of course they can, and have for decades. But the organization spends so much time and energy dealing with the nested half-truths and webs of self-preservation that their productivity becomes artificially limited well below what it could be.

We know that there are certain skills that humans naturally possess.

Similarly, there are skills that we do not have. Traditional Project Management is, unfortunately, built around three things that humans are horrible at doing:

• Creating an exhaustive list that includes all assumptions, risks and caveats. If you want to see how bad you are at this, have a group of several friends maliciously comply with your directions and then give them instructions to walk across the room and turn a light off. Watch the variety of assumptions or details that you forget to state as they collapse into the floor or stumble over one another!

• Estimating quantity, duration, distance or mass. Think this one is wrong? Next time you go to a new restaurant, estimate how many minutes it will take from the time your server takes your order until the time you have finished eating your meal. Or if you’re really adventurous, walk up to a few strangers on the street, estimate their combined weight and ask them to total it up for you.

• Refusal to adapt. One of the reasons humans have done such an exceptional job at dominating the Earth is that we adapt so quickly that we don’t even realize we’re doing it in some cases. How did your commute to work go over the last five days? Was each day exactly the same, or did you have to adapt? Our minds simply aren’t wired to follow a set of plans or behaviors while ignoring changing environmental feedback.

1. Everyone at every level accepts that facts and goals around the project will change.
2. Working relationships are established to reward and encourage trust, openness and communication.
3. The whole organization assumes responsibility for dealing with change, not just the person or group who discovered the need for it.

Healthy teamwork requires trust – which is the last thing that traditional Project Management encourages in a team. But by shifting the metrics we collect and how they are used, we can begin to see a healthier and more productive environment begin to emerge. So instead of focusing on “exhaustive lists” where we know we will fail, let’s state the known and agree to discover the unknown together, which is something we all do well. And let’s give up estimates in quantity, duration, distance or mass so we can provide estimates based on complexity and grouping of similar items, at which we excel. And finally, instead of punishing deviation from a plan as the project proceeds, let’s reward adaptation that leads to better, more accurate or satisfying deliverables.

These are three of the basic tenets of Scrum, and why it achieves higher quality, more meaningful results and faster deliverables over time. By playing to the natural strengths and interests of people on the team, everyone’s quality of life is improved, from the Customer to the CEO. With a Scrum team,

And, yes, Scrum does create some metrics but they are not the same old metrics from traditional Project Management. Because Scrum focuses on the known and the possible over the desired, and makes the entire organization responsible for the adaptation to the discovered, these metrics can exist safely without being weaponized.

So when you’re first getting into Scrum, you may find yourself having an alarmed reaction to the metrics it creates. On a team of seven people, usually at least one will say that Scrum feels like micro-management at the beginning. But over time, provided with positive support and reinforcement, most see that Scrum is liberating them from the deceptions and inflations encouraged by the serious problems of traditional Project Management and, by allowing them to increase their value contribution, their job satisfaction begins to soar.

The Myth of Multitasking

I recently had an engineer ask me, "Why does Scrum make me work so slowly? I felt like I was getting a lot more done before we started using Scrum." It's a fairly common question, so I thought I'd post the answer I gave him and a few details that came from our discussion.

His frustration came from the fact that he bought into the myth of multitasking. The more correct name for "multitasking" is Rapid Context Switching (RCS) – a skill that humans don't really have. Nevertheless, he felt like he was accomplishing a lot because at any point in time he would have four or more projects in progress. He felt that it increased his credibility among the engineers if he could provide a long list of projects whenever someone asked him what he's working on, and he would look back at each day with great pride for having been able to move each forward a bit. He was measuring his contribution in lines of code... but there are problems with that approach.

First, all of his projects were always in motion right up until the final deadline. As he crossed the finish line, he would do a Big Reveal to show his team which ones were finished and which ones weren't. He couldn't do it before the last day of the project because he didn't know himself which ones he would finish. His failures to deliver, combined with the surprise factor at the end of the project, would launch the rest of the team into a scramble to account for his missing code. As you can imagine, he wasn't very popular among his peers but Management loved him because they saw him as the guy with the highest bandwidth. He had fooled them into measuring work in progress rather than work completed – which brings me to the second problem with this approach.

As a software engineer, you create value when you have user-relevant code working correctly in production. Until your code is available for revenue generation, you really haven't contributed any bankable value for the company.

Finally, the RCS approach usually increases the time to delivery for any given project. It emerged because we as an industry were too indulgent with un-prioritized pools of work so the scatter shot approach increased the odds that you had done the right thing. But Scrum removes that problem altogether by insisting that the process starts with a triaged Backlog, ordered by Business Value. With that clarity, we no longer have to guess how to maximize our contributions.

We have to change how we think about value contribution and we have to shift our rewards to be in line with this new realization. We have to stop encouraging people to declare success and walk away until the code is in production and working to generate revenue for the company. In short, we have to measure people by what they complete, not what they start.

It's a Process, Not a Faith

Too many people approach Scrum like a religion. It's as if they believe that repeating some mystical lines from Schwaber's book will transmogrify the team. They move Post-It notes around a board but fail to communicate or clarify anything in the process. They draw charts but don't know their velocity. They estimate in story points but track in hours. In short, they have missed the point and are generally a danger to your organization.

The truth is that shifting an organization from a non-Agile methodology to Scrum is not for the faint of heart. It is a long, arduous and risky endeavor but pays exponential dividends to the successful. It requires a uniformity of purpose and mission clarity at every level of the organization and, for established organizations entrenched in old methodologies, it requires a strong, assertive and intuitive Scrum Coach. But whether you choose Scrum, Waterfall, XP, Lean or another methodology, your success still derives from good people, strong leadership, clear vision and commitment to excellence.

In "labs" around the world, Scrum has been tested at length and in a wide variety of organizations. Though it can be misapplied and half-hearted attempts do lead to failure, it has proven to be a remarkably successful process for human organization. It also increases the quality of life of everyone involved with the organization, from the customers to the CEO, when correctly applied. The data and success stories are overwhelming and measurable.

Here's one for you software engineering types out there.

Instead of religious ferver, how about we approach Scrum as a scientist would? Let's insist that any theories be justified by testable facts and metrics. Let's gather and review data, comb it over for anomalies and perform experiments to see where the boundaries of the theory break down. And that's the thing... There is already a lot of good news!

Does that mean Scrum will work for you? No.

But can it work? Almost certainly.

When a piece of software fails, which is more likely at fault?

• The Programming Language
• The Engineer
• The Computer

The answer is, of course, B: The Engineer. Making syntax mistakes, misusing constructs or failing to grasp the larger concept set forth by the language leads to horrific code and non-functional applications. It reminds me of the early days of Object Oriented Programming, and how C programmers would pick up a C++ compiler and work all manners of mischief on the code. I remember frequently seeing C programmers create an object then fill up the Constructor with C-style, procedural code. It was nauseating.

Taking an organization to hyper-productivity with Scrum is much more algorithm than incantation. Instead of considering Scrum to be magic or religious, consider it to be like a new programming language. Any language brings with it "must" and "must not" rules that, when applied correctly, yield the benefits of its specific strengths. In this case, however, we're programming organizations instead of computers. When companies adopt Scrum top-to-bottom and follow its "linguistic" rules, we see time and again that they uniformly begin to over-perform.

And be wary of charlatans who encourage you to try a few parts of Scrum but retain the old structures and procedures for the rest. They will most often reveal themselves by saying something like, "Let's compromise. We'll have daily stand-up meetings and give you a backlog, but we won't do planning meetings, observe Sprints, perform retrospectives, or track our velocity." It may seem like an incremental win but be warned: successes will be attributed to the compromise, failures will be attributed to the parts of Scrum you're using and this, my friend, is how you wind up with "Hello, World!" in your constructor.

You’re Unique, Just Like Everyone Else...

When I'm helping to coach a new team toward Scrum adoption, probably the most common objection I hear is something along the lines of, 

          "Yeah, well… Scrum is fine for you. But my 
          [team|project|company|product] is really incredibly special
          and completely unique in the world.  An out-of-the-box
          solution like Scrum just wouldn't work for us." 

I think this objection most often comes from the all too common misconception that Scrum is somehow tied to a technology, type of product or a certain pool of customers.

While it is true that most organizations successfully applying it today are software engineering firms, it is equally applicable to the local chapter of the PTA, automobile manufacturing and biochemical research. At its core, Scrum is a set of three characters, three rituals and three relics that each team contains or produces. In much the same way that basic laws governing traffic apply equally to all types of motorized vehicles, so these nine pillars of Scrum can be applied to your team. It can launch your team toward hyper-productivity, improve the lives of team members, give everyone a deeper sense of accomplishment and make your customers happier than they have ever been.

I recently had such a conversation with a colleague who insisted that his team could never utilize Scrum because he does research. We happened to be standing beside a whiteboard when he raised the objection so I began to interview him about his tasks and write them up on the board.

• "What are you researching?"
• "Are there a lot of research items waiting for your attention?"
• "Can you describe to me how you go about your research?"
• "How do you know if your research is heading in the right direction?"

In under ten minutes of interviewing him, I quickly learned that he was already applying a basic set of rules and processes to all of his research items regardless of the goal or subject. When I enumerated them on the board for him, his eyes widened and he said, "You mean those are my Scrum stories?? Wow. That's so cool!" Once he got that Scrum wasn't trying to tell him what to do or to micromanage his tasks, his mind opened and he saw how useful it can be to create the transparency and collaborative atmosphere that Scrum brings to a team.

So if you, like my colleague, have been struggling to understand how the rules of Scrum apply to your product, take a deep breath and relax. The fact is, they don't. They do, however, apply to the team that creates the product and the way they go about their work.

Introduction to my Scrum Blog

I have been in the Software industry for over 20 years now and have served at all levels of an organization. I started out as a Database and Unix System Administrator then moved into Software Engineering (Associate through Senior Software Engineer titles). I have been a Development Manager, Project Manager, Vice President of Engineering and Chief Architect. I also spent several years either moonlighting or primarily employed as a C Instructor, was a Microsoft Certified Instructor of C++/MFC and Win32, and taught Unix Shell Script Programming and Unix for Users and System Administrators.

I have worked with some of the best, and with some of the worst. I have been in healthy organizations that were very happy, empowering, educational and sometimes even inspirational places. I have been in "bleeding edge" companies, high profile security, obscure infrastructure and once even accidentally stumbled into a position with a spammer (I quickly left).

I have also been in the pits of hell from death marches, survived micro managers, outlived absentee managers, endured ego-maniacal architects, suffered with dishonest Product and Marketing Executives, bolstered battered QA engineers and even coached some very senior engineers with diva complexes into better behavior. I won't say that I've "seen it all" but I will say that it's rare that I see something new.

Frankly, although I have worked in some high profile companies that most people would consider to be very exciting, it has been a long time since anything in the tech industry ignited my passions. But recently I stumbled upon something that has my creative and energetic juices flowing again. It's a process that can improve not only the efficacy of any team of people with a goal but, when properly applied, it simultaneously improves the lives of the team members and the satisfaction of their customers. As you may have guessed from the name of this account and the title of this blog entry, I am of course talking about Scrum.

I am currently serving as the Master Scrum Master for a large and growing company that is striving to make both the structural and cultural shifts toward Scrum. It's not a path without pitfalls, to be sure, but I wanted to start this blog to track our progress, address issues we encounter and share war stories to help others who may be similarly engaged through what can be some treacherous waters.

So welcome to my blog. I hope you find it informative and useful, and I look forward to hearing your thoughts on my musings, too.

Cheers,
Scott