Improving The Odds of Success For Any Goal With A Definition of Done

In 1626 the King of Sweden, Gustavus Adolphus, began work on what he envisioned would be the most powerful battleship ever to set sail – the Vasa. By all accounts, Gustavus was a brilliant military commander. Over the next two years the King repeatedly alter specifications such that massive amounts of rework were required. The mid-project inclusion of non-essential work – such as adding close to 500 elaborately decorated sculptures – added to the delay. The array of canon on the ship grew both in size and number. The result was an untested design that proved unstable when the ship was launched with great fanfare from the shipyard in Stockholm. Before King and country, the Vasa hadn’t made it out of the harbor before a strong breeze tipped the ship so far that water began entering the canon portals and sank the ship.

The lessons from this historical event about meddling managers embedded in a hierarchical system of status and nobility are obvious. This practice is still very much endemic in legacy corporations and MBA programs continue to crank out a plethora of future executives equipped to carry on the tradition. Thousands of executive and Agile coaches make a well deserved living working to remediate the problem.

A lesser but more actionable lesson has to do with Gustavus’ approach to project management. As brilliant as he was on the battlefield, this skill did not translate to the material production field where events move toward completion over months and years rather than hours and days.

There is a reason Agile project management leverages frameworks rather than highly structured protocols for getting work done. It recognizes that the world can be a messy place. Particularly when it requires human beings to complete work. With so many variables in play – emotions, physical health, competing priorities around family, pandemics, etc. – it’s amazing we get as much done as we do. Frameworks give us the flexibility to adjust and adapt to the situation.

There is a paradox embedded within Agile frameworks. Flexibility and adaptability are important, but there are also elements of the frameworks that are important to get right. The most important is to have a healthy product backlog that is vigorously maintained and defended by the product owner. If this isn’t in place, everything else become a major battle to implement. Stories bounce across multiple sprints, errors and rework grow exponentially and stakeholders readily jump to uncomfortable conclusions about progress.

Another important element is what’s typically called the “definition of done.” If the product owner or Agile team member can’t clearly and concisely describe what “done” looks like, you end up with some version of this conversation.

Product Owner: “What do you mean you’re still working on that story. I closed it last sprint because you said it was ‘done!'”

Agile Team Member: “Well, uh, yeah. It was done. But it wasn’t done done. There were still a couple of things I wanted to finish.”

If your definition of done is some version of “I’ll know it when I see it,” there is a good chance you’re about to attempt the launch your very own Vasa.

If you’d rather not do that, here are a few things to do instead:

  • If you are involved during the design phase of the project, repeatedly run a thought experiment where you begin with the end in mind. It’s that vision statement thingy.
  • Work to establish a clear understanding of what “good enough for now” means. And when you’ve done that, keep checking in with your team to evaluate if anything has changed to cloud that understanding.
  • Use minimum viable product definitions. Add to this the idea of minimum viable actions. As important as it is to know, as best you can, what done looks like, you need a sequence of actions that will get you there. What are those? In what order can they most effectively be sequenced? How jis what you’re learning along the way changing the path to “done?”
  • Finally, keep your product backlog healthy and strong. Without exception, continuously refine the backlog with stakeholders and the development team so that it is an accurate reflection of progress and future work.

Photo by Jamie Morrison on Unsplash

What’s in YOUR manual?

 

You go to see a movie with a friend. You sit side-by-side and watch the same movie projected on the screen. Afterward, in discussing the movie, you both disagree on the motives of the lead character and even quibble over the sequence of events in the movie you just watched together.

How is it that two people having just watched the same movie could come to different conclusions and even disagree over the sequence of events that – objectively speaking – could have only happened in one way?

It’s what brains do. Memory is imperfect and every one of us has a unique set of filters and lenses through which we view the world. At best, we have a mostly useful but distorted model of the world around us. Not everyone understands this. Perhaps most people don’t understand this. It’s far more common for people – especially smart people – to believe and behave as if their model of the world is 1) accurate and 2) shared with everybody else on the planet.

Which gets me to the notion of the user manuals we all carry around in our heads about OTHER people.

Imagine a tall stack of books, some thin others very thick. On the spine of each book is the name of someone you know. The book with your partner’s name on it is particularly thick. The book with the name of your favorite barista on the spine is quite a bit thinner. Each of these books represents a manual that you have written on how the other person is supposed to behave. Your partner, for example, should know what they’re supposed to be doing to seamlessly match your model of the world. And when they don’t follow the manual, there can be hell to pay.

Same for your coworkers, other family members, even acquaintances. The manual is right there in plain sight in your head. How could they not know that they’re supposed to return your phone call within 30 minutes? It’s right there in the manual!

It seems cartoonish. But play with this point of view for a few days. Notice how many things – both positive and negative – you project onto others that are based on your version of how they should be behaving. What expectations do you have, based on the manual you wrote, for how they’re supposed to behave?

Now ask yourself, in that big stack of manuals you’ve authored for how others’ brains should work, where is your manual? If you want to improve all your relationships, toss out all of those manuals and keep only one. The one with your name on the spine. Now focus on improving that one manual.


Photo by Ying Ge on Unsplash

Agile Money

In a recent conversation with colleagues we were debating the merits of using story point velocity as a metric for team performance and, more specifically, how it relates to determining a team’s predictability. That is to say, how reliable the team is at completing the work they have promised to complete. At one point, the question of what is a story point came up and we hit on the idea of story points not being “points” at all. Rather, they are more like currency. This solved a number of issues for us.

First, it interrupts the all too common assumption that story points (and by extension, velocities) can be compared between teams. Experienced scrum practitioners know this isn’t true and that nothing good can come from normalizing story points and sprint velocities between teams. And yet this is something non-agile savvy management types are want to do. Thinking of a story’s effort in terms of currency carries with it the implicit assumption that one team’s “dollars” are not another team’s “rubles” or another teams “euros.” At the very least, an exchange evaluation would need to occur. Nonetheless, dollars, rubles, and euros convey an agreement of value, a store of value that serves as a reliable predictor of exchange. X number of story points will deliver Y value from the product backlog.

The second thing thinking about effort as currency accomplished was to clarify the consequences of populating the product backlog with a lot of busy work or non-value adding work tasks. By reducing the value of the story currency, the measure of the level of effort becomes inflated and the ability of the story currency to function as a store of value is diminished.

There are a host of other interesting economics derived thought experiments that can be played out with this frame around story effort. What’s the effect of supply and demand on available story currency (points)? What’s the state of the currency supply (resource availability)? Is there such a thing as counterfeit story currency? If so, what’s that look like? How might this mesh with the idea of technical or dark debt?

Try this out at your next backlog refinement session (or whenever it is you plan to size story efforts): Ask the team what you would have to pay them in order to complete the work. Choose whatever measure you wish – dollars, chickens, cookies – and use that as a basis for determining the effort needed to complete the story. You might also include in the conversation the consequences to the team – using the same measures – if they do not deliver on their promise.


Photo by Micheile Henderson on Unsplash

Improving the Signal to Noise Ratio

Ellen Fishbein asks, “Why NOT be an information sponge?” In the Age of Information, I think her answer is a good one: “I currently believe that each of us must move away from the ‘information sponge’ mindset and try to develop a more nuanced relationship with information.”

I’d have to characterize myself as more of an information amoeba – (IIRC, the amoeba is, by weight, the most vicious life form on earth) – on the hunt for information and after internalizing it, going into rest mode while I decompose and reassemble it into something of use to my understanding of the world. Yum.

More generally, to be an effective and successful consumer of information these days, the Way of the Sponge (WotS, passive, information washes through them and they absorb everything) is no longer tenable and the Way of the Amoeba (WotA, active, information washes over them and they hunt down what they need) is likely to be the more successful strategy. The WotA requires considerable energy but the rewards are commensurate with the effort. WotS…well, there’s your obsessive processed food eating TV binge-watcher right there. Mr. Square Bob Sponge Pants.

What’s implied by the WotA vs the WotS is that the former has a more active role in optimizing the informational signal to noise ratio than the latter. So a few thoughts to begin with on signals and noise.

Depending on the moment and the context, one person’s signal is another person’s noise. Across the moments that make up a lifetime, one person’s noise may become the same person’s signal and vice versa. When I was in high school, I found Frank Sinatra’s voice annoying and not something to be mingled with my collection of Mozart, Bach, and Vivaldi. Today…well, to disparage the Chairman of the Board is fightin’ words in my house. Over time, at least, noise can become signal and signal become noise.

But I’m speaking here of the signal quality and not it’s quantity (i.e. volume)

Some years ago I came across Stuart Kauffman’s idea of the adjacent possible:

It may be that biospheres, as a secular trend, maximize the rate of exploration of the adjacent possible. If they did it too fast, they would destroy their own internal organization, so there may be internal gating mechanisms. This is why I call this an average secular trend, since they explore the adjacent possible as fast as they can get away with it.

This has been interpreted in a variety of ways. I carry this around in my head as a distillation from several of the more faithful versions: Expand the edge of what I know by studying the things that are close by. Over time, there is an accumulation of loosely coupled ideas and facts that begin to coalesce into a deeper meaning, a signal, if you will, relevant to my life.

With this insight, I’ve been able to be more deliberate and directed about what I want or need to know. I’ve learned to be a good custodian of the edge and what I allow to occupy space on that edge. These are my “internal gating mechanisms.” It isn’t an easy task, but there are some easy wins. For starters, learning to unplug completely. Especially from social media and what tragically passes for “news reporting” or “journalism”these days.

The task is largely one of filtering. I very rarely directly visit information sources. Rather, I leverage RSS feeds and employ filtering rules. I pull information of interest rather than have it pushed at me by “news” web sites, cable or TV channels, or newspapers. While this means I will occasionally miss some cool stuff, it’s more than compensated by the boost in signal quality achieved by excluding all the sludge from the edge. I suspect I still get the cool stuff, just in a slightly different form or revealed by a different source that makes it through the filter. In this way, it’s a matter of modulating the quantity such that the signal is easier to find.

There is a caution to consider while optimizing a signal-to-noise ratio, something reflected in Kauffman’s comments around the rate of exploration for new ideas: “If they did it too fast, they would destroy their own internal organization…”

Before the Internet, before PCs were a commodity, before television was popular it was much, much easier to find time to think. In fact, it was never something that had to be looked for or sought out. I think that’s what is different today. It takes WORK to find a quiet space and time to think. While my humble little RSS filters do a great job of keeping a high signal-to-noise ratio with all things Internet, accomplishing the same thing in the physical world is becoming more and more difficult.

The “attention economy,” or whatever it’s being called today, is reaching a truly disturbing level of invasion. It seems I’ve used more electrician’s tape to cover up camera lenses and microphones in the past year than I’ve used on actual electrical wires. The number of appliances and gadgets in the home with glowing screens crying out for bluetooth or wifi access like leaches seeking blood are their own source of noise. This is my current battleground for finding the signal within the noise.

Enough about filtering. What about boundaries. Fences make for good neighbors, said someone wise and experienced. And there’s a good chance that applies to information organization, too. Keeping the spiritual information in my head separate from my shopping list probably helps me stop short of forming some sort of cult around Costco. ( “All praise ‘Bulk,’ the God of Stuff!)

An amoeba has a much more develop boundary between self and other than a sponge and that’s probably a net gain even with the drawback of extra energy required to fuel that arrangement. Intellectually, we have our beliefs and values that mark where those edges between self and other are defined.

So I’ll stop for now with the question, “What are the strategies and mental models that promote permeability for desired or needed information while keeping, as much as possible, the garbage ‘out there?’”


Image by Pete Linforth from Pixabay

Baseballs and Hockey Pucks

“Keep your eye on the ball!” I was always coached when learning how to play baseball. Seemed like reasonable advice while standing at the plate, facing down the pitcher for the opposing team. Certainly wouldn’t want to be daydreaming or casting my gaze to the horizon. It didn’t seem to help, though. I excelled at striking out.

Later…much later…I came across Wayne Gretzky’s quote: “Skate to where the puck is going, not where it has been.” I wonder if I had learned to figure out where the baseball was going to be and made sure my bat was there to meet it if I might have spent more time on bases. Keeping my eye on the ball didn’t tell me much about when to start my swing.

No regrets. I still love the game (as it was, not as it currently is.)

I think of this Gretzky quote when I watch product owners struggle with organizing their backlog. (I also think how tragic it is that the business world has beat this quote into an intolerable pulpy platitude.)

Ask a product owner what their team is working on today, they should be able to give a succinct answer. Ask them what their team is going to be working on in three months and watch the clock. The longer they can go on about what their team is going to be working on, the healthier their backlog is likely to be. Struggling product owners scramble to keep their teams busy sprint-to-sprint. Good product owners can see where their teams are going to be in several months. Great product owners see to the end of the game.


Photo by Chris Chow on Unsplash

Minimum Viable Product – It’s What You Don’t See

Take a moment or two to gaze at the image below. What do you see?

 

Do you see white dots embedded within the grid connected by diagonal white lines? If you do, try and ignore them. Chances are, your brain won’t let you even though the white circles and diagonal lines don’t exist. Their “thereness” is created by the thin black lines. By carefully drawing a simple repetitive pattern of black lines, your brain has filled in the void and enhanced the image with white dots and diagonal white lines. You cannot not do this. This cognitive process is important to be aware of if you are a product owner because both your agile delivery team members and clients will run this program without fail.

Think of the black lines as the minimum viable product definition for one of your sprints. When shown to your team or your client, they will naturally fill the void for what’s next or what’s missing. Maybe as a statement, most likely as a question. But what if the product owner defined the minimum viable product further and presented, metaphorically, something like this:

 

By removing the white space from the original image there are fewer possibilities for your team and the client to explore. We’ve reduced their response to our proposed solution to a “yes” or “no” and in doing so have started moving down the path of near endless cycles of the product owner guessing what the client wants and the agile delivery team guessing what the product owner wants. Both the client and the team will grow increasingly frustrated at the lack of progress. Played out too long, the client is likely to doubt our skills and competency at finding a solution.

On the other hand, by strategically limiting the information presented in the minimum viable product (or effort, if you like) we invite the client and the agile delivery team to explore the white space. This will make them co-creators of the solution and more fully invested in its success. Since they co-created the solution, they are much more likely to view the solution as brilliant, perfect, and the shiniest of shiny objects.

I can’t remember where I heard or read this, but in the first image the idea is that the black lines are you talking and the white spaces are you listening.

Relative Team Expertise and Story Sizing

In Parkinson’s Law of Triviality and Story Sizing, I touched on the issue of relative expertise among team members during collaborative efforts to size story cards. I’d like to expand on that idea by considering several types of team compositions.

Team 1 is a tight knit band of four software developers represented in Figure 1.

Figure 1 - Team 1
Figure 1 – Team 1

Their preferred domain and depth of experience is represented by the color and area of their respective circles. While they each have their own area of expertise, there is a significant overlap in common knowledge. All four of them understand the underlying architecture, common coding practices, and fundamental coding principles. Furthermore, there is a robust amount of inter-domain expertise. When needed, the HTML5/CSS developer can probably help out with JavaScript issues, for example. The probability of this team successfully working together to size the stories in the product backlog is high.

Team 1 represents a near-ideal team composition for a typical software related project. However, the real world isn’t so generous in it’s allocation of near-ideal, let alone ideal, teams. A typical team for a software related project is more likely to resemble Team 2, as represented in Figure 2.

Figure 2 - Team 2
Figure 2 – Team 2

In Team 2, the JavaScript developer is fresh out of college,  new to the company and new to the business. His real-world experience is limited so his circle of expertise is smaller relative to his teammates. The HTML5/CSS developer has been working for the company for 10 years and knows the business like the back of her hand. So she has a much wider view of how her work impacts the company and product development. As a team, there is much less overlap and options for helping each other through a sprint is diminished.  As for collaborative story sizing efforts, the HTML5/CSS and C# developers are likely to dominate the conversation while the JavaScript developer agrees with just about anything not JavaScript related.

As Agile practices become more ubiquitous in the business world, team composition beings to resemble Team 3, as shown in Figure 3.

Figure 3 - Team 3
Figure 3 – Team 3

The mix now includes non-technical people – content developers and editors, strategists, and designers. Even assuming an equal level of experience in their respective domains, the company, and the business environment, there is very little overlap. Arriving at a consensus during a story sizing exercise now becomes a significant challenge. But again, the real world isn’t even so kind as this. We are increasingly more likely to encounter teams that resemble Team 4 as shown in Figure 4.

Figure 4 - Team 4
Figure 4 – Team 4

As before, the relative circle of expertise among team members can vary quite a bit. When a team resembles the composition of Team 4, the software developers (HTML5/CSS and C#) will have trouble understanding what the Learning Strategist is asking for while the Learning Strategist may not understand why what he wants the software developers to deliver isn’t possible.

When I’ve attempted to facilitate story sizing sessions with teams that resemble Team 4 they either become quite contentious (and therefore time consuming) or team members that don’t have the expertise to understand a particular card simply accept the opinion of the stronger voices. Neither one of these situations is desirable.

To counteract these possibilities, I’ve found it much more effective to have the card assignee determine the card size (points and time estimate) and work to have the other team members ask questions about the work described on the card such that the assignee and the team better understand the context in which the card is positioned. The team members that lack domain expertise, it turns out, are in a good position to help craft good acceptance criteria.

  • Who will consume the work product that results from the card? (dependencies)
  • What cards need to be completed before a particular card can be worked on? (dependencies)
  • Is everything known about what a particular card needs before it can be completed? (dependencies, discovery, exploration)

At the end of a brief conversation where the entire team is working to evaluate the card for anything other than level of effort (time) and complexity (points), it is not uncommon for the assignee to reconsider their sizing, break the card into multiple cards, or determine the card shouldn’t be included in the sprint backlog. In short, it ends up being a much more productive conversation if teammates aren’t haggling over point distinctions or passively accepting what more experienced teammates are advocating. The benefit to the product owner is that they now have additional information that will undoubtedly influence the product backlog prioritization.

Innovation and Limits to Growth

In a basic growth model, some finite resource is consumed at a rate such that the resource is eventually depleted. When that happens the growth that was dependent on that resource stops and the system begins to collapse. If it happens that the resource is renewable eventually the rate of consumption matches the rate of renewal and the system enters into a state of equilibrium (no growth). This is illustrated by the black line in Figure 1. In this second scenario if the rate of consumption exceeds the rate of renewal the system will again collapse.

In the Solow model of growth (neoclassical growth model) a new element is introduced: the effect of technology or innovation on the growth curve. Without innovation, in systems where technology stays fixed, growth will eventually stop. The introduction of innovative solutions to resource problems, however, has the effect of raising the upper bound to growth limits. This is illustrated by the red line in Figure 1.

Figure 1 - Innovation Boost
Figure 1 – Innovation Boost

A prevailing assumption with innovation is that it is necessarily synonymous with invention. To be innovative is to create something that has not previously existed. This is an erroneous assumption. History is filled with accounts of dominant societies furthering their success by adopting innovative discoveries made by smaller societies. The adoption of Arabic numerals by countries that had previously used Roman numerals is a striking example of a dominant society integrating an innovation from a smaller society.

The challenge for an organization, then, isn’t so much how to be innovative, rather, how to better recognize and adopt innovations discovered elsewhere. More succinctly, how to better seek out and distinguish innovative solutions aligned with the organization’s strategy from those that simply rate high on the coolness scale.

False Barriers to Implementing Scrum – II

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.


Photo credit: langll