False Barriers to Implementing Scrum

When my experience with scrum began to transition from developer to scrum master and on to mentor and coach, early frustrations could have been summed up in the phrase, “Why can’t people just follow a simple framework?” The passage of time and considerable experience has greatly informed my understanding of what may inhibit or prevent intelligent and capable people from picking up and applying a straightforward framework like scrum.

At the top of this list of insights has to be the tendency of practitioners to place elaborate decorations around their understanding of scrum. In doing so, they make scrum practices less accessible. The framework itself can make this a challenge. Early on, while serving in the role of mentor, I would introduce scrum with an almost clinical textbook approach: define the terms, describe the process, and show the obligatory recursive work flow diagrams. In short order, I’d be treading water (barely) in endlessly circuitous debates on topics like the differences between epics and stories. I wrote about this phenomenon in a previous post as it relates to story points. So how can we avoid being captured by Parkinson’s law of triviality and other cognitive traps?

Words Matter

I discovered that the word “epic” brought forth fatigue inducing memories of Homer’s Iliad and Odyssey, the Epic of Gilgamesh, and Shakespeare. Instant block. Solution out of reach. It was like putting a priceless, gold-plated, antique picture frame around the picture postcard of a jackalope your cousin Eddie sent you on his way through Wyoming. Supertanker loads of precious time were wasted in endless debates about whether or not something was an epic or a story. So, no more talk of epics. I started calling them “story categories.” Or “chapters.” Or “story bundles.” Whatever it took to get teams onto the idea that “epics” are just one of the dimensions to a story map or product backlog that helps the product owner and agile delivery team keep a sense of overall project scope. Story writing progress accelerated and teams were doing a decent job of creating “epics” without knowing they had done so. Fine tuning their understanding and use of formal scrum epics came later and with much greater ease.

“Sprint” is another unfortunate word in formal scrum. With few exceptions, the people that have been on my numerous scrum teams haven’t sprinted anywhere in decades. Sprinting is something one watches televised from some far away place every four years. Maybe. Given its fundamental tenets and principles, who’s to say a team can’t find a word for the concept of a “sprint” that makes sense to them. The salient rule, it would seem, is that whatever word they choose, the team fully understand that “it” is a time-boxed commitment for completing a defined set of work tasks. And if “tide,” “phase,” or “iteration” gets the team successfully through a project using scrum than who am I to wear a the badge of “Language Police?”

A good coach meets the novice at their level and then builds their expertise over time, structured in a way that matches and challenges the learner’s capacity to learn. I recall from my early Aikido practice the marked difference between instructors who stressed using the correct Japanese name for a technique over those that focused more on learning the physical techniques and described them in a language I could understand. Once I’d learned the physical patterns the verbal names came much more easily.

Full disclosure: this is not as easy when there are multiple scrum teams in the same organization that eventually rotate team members. Similarly, integrating new hires with scrum experience is much easier when the language is shared. But to start, if the block to familiarization with the scrum process revolves around semantic debates it makes sense to adapt the words so that the team can adopt the process then evolve the words to match more closely those reflected in the scrum framework.

Philosophy, System, Mindset, or Process

A similar fate awaited team members that had latched onto the idea that scrum or agile in general is a philosophy. I watched something similar happen in the late 1980’s when the tools and techniques of total quality management evolved into monolithic world views and corporate religions. More recently, I’ve attended meet-ups where conversations about “What is Agile?” include describing the scrum master as “therapist” or “spiritual guide.” Yikes! That’s some pretty significant mission creep.

I’m certain fields like philosophy and psychotherapy could benefit from many of the principles and practices found in agile. But it would be a significant category error to place agile at the same level as those fields of study. If you think tasking an agile novice with writing an “epic” is daunting, try telling them they will need to study and fully understand the “philosophy of agile” before they become good agile practitioners.

The issue is that it puts the idea of practicing agile essentially out of reach for the new practitioner or business leader thinking about adopting agile. The furthest up this scale I’m willing to push agile is that it is a mindset. An adaptive way of thinking about how work gets done. From this frame I can leverage a wide variety of common, real-life experiences that will help those new to agile understand how it can help them succeed in their work life.

Out in the wild, best to work the system and process angles if you want meaningful work to actually get done.

Parkinson’s Law of Triviality and Story Sizing

From  Infogalactic: Parkinson’s law of triviality

Parkinson observed and illustrated that a committee whose job was to approve plans for a nuclear power plant spent the majority of its time on discussions about relatively trivial and unimportant but easy-to-grasp issues, such as what materials to use for the staff bike-shed, while neglecting the non-trivial proposed design of the nuclear power plant itself, which is far more important but also a far more difficult and complex task to criticise constructively.

I see this phenomenon in play during team story sizing exercises in the following scenarios.

  1. In the context of the story being sized, the relative expertise of each of the team members is close to equal in terms of experience and depth of knowledge. The assumption is that if everyone on the team is equally qualified to estimate the effort and complexity of a particular story then the estimation process should move along quickly. With a skilled team, this does, indeed, occur. If it is a newly formed team or if the team is new to agile principles and practices, Parkinson’s Law of Triviality can come into play as the effort quickly gets lost in the weeds.
  2. In the context of the story being sized, the relative expertise of the team members is not near parity and yet each of the individual team members has a great deal of expertise in the context of their respective functional areas. What I’ve observed happening is that the team members least qualified to evaluate the particular story feel the need to assert their expertise and express an opinion. I recall an instance where a software developer estimated it would take 8 hours of coding work to place a “Print This” button on a particular screen. The credentialed learning strategist (who asked for the print button and has no coding experience) seemed incredulous that such an effort would require so much time. A lengthy and unproductive argument ensued.

To prevent this I focus my coaching efforts primarily on the product owner as they will be interacting with the team on this effort during product backlog refinement session more frequently than I. They need to watch for:

  1. Strong emotional response by team members when a size or time estimate is proposed.
  2. Conversations that drop further and further into design details.
  3. Conversations that begin to explore multiple “what if” scenarios.

The point isn’t to prevent each of these behaviors from occurring. Rather manage them. If there is a strong emotional response, quickly get to the “why” behind that response. Does the team member have a legitimate objection or does their response lack foundation?

Every team meeting is an opportunity to clarify the bigger picture for the team so a little bit of conversation around design and risks is a good thing. It’s important to time box those conversations and agree to take the conversation off-line from the backlog refinement session.

When coaching the team, I focus primarily on the skills needed to effectively size an effort. Within this context I can also address the issue of relative expertise and how to leverage and value the opinions expressed by team member who may not entirely understand the skill needed to complete a particular story.

(John Cook cites another interesting example of Parkinson’s Law of Triviality (a.k.a. the bike shed principle) from Michael Beirut’s book How to involving the design of several logos.)

Showcasing Innovative Adaptations of Agile

Working Agreements

“Our working agreements had become a little cumbersome,” remarked Joseph, the PO for the Crain, Schmidt, and Poole account. “In fact, they were so bad we considered just adopting the Microsoft Windows End User License as an abbreviated version of our working agreements.”

“It was pretty ridiculous,” added Sonya, a software developer on the project. “Our first retrospective took eleven weeks to complete, mostly due to the delays caused by everyone’s lawyers working out the language around things that needed improvement. We all seemed pretty OK with taking responsibility for our own work but were adamant that someone else should be held accountable for the problems we were facing.”

“In the end we all agreed that Chester, the testing goat, should be the one held accountable. Dual use: testing goat and scapegoat. Seemed pretty efficient to us,” said Denny, the team’s tQA expert.

“And that’s where it all started. Our drive for greater efficiencies, I mean,” said Bernie, a second developer on the project. “Rather quickly, we were collapsing all sorts of two’s and three’s into one. Before long, our 342 page working agreements document was down to three sentences. The PO was thrilled to drop the attorneys from the project budget.”

“Yeah,” added Denny. “Even Chester is back to being just a plain ol’ testing goat again.”

Stand-ups

“Nobody says anything in stand-ups. Zip. Zero. Nada. Nothing.” proclaimed Kurt, scrum master for the Cleo Parker Robinson account. “It’s a room full of clinically certifiable introverts,” declared Seth, the project’s product owner. “They make Marcel Marceau seem annoyingly chatty by comparison,” he added. “Turns out, that was just us being blinded by our own biases and assumptions. One day, Tracy, one of the senior developers on the project all of the sudden slapped both her palms on the conference table, grabbed the polycomm, and started swinging it like a pendulum. Then Raj jumped up, put one hand over his left ear and stretched his right arm out straight. Then Truman made a noise that sounded something like ‘Ahhhhyooooye!’ and started pantomiming like he’s dealing cards. After that, all manner of odd behavior unfolded before our eyes.”

“By the end of the day,” Kurt added, “the number of cards for the sprint in the ‘Done’ column went from 20% to just over 80% – and there’s four days left in the sprint!”

“That’s when it struck us,” interrupted Seth. “The agile delivery team had been paying VERY close attention during the subject matter expert’s all day intensive discovery sessions from the design study. They were communicating their stand-ups through interpretative dance! From then on, it was easy. We just had to work to stay out of their way.”

Sprint Reviews

“We’d just kicked off the project with the Gucci account and muddled through our first working session, but it just didn’t feel productive,” said Carmine, a UI/UX expert. “Something was preventing us for actually getting to work. It was like we were pretending or something,” she added.

“So we hit on the idea we weren’t dressed for the part. We brainstormed a zillion outfit options and ran through an affinity exercise on the results before deciding on the optimal wardrobe,” chimed in Zeke, a tQA specialist.

“I have to admit, though,” shared Carmine. “It was a pretty awkward moment at the start of our first review with the client. There we were, sitting across the table from what must have been a million bucks worth of gabardine and silk and us in our flannel shirts, bib overalls, and work boots. Luckily, our PO is brilliant. She reached out, put her hand on the CLO’s shoulder and said, ‘Don’t worry. They’re Carharts!’ Huge sighs of relief filled the conference room knowing only quality name brands were present. We rolled up our sleeves and they loosened their ties and shirt collars and we stepped through a fantastic demonstration.”

The Future of Scrum

“Form a hypothesis, design an experiment, and then analyze the results. That’s really all we do,” said Guy Torqué, Senior Research Associate at the Institute for Advance Agile Research in Marseille, France. “We don’t always get it right. For example, we hypothesized that if standing up during meetings prompted participants to move through meetings more efficiently then perhaps if we had them stand on their heads the efficiency would increase even more. What we discovered is that people just passed out and meeting recovery time increased substantially. Similar results happened with our tests using advanced yoga poses.”

But that didn’t stop the intrepid researchers from pressing forward. They also experimented with having participants lighting and holding onto a match when it was their turn to speak during stand-ups. This did increase the speed at which individuals moved through the classic three questions for stand-ups, but unfortunately it also decreased productivity as agile delivery team members were less motivated to develop work products with burned fingers.

“Agile team role development is another area of acute research interest,” said Guy. “We’re currently testing a ‘Product Owner of Fortune’ hypothesis. Several weeks ago we dropped a dozen highly trained product owners deep into the interior of several politically unstable countries with a satchel full of sticky notes and marker pens. Our hypothesis is that they should be able to successfully define a set of minimum viable procedures that will successfully lead them out of the troubled areas. We haven’t heard back from any of them as yet. But it’s early,” he said, optimistically.

More Resources for the Curious

Conducting Stand-ups With Remote Teams

The dialog about the value of stand-up meetings is as vigorous as ever. I hope it never gets settled. That’s because I frequently argue both sides. Just not at the same time. Which side I’m on depends entirely on the context. If the team composed of a single functional domain that has worked together for an extended period of time while co-located in a tuned collaboration work environment, then stand-ups of any frequency are probably a waste of time. If the team is for the most part remote and composed of independent contractors representing multiple functional domains, than it can be argued that daily stand-ups become THE most important scrum meeting.

I want to talk about the latter scenario in this post. Remote stand-ups can be the most challenging meetings for a scrum master to facilitate. (In the interests of space, I’ll have to set aside cultural and language issues that are frequently an issue while running scrum with remote teams. I do this not to minimize the importance of these issues, but to recognize they are worthy of much better treatment than I can cover here.)

Remember the agile manifesto? The first two line read:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation

Simply stated: Don’t bother taking notes during a stand-up. Not as a group, anyway. Individual agile delivery team members are certainly free to do so if it helps their individual efforts. Stand-up notes are a false crutch. It’s as near to a 100% guarantee one can get to say that no one will every go back and re-read stand-up notes. If someone is demanding stand-up notes be taken, suspect a waterfall zombie in your midst and respond accordingly. Worse yet is that the poor agile delivery team member tasked with serving as scribe is going to be so busy trying to capture stuff they will miss much of the conversation and information exchange that makes a quality stand-up so vital.

Good Practices

  • Early in a project the scrum master should specifically call out team members during the stand-up and do so in a different order each day. This will prevent team members from talking over one another as they miss the visual cues that tell people meeting in person who is likely to speak next. Changing up the order keeps the whole team alert as they will not know when their name will be called. As the team gains experience with each other, switch to calling out the name of the team member who’ll kick off the stand-up conversation. When they’ve completed informing the team what they’ve worked on yesterday, what they’re working on today, and anything in the way of success the delivery team member calls out the next team member to take the conversation. This will further develop the remote behaviors that compensate for the missing non-verbal communication.
  • At least once a week, more frequent if warranted, briefly reiterate the sprint goals and minimum viable product (MVP) definition at the start of the stand-up. I’ve also found it very effective to challenge the team about mid-sprint with an intuitive check on how they are doing with respect to the sprint goals and MVP definition. Any feelings of dread there? Any sense of anxiety? If so, what’s causing that feeling. Move down the 5 Whys path to find any root causes. This will help shake out any hidden dependencies or reluctance by any one team member to ask for help.

Technology

Consider quality virtual meeting hardware and software an essential tool for your business. We wouldn’t accept a surgeon who goes into the operating room with kitchen knives because they’re “good enough.” Sound professional, be professional. Clear and efficient communication is essential to the success of remote agile teams. Have the best possible communication tools available in place and cut corners someplace else.

  • A good view of the scrum board via web conferencing. This is the big picture the team needs to keep their individual efforts in context of the whole sprint effort.
  • A high quality and reliable audio connection
    • How each team member’s cell reception? Does their connection drop frequently? Is their voice muffled or otherwise hard to hear? They may need a phone upgrade, particularly if their phone cannot leverage WiFi calling.
    • Are they on a land-line?
    • Are they using a cordless phone that’s subject to interference or cuts in and out?

Responding to change over following a plan

Welcome changing requirements, even late in
development. Agile processes harness change for
the customer’s competitive advantage.

Agile Manifesto Principle #2

Following from the Agile Manifesto value that is the title of this post, Principle #2 may be the most mis-interpreted and misunderstood principle among the set of twelve. Teams frequently behave as if this principle was prefaced with the word “always.”

Constantly shifting requirements leads to a frustrating and unsatisfying environment in which to work. It feeds burn-out and loss of morale. The satisfaction of a job well done depends on the opportunity to actually finish the job, no matter how small. Consider the effects on a finish carpenter who has just spent several days installing and trimming a full set of kitchen cabinets when the homeowner declares they want to change the kitchen design such that all those new cabinets will need to be ripped out and work begun on a new design. Or a film editor who has just worked 21 days straight to pare down an hour’s worth of video to fit into 7 minutes only to learn the scene has to be re-shot from scratch in order to match a change in the storyline.

Of course, the second principle does not state we should “always welcome changing requirements.” Nor does anyone I know claim that it does. But that doesn’t stop people from behaving as if it did. The rationale offered for agreeing to change requests from the stakeholders may be “We’re an agile shop and agile welcomes changing requirements” when, in fact, the change was agreed to because the product owner didn’t challenge the value of the change or make clear the consequences to the stakeholders. Or the original design was, and remains, needlessly ambiguous. Or the stakeholders have changed without renegotiating the contract or working agreements. Or any number of reasons that are conveniently masked with “welcoming changing requirements.” At some point, welcoming changing requirements is about as attractive as welcoming a rabid dog into the house. This won’t end well.

So, what kind of change is the Agile Manifesto referring to? There are several key scenarios that embody the need for flexibility around requirements.

  • The change that results from periods of deliberate design, such as during design sprints.
  • The change that is driven by the lessons learned from exploration and prototyping. If it is understood that the work being “completed” is for the purposes of testing a hypothesis and the expectation is that the work will most likely be thrown away, there can still be a great deal of satisfaction derived from the effort as the actual deliverable wasn’t working software, but the lessons from the experiment (usually in the form of a wireframe or prototype.)

So what is it that locks out the option for additional change? It’s a simple event, really. A decision is made.

Each of these scenarios where adapting to lessons and discovery is essential nonetheless end in a decision, a leverage point from which progress can be made toward a final deliverable. Each of these decisions can themselves form the basis of a series of experiments which, depending on the eventual outcome, may change.  Often, a single decision point may look good but when several decisions are evaluated together they may suggest a new direction and therefore impact the requirements. If the cumulative insight from a series of decisions results in the need to change direction, that shift is usually more substantial and on the scale of a project plan pivot rather than a simple response to a single change in a single requirement. The need to pivot cannot reliably be revealed if the underlying decisions do not coalesce into some sort of stable understanding of the emerging design.

Changing requirements cannot go on indefinitely or a final product will never be delivered. Accepting change for the sake of change is what gets teams into trouble.

Much like the forces on evolution, there will always be some external force that seeks to change the project requirements so that the delivered product can be stronger, faster, better, taller, smarter, etc.  This must be countered by clear definitions of “minimum viable” and “good enough” relative to what the customer is expecting.

In addition, product owners would serve their teams well by vigorously challenging any proposed changes to the requirements.

  • What is the source of the change?
  • Is it random change or triggered by some agent that does not announce its arrival ahead of time?
  • Was the change in requirements a surprise? If so, why was it a surprise?
  • Will this (or something like it) happen again? With what frequency? At what probability?

 

Agile Interns

I had the privilege of presenting to a group of potential interns from the Colorado School of Mines interested in agile project management. Action shot…

The slide shows what we can offer them as interns: Failure, chaos, and confusion. I unpacked that as follows…

Failure

It’s important interns have the opportunity to learn how to fail in small, deliberate and safe increments along with the opportunity to learn how to extract every possible lesson from failures and how those failures lead to eventual success. Much of our business is driven by experimentation and hypothesis testing. Most of those experiments will fail, at least initially.

Chaos

We strive to be anti-fragile. One way to accomplish this is to be good at working under chaotic and ambiguous conditions. When involved with highly evolutionary design sessions, shifting sands can seem like the most solid ground around.

Confusion

One of the values for bringing interns into the organization is the fresh perspective they offer.  Why waste that on having them fetch coffee? However, interns can often be intimidated by working with people who have decades of experience under their belt. So it’s important they know they have the opportunity to work in an environment that expects questions and recognizes no one knows it all. They are in an environment that  seeks alternative points of view. In this organization, everyone gets their own coffee.

Waste

What comes to mind when you think of the word “waste?” I’d wager a ten spot it wasn’t something pleasant. Rather, something to be pushed to the curb, rinsed down the drain, or thrown into a hole in the ground and buried. Even the sterile waste from technology projects has a high “ick” factor. If Josef Oehmen and Eric Rebentisch of MIT’s Lean Advancement Institute put the amount of time, money, and resource waste in corporate product development at 77%, how can there be anything good about waste?

Now think of something you value quite highly – a piece of fine jewelry, mastery of a sport or musical instrument, or your home. Have you considered how many resources may have been “wasted” to bring those highly valued things into existence? Shiny diamonds get that way by cutting and throwing away pieces of the original, mastering a sport or a musical instrument involves years filled with bad moves or cringe worthy sounds, and a significant amount of material was used and discarded while building your home.

When organizations consider implementing one of Agile’s many formalized methodologies or frameworks, the idea of eliminating waste is a prominent promise that helps close the sale. Cutting out waste means saving money and saving money means increasing profits. Unfortunately, this promise is frequently delivered to the agile teams as: “All waste is bad. Get it right the first time.” This message doesn’t support exploration and discovery. It doesn’t allow teams the space they need to find innovative solutions in what Stuart Kauffman called the “adjacent possible.” And it certainly doesn’t encourage the iterative development of numerous minimum viable products that build upon each other and lead the way toward the delivery of quality products.

The message I work to reinforce is: “Expect to throw stuff away, especially early on.” By itself, this isn’t enough to overcome the many negative connotations around waste. What is needed is a fundamental re-framing around the activities that have resulted in something one expects to throw away. A couple of questions are worth asking. What value is anticipated from the activity? What are the potential positive effects of having engaged in an effort at risk for ending as waste? Pursuing a goal of zero wasted effort is a fool’s errand. What we want to reduce is any effort that doesn’t add value. If 40 hours were spent exploring a technical option “only” to find out that it wasn’t a viable option in the long term, that throw-away 40 hour effort may just have saved 400 hours of developer time spent trying to make it work. And had the less-than-optimal long term option gone to market, the expense of supporting the early wrong decision could make or break the product, perhaps even the business.

Skilled agile practitioners have a strategy for monitoring the value of any project related efforts:

  • Establish definitions of activities that create value. By identifying the intent behind the effort and acknowledging the value, the team is better positioned for focusing on the goals and objectives of the activity. Discovery, exploration, risk assessment, even fun can be worthwhile justifications if it is clear they add value to the overall effort and end goal success.
  • Identify efforts that are wasteful, but nonetheless necessary, and work to minimize the effects of these efforts. Transitioning from a design sprint to actual production work often results in a lull in activity as the design team works to communicate to the production team what needs to be done. Similarly, when production work is handed off to deployment, support, and maintenance teams.
  • Identify clear signs of waste. Gold-plating (over-engineering), lack of a product vision or road map that causes the agile team to “make it up as they go along” and react to the customer’s reaction, infrequent opportunities for feedback (both inter-team and with the client), or time-tracker cards that attract dozens of hours of nondescript time.

From a lean product development perspective, Oehmen and Rebentisch describe eight types of waste. I’ve included my additions and comments in parenthesis.

  • Overproduction of information
    • Two different groups creating the same deliverable
    • Delivering information too early
  • Over-processing of information
    • Over-engineering of components and systems (Often referred to as Gold-platting.)
    • Working on different IT systems, converting data back and forth (The use of one-off tools rather than leveraging the capabilities within the organization’s suite of tools.)
  • Miscommunication of information
    • Large and long meetings, excessive email distribution lists
    • Unnecessary hand-offs instead of continuous responsibility
    • (Unacknowledged project dependencies, such as the effect of re-architecting system components, on client projects.)
  • Stockpiling of information
    • Saving information due to frequent interruptions
    • Creating large information repositories due to large batch sizes
    • (Withholding opportunities to review work and solicit feedback.)
  • Generating defective information
    • Making errors in component and architecture design
    • Delivering obsolete information to down-stream tasks (Insufficient feedback opportunities, delays in communication due to competing project responsibilities.)
  • Correcting information
    • Optimization iterations (Rework)
    • Reworking deliverables due to changing targets (Design ambiguity, client decision instability)
  • Waiting of people
    • Waiting for long lead time activities to finish
    • Waiting due to unrealistic schedules
  • Unnecessary movement of people
    • Obtaining information by walking up and down the hallway
    • Traveling to meetings

References

Kauffman, S.A. (2003). The Adjacent Possible, A Talk with Stuart A. Kauffman. Retrieved from https://www.edge.org/conversation/stuart_a_kauffman-the-adjacent-possible

Oehmen, J., Rebentisch, E. (2010). Waste in Lean Product Development. Lean Advancement Initiative. Retrieved from http://hdl.handle.net/1721.1/79838

Page 3 of 41234