This one annoys me.
This one suits my purposes.
I pick the cherries.
This one annoys me.
This one annoys me.
This one suits my purposes.
I pick the cherries.
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?
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 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.
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:
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.
“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.”
“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.”
“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
Agile? What the hell?
This is not familiar!
Stand up. Now step two.
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:
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.
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.
Welcome changing requirements, even late in
development. Agile processes harness change for
the customer’s competitive advantage.
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.
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.
The rules are in place.
We’ve always done it this way.
Sound of waterfall.
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…
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.
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.
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.
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:
From a lean product development perspective, Oehmen and Rebentisch describe eight types of waste. I’ve included my additions and comments in parenthesis.
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