Tag: learning

In a previous post, I described several barriers to implementing scrum. Recently, an additional example came to light similar to the mistake of elevating scrum or Agile to a philosophy.

In a conversation with a colleague, we were exploring ways on how we might drive interest for browsing the growing wealth of Agile related information being added to the company wiki. It’s an impressive collection of experiences of how other teams have solved a wide array of interesting problems using Agile principles and practices. Knowing that we cannot personally attend to every need on every project team, we were talking through various ways to develop the capacity for exploration and self-education. I think I must have used the phrase “the information is out there and readily available” a couple of times to many because my colleague reacted to where I put the bar by comparing learning Agile to surgery.

Using the surgery metaphor, she pressed the comparison that all the information she needs about surgery is “out there and readily available” but even if she knew all that information she likely wouldn’t be a good surgeon. Fair point that experience and practice are important. And if that is the case, then everyone should be taking every opportunity they can to practice good agile rather than regressing to old habits.

More importantly, perhaps, is the misapplied metaphor. Practicing agile isn’t as complicated as surgery or rocket science or any other such endeavor that requires years of deep study and practice. Comparing it to something like that places the prospects of doing well in a short amount of time mentally beyond the reach of any potential practitioners.

Perhaps a better metaphor is the opening of a new rail line in the city. A good measure of effort needs to be expended to educate the public on the line’s availability, the schedules, how to purchase fares, where the connections are, what are the safety features, etc. Having done that, having “put the information out there where it is generally available,” it is a reasonable expectation that the public will make the effort to find it when they need it. It is unreasonable, and unscaleable, to build such a system and then expect that every passenger will be personally escorted from their front door to their seat on the train.

It is also interesting to consider what this does to the “empathy scale” when such an overextended metaphor is applied to efforts such as learning to practice Agile. If we frame learning Agile as similar to surgery then as people work to implement Agile are we more inclined to have an excessive amount of empathy for their struggles and be more accepting or accommodating of their short comings?

“Not to worry that you still don’t have a well formed product backlog. This is like surgery, after all.”

Are we as an organization and each of our employees better served by the application of a more appropriate metaphor, one that matches the skill and expectations of the task?

“We’ve provided instruction as to what a product backlog is and how to create one. We’ve guided you as you’ve practiced refining a product backlog. You know where to find suggestions for improving your skills for product backlog stewardship (wiki, books, colleagues, etc). Now role up your sleeves and do the work.”

Successful coaching for developing the ability in team members for actively seeking answers requires skillfully letting them struggle and fail in recoverable ways. It is possible to hold their hand too long. To use another metaphor, provide whatever guidance and instruction you need to so they know how to fish, then let them alone to practice casting their own line.

Related Posts

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.

Related Posts

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

Old joke: A young couple visiting New York City for the first time has lost their way. They spot a street musician, just the person to help them get reoriented. “Excuse us, but can you tell us how to get to Carnegie Hall?” The musician stopped playing and thought for a moment before replying: “Practice.”

The prevailing wisdom is that it takes 10,000 hours of practice to achieve the level of mastery in any particular field of endeavor. Turns out, this is true for fields with well-defined measures for excellence like chess and music. In each of these areas, the rules are relatively simple, but mastering them isn’t easy. It’s pretty easy to tell when someone is playing an instrument out of tune or off-beat. And yet, a pawn shop guitar in the hands of Joe Satriani or Liona Boyd will likely result in that instrument expressing a voice no one knew it had. As for chess masters, they’re the ones who win against all challengers regardless the time or place of the match.

For areas of human endeavor where the edges are less well defined, like business or coaching, there may be no marker for how much practice it takes to reach a stable mastery. Having successfully started and built one business does not guarantee the next venture will be equally successful. A coach with a winning system for one team may end up at the bottom of the ranks when the same system is used with a different team.

Developing expertise with scrum is a blend of both of these. The rules are simple, but they are not easy to master. At the same time the territory isn’t well defined and frequently changes. A new client, a new team, or a new project and the edges for what is possible change. Misunderstanding this has been at the root of much of the frustration I’ve observed among people new to agile. They come from a world with well-defined edges – traditional project management practices filled with Gantt charts, milestones, functional specifications, use cases, deployment requirements, and a plethora of other artifacts that “must” be in place before work can begin. As many unknowns as possible must be made known, risks pounded down to trivial annoyances, and all traces of ambiguity squeezed out of the project plan. Learning how to let go of deeply rooted practices like this is no small thing. We like the comfort of well-defined rules. And when there’s work to be done with scarce resources to make it happen, we reach for the rules most familiar to us.

So how can we update the tried-and-true, super comfy confines of past practices and rule sets?

Practice.

Research following on the “10,000 hours of practice” generalization has shown that it isn’t just that someone has completed 10,000 hours of practice. The critical factor was how they practiced. Was each hour spent completing the same motions and behaviors from the previous hour or were they spent building on successive experiences, seeking greater challenges, and developing a deeper understanding of their craft? Following the latter path leads to the incremental improvements required to build mastery. And once obtained, the same attitude toward practice helps sustain a level of mastery. There will always be something more to learn, a fresh perspective to experience, or a more satisfying way to experience success.

There is a great deal of neuroscience at the foundation of practice and few would dispute the value of learning how to learn. And yet as our experience grows and we master a particular field, it’s deceptively easy to fall into a complacency of thought whereby we convince ourselves there isn’t anything else to learn. That is until some seismic paradigm shift makes it clear the rules have changed and we’d let our mastery go stale. The consequences of this are captured by Greene (2012) in his book, Mastery:

“We prefer to live with familiar ideas and habits of thinking, but we pay a steep price for this: our minds go dead from the lack of challenge and novelty; we reach a limit in our field and lose control over our fate because we become replaceable.” (pg. 176)

If this happens, learning how to learn may not be enough. Learning how to unlearn may be equally valuable for regaining mastery.

In classic hacker culture, you aren’t a hacker until other recognized hackers call you a hacker. It’s a title to be earned, not claimed. The unfortunate title of “scrum master” aside, it is useful to take this credentialing tradition to heart with scrum as well. Consider yourself an apprentice scrum practitioner until other recognized scrum masters recognize your mastery. Holding such a frame keeps us humble, curious, and open to constant and never ending improvement.

I’ve been practicing, leading, or coaching scrum in one capacity or another for over 10 years and based on my billable hours over the past several years, I’m quite confident I’ve passed the 10,000 hour mark for practicing scrum. Even so, I’m not a master scrum master…yet. The reason is simple and is expressed by the great cellist Pablo Casals’ response to filmmaker Robert Snyder’s query as to why Casals continues to practice five hours a day at 80 years of age, “Because I think I am making progress.” I keep building upon my practice because each day I discover new ways to enhance team performance and improve my skills. Perhaps more telling, any time I think I’ve heard every excuse for not following the scrum framework, someone on one of my teams surprises me.

If you’re interested in staying on the path toward scrum mastery, you need to get out of the books and into the world. There are a variety of ready opportunities to mark and gauge your progress.

Frequently review the framework for scrum and compare what’s there with your current projects. If there are mismatches, find out why. Is there really a good reason for straying from the framework? If so, open a dialog about these differences during your retrospectives.

If possible, ask your fellow agile practitioners when they are holding their next review, backlog refinement, or sprint planning session and get yourself invited as an observer.

There are probably a number of excellent agile related meet-ups in your area. Speaking from personal experience, these are incredibly valuable communities of support and new ideas.

References

Greene, R. (2012). Mastery. New York, NY: Viking Penguin

This article was originally published by the Scrum Alliance under Member Articles.

Recently I had the opportunity to attend the Mile High Agile 2015 conference in Denver where Mike Cohn delivered the morning keynote address: “Let Go of Knowing: How Holding onto Views May Be Holding You Back.” As you might expect from a seasoned professional, it was an excellent presentation and very well received. A collection of 250+ scrum masters, product owners, and agile coaches is no stranger to mistakes, failures, and terrifying moments of doubt.

As valuable as the ideas in Cohn’s presentation are, I want to take them further. Not further into the value of keeping our sense of sureness somewhat relaxed, rather onto some thoughts about what’s next. After we’ve reached a place of acknowledging we don’t know something and are less sure then we were just a moment before, where do we go from there? It’s an important question, because if you don’t have an answer, you’re open to trouble.

The “I Don’t Know” Vacuum

Humans are wired to find meaning in almost every pattern they experience. The cognitive vacuum created by doubt and uncertainty is so strong it will cause seemingly rational people to grasp at the most untenable of straws. It’s a difficult path, but developing the skill for being comfortable with moments of doubt and uncertainty can lead to new insights and deeper understanding if we give our brains a little time to search and explore. Hanging out in a space of doubt and uncertainty may be fine for a little while, but it isn’t a wise place to build a home.

After acknowledging we don’t know something or that we’ve been wrong in our thinking, it’s important to make sure the question “What’s next?” doesn’t go begging. I’d wager we’ve all had the dubious pleasure of discovering what we don’t know in full view of others and in those situations the answer to this question becomes critical. It may not need an immediate answer, but it does need an answer. If you don’t work to fill the vacuum left by “I don’t know” or “I was wrong,” someone else surely will and it may not move the conversation in the direction you intended.

The phenomenon works like this. Bob, a capable scrum master, ends up in a situation that reveals a lack of experience or understanding with the scrum framework and doesn’t know what to do. Alice, maybe immediately or maybe later, moves into the ambiguity, assumes control, and tells the team what should be done. If Alice is wise in the ways of agile, this could end well. If command-and-control is her modus operandi in the defence of silos and waterfall, it probably won’t.

So how can an agile practitioner prepare themselves to respond effectively in situations of doubt and uncertainty? Here are a few things that have worked for me.

Feynman-ize the Conversation

In his book “Surely You’re Joking , Mr. Feynman!,” Nobel physicist Richard Feynman tells a story from his early career where several building engineers started reviewing blueprints with him, thinking he knew how to read them. He didn’t. Having been surprised by being placed in a position of assumed expertise, Feynman improvised by pointing at a mysterious but ubiquitous symbol on the blueprint and asking, “What if that sticks?” The engineers studied the blueprint in light of Feynman’s question and realized the plans had a critical flaw in a system of safety valves.

That’s how to Feynman-ize a conversation. Start asking questions about things you don’t understand in a manner that challenges those around you to seek the answer you need. In essence, it expands the sphere of doubt and uncertainty to include others in the situation. This tactic is particularly effective in situations where corporate politics are strong. Bringing the whole team into the uncertainty space helps neutralize unhelpful behaviors and increase the probability the best answer for the moment will be found. It is no longer just you who doesn’t know. It’s us that that don’t know. That’s a bigger vacuum in search of an answer. In short order, it’s likely one will be pulled in.

The Solution Menu

Thinking of the agile practitioners in my professional circle, they are all adept at generating possibilities and searching their experience reservoir for answers based on similar circumstances. When the creative juices or flow of answers from the past are somewhat parched by the current challenge, it is natural to project the appearance of not knowing. Unless you’ve drawn a complete blank, you can still use the less-than-ideal options that came to mind.

“I can think of several possible solutions,” you might say. “But I’m not yet sure how they can be adapted to this challenge.” Then offer your short list of items for consideration. One of those menu choices might be the spark that inspires a team members to think of a better idea. Someone else may find an innovative combination of menu choices that gets to the heart of the issue. I’ve even had someone mishear one of my menu choices such that what they thought they heard turned out to be the more viable solution. This is just another way to leverage the power of everyone’s innate drive for finding meaning.

Design an Experiment

If there is a glove that fits the “I don’t know” hand, it’s experimentation. I suppose you could work to stretch the guessing glove over “I don’t know.” But if your team is aware that you don’t know something, it’s worse if they know you’re pretending that you do. Challenges and problems are the situation’s way of asking you questions. If the answers aren’t apparent, form a solution hypothesis, set up a simple test, and evaluate the results. And as the shampoo bottle says: lather, rinse, repeat until the problem is washed away. It’s another way to expand the sphere of uncertainty to include the whole team and increase the creative power brought to bear on the problem. If your shampoo bottle is this agile, I’ve every confidence you can be, too.

Now I’m curious. What has helped you move past “I don’t know?”

This article was originally published by the Scrum Alliance under Member Articles.