Broken Windows and Broken Scrum

Recently, I was in a conversation with a scrum master that was of the opinion that correcting teams on all the small details of practicing scrum was the best way to develop them into a high performing team. For example, if someone is a minute late to stand-up, call them out. Or daily stand-up must not deviate from the “Yesterday, today, and in the way” script regardless how well the team is communicating.

I can see the merits of developing discipline. However, this approach reminds me of the Broken Windows Theory of crime reduction. Without explanation or coaching that includes the rational for practicing scrum in such a way, there is a real possibility for negative unintended consequences.

  • The Broken Windows theory was meant to be applied to situations in need of a reduction of crime. To apply this approach to scrum practices is to imply that any deviation from the scrum framework is criminal.
  • Similar to how the Broken Windows theory resulted in the emergence of “zero tolerance” laws, applying such an approach to scrum teams and the rigor to how they may or may not follow the scrum framework is likely to result in a lot of command-and-control zero tolerance enforcement of the framework. The guides will become rules and, in turn, inflexible laws.

The approach I’ve found to be more effective is to hunt down the root causes to issues, for which being late to stand-ups or poor communication during stand-ups are a symptom. It’s more like being a big game hunger. Seek out the root of the problem, solve that problem, and it’s likely many of the lesser issues will resolve themselves.

Estimating Effort – An Explicitly Implicit Approach

It is difficult to make predictions, especially about the future.Unknown

Sage advice.

So why bother estimating the amount of work needed to complete a product backlog item? After all, since estimates are about the future the probability is high that they will be wrong. Actually, they may very well be guaranteed to be wrong. It’s just that some of the guesses happened to match what the effort ended up to be and just look like they were “right.”

I’ve written in the past expressing my thoughts about estimating the effort needed to complete product backlog items, particularly with respect to story points. I believe working to find a relative gauge to how well teams are estimating work is important. Without them, cognitive biases such as the optimism bias and planning fallacy can significantly distort a project delivery timeline. However, the phrase “story point” is burdened with a lot of baggage. It has been abused and misused such that invoking the phrase often causes more harm than good.

I’ve been experimenting recently with different approach to estimating effort. The method I’ll describe in this post got a bit of a boost after listening to a recent interview with Psychologist and Nobel laureate Daniel Kahneman. In this interview, Kahneman describes an experience he had while serving in the Israeli army some sixty years ago. He was assigned the job of setting up an interview process that would determine how well a recruit would do as a combat soldier. For this process, he selected six traits and instructed the interviewers to ask questions designed to evaluate each trait independently and score them. The interviewers were not happy with this approach. As a compromise, Kahneman instructed the interviewers, when they were finished asking about the six traits, to close their eyes and just jot down a number they felt matched how good a soldier the recruit might be. What he discovered:

When we validated the results of the interview, it was a big improvement on what had gone on before. But the other surprise was that the final intuitive judgments added, it was good. It was as good as the average of the six traits, and not the same. It added information, so actually we ended up with a score that was half determined by the specific ratings, and the intuition got half the weight. That, by the way, stayed in the Israeli army for well over 50 years.Daniel Kahneman

This intuitive evaluation made by the interviewers is similar to what Agile methods ask of development teams when determining a value for “story points.” T-shirt sizes, planning poker, dot voting, affinity mapping and many similar techniques are all designed to elicit an intuitive sense of the effort involved. If there is a dependency between team members, than a dialog follows to understand what that discrepancy is all about. This continues until there is alignment on what the team believes the effort to be. When it works, it works well.

So on to the details of the approach I’ve been experimenting with. (It doesn’t have a name yet.) The result of this approach is a number I call the “effort value.” The word “value” is a reference to the actually elementary mathematics value being derived. Much like the answer to the question “What value results from adding 2 and 2?” Answer: 4. The word “value” also suggests an intrinsic worth, something beyond a hard number. My theory is that this will help teams think beyond the mere number and think also about the value they are delivering to stakeholders. The word “point” correlates to a hard number and lacks any association to intrinsic worth or value.

Changing the words introduces a simple and small shift that nonetheless has a significant impact. With the change, teams are more open to considering a different approach to determining estimates.

So how is the effort value derived?

I begin by having the team define 4-5 characteristics or attributes that, to them, describe what they mean by “effort.” It is important for the team to define these attributes. By doing so, they own the definition and it becomes much harder for them to dismiss the attributes as “some else’s” and thereby object to their use in deriving an effort value. These attributes can be anything that is meaningful to the team. Examples:

  • Complexity – Is the work straightforward (e.g. code a bubble sort function) or does it involve interrelated systems (e.g. code a predictive inventory control algorithm)?
  • Dependencies – How dependent is the product backlog item on other backlog items or other teams?
  • Familiarity – Is this work very similar to work the team has done in the past or something quite new?
  • Information – Is the detail in the product backlog item complete? Are the acceptance criteria and definition of done clear?

The team can define any attribute they wish. However, there are a few criteria to consider:

  • Keep the list limited to 4-6 attributes. More than that risks turning the derivation of an effort value into the equivalent of a product backlog item navel-gazing exercise.
  • Time cannot be one of the attributes.
  • The attributes should be reasonable. Assessing a product backlog item’s effort value by evaluating it’s “aura” or the current position of the stars are generally not useful attributes. On the other hand, I’ve listen to arguments against evaluating estimates in terms of “complexity” as being similarly useless. I see the point of those arguments, but my view is that the attributes must first and foremost be meaningful to the entire team. In the end, it an educated guess and arguments about the definition of terms like “complexity” are counterproductive to the overall intent of deriving an effort value.

Each of these attributes is then given a scale, the same scale for each attribute – 1 to 10, 1 to 15 – whatever the team feels is most appropriate. The team then goes through each of these attributes and evaluates the product backlog item attribute on the scale. The low number on the scale represents very little impact. If dependency, for example, is one of the attributes then a 1 might mean that the product backlog item is entirely self-contained. A 10 might represent a case where the product backlog item is dependent on several other product backlog items or perhaps the output from other teams.

When this is done, ask the team where on the modified Fibonacci scale they think this particular product backlog items effort value should be. If they’re struggling you can do the math: find the average for all the attributes and match that number in the modified Fibonacci scale. If he average as a decimal, for example 3.1, match the value to the next highest modified Fibonacci scale number. In this case the value would be 5. Then ask the team if they feel that number it’s a good representation of the effort value for the product backlog item.

Yes, I know. This is fluff. But technical people like simple processes that they understand and numbers they can calculate. The number isn’t what’s important here. What’s important is the conversation that happens around the attributes and what the team feels about the number that results from the conversation. This exercise is meant to develop their intuitive muscles for considering multiple aspects and dimensions behind the “effort” needed for them to get the work done.

Use this process enough times and eventually calculating the average can be dropped from the process. Continue using this process and eventually calculating the numbers for the individual attributes can be dropped from the process. I don’t know if it’s a particularly good idea the drop the use of the attributes for generating the needed conversation around the effort needed, but it will certainly be valuable to reconsider the list of attributes from time to time so as to fine tune the list to match what the team feels is important.

With this approach I’m turning the estimation process on it’s head (or back on it’s feet, if Kahneman is right.) Rather than seek the intuitive response first (e.g. t-shirt size) and elicit details later if there is a mismatch between team members, this method seeks to better prime and develop the team’s intuition about the effort value by having them explicitly consider a list of self-selected attributes (or traits) for effort first and then include an intuitive evaluation for effort.

Don’t try to form an intuition quickly, which was what we normally do. Focus on the separate points, and then when you have the whole profile, then you can have an intuition and it’s going to be better. Because people form intuitions too quickly, and the rapid intuitions are not particularly good. If you delay intuition until you have more information, it’s going to be better.Daniel Kahneman

Coder’s Lullaby

[Sung to the tune of Woody Guthrie‘s Hobo’s Lullaby.]

Go to sleep you weary coder.
Let the output scroll on by.
Hear the cooling fans a hummin’.
That’s the coder’s lullaby.

Do not think about the deadlines.
Let the deadlines come and go.
Tonight you’ve got a nice warm cubie.
Safe from all the deadline woe.

Go to sleep you weary coder.
Let the output scroll on by.
Hear the cooling fans a hummin’.
That’s the coder’s lullaby.

I know the bosses cause you trouble.
They cause trouble everywhere
When you die and go to heaven,
You’ll find there are no bosses there.

Go to sleep you weary coder.
Let the output scroll on by.
Hear the cooling fans a hummin’.
That’s the coder’s lullaby.

Assessing and Tracking Team Performance – Part 9: Design Changes and Scope

Changes in design can either be tightly or loosely coupled to changes in scope. In general, you can’t change one without changing the other. This is how I think of design and scope. Others think of them differently.

Few people intentionally change the scope of a project. Design changes, however, are usually intentional and frequent. They are also usually small relative to the overall project design so their effect on scope and progress can go unnoticed.

Nonetheless, small design changes are additive. Accumulate enough of them and it becomes apparent that scope has been affected. Few people recognize what has happened until it’s too late. A successive string of “little UI tweaks,” a “simple” addition to handle another file format that turned out to be not-so-simple to implement, a feature request slipped in by a senior executive to please a super important client – changes like this incrementally and adversely impact the delivery team’s performance.

Scope changes primarily impact the amount of Work to Do (Figure 1). Of course, Scope changes impact other parts of the system, too. The extent depends on the size of the Scope change and how management responds to the change in Scope. Do they push out the Deadline? Do they Hire Talent?

Figure 1 (click to enlarge)

The effect of Design Changes on the system are more immediate and significant. Progress slows down while the system works to understand and respond to the Design Changes. As with Scope, the effect will depend on the extent of the Design Changes introduced into the system. The amount of Work to Do will increase. The development team will need to switch focus to study the changes (Task Switching. ) If other teams are dependent on completion of prior work or are waiting for the new changes, Overlap and Concurrence will increase. To incorporate the changes mid-project, there will likely be Technical Debt incurred in order to keep the project on schedule. And if the design impacts work already completed or in progress, there will be an increase in the amount of Rework to Do for the areas impacted by the Design Changes.

Perhaps the most important secondary consequence of uncontrolled design changes is the effect on morale. Development teams love a good challenge and solving problems. But this only has a positive effect on morale if the goal posts don’t change much. If the end is perpetually just over the next hill, morale begins to suffer. This hit to morale usually happens much quicker than most managers realize.

It is better to push off non-critical design changes to a future release. This very act often serves as a clear demonstration to development teams that management is actively working to control scope and can have a positive effect on the team’s morale, even if they are under a heavy workload.

 

Responsibility and Improvement

Feral chickens on the Hawaiian Island of Kaua’i are ubiquitous. And they can be aggressive, particularly when they are roaming around common outdoor eating areas.

While the vast majority of visitors to the island honor the signs that say “Don’t Feed the Chickens,” all it takes is a couple of noob’s to put the operant conditioning in motion and keep it going with each new planeload of first-time and unaware visitors.

I watched the consequences of this play out during a recent trip to the island. I was enjoying a cup of coffee and a blueberry scone at The Spot in Princeville. (Side Bar: GO HERE! The food and coffee is FANTASTIC!) A young couple, obviously new to the island, collected their breakfast order at the service window, selected a table, and then went back to the service window to get utensils, napkins, and whatever else. Left unattended for less than 5 seconds, the chickens were on the table and a sizeable rooster had made off with a croissant.

I can only describe the woman’s response as upset and indignant. She promptly returned to the service window and asked – expectantly – for a replacement. To which The Spot employee directed her attention to the sign above the service windows that said, “DO NOT LEAVE FOOD UNATTENDED. Chickens are aggressive and will attack your food if not guarded. WE ARE NOT RESPONSIBLE FOR THE CHICKENS AND CANNOT REPLACE DAMAGED FOOD FOR YOU.”

There are two (at least) lessons to be learned from this. One by the patron and one by the owner of The Spot.

First, the patron. Five bucks (or whatever a croissant costs on Kaui’i) is a very cheap price to pay for a valuable lesson about not just the chickens on Kaua’i, but the very fact that the Rules of Life from wherever your point of origin was have changed. I’ve camped on this island many time over the years and if you are not mindful of the dangers and keep the fact you are not in Kansas any more foremost in your mind, it’s easy to get into trouble. It’s a stunningly beautiful part of the planet with many hidden dangers. Slip and fall on a muddy trail, for example, can be deadly. Lack of awareness of the rip tides and undertows at the beaches can be equally deadly.

So stay alert. Be aware. Read every sign you see. Study what the locals do. Ask questions. And do a little research before traveling to Hawai’i.

For the owner of the Spot, I have this suggestion: The chicken warning sign is written in black marker on brown paper. It’s also placed high in the service window where patrons collect their order. If there is a line out the door, it typically bends away from the service window. Patrons don’t come to the service windows until their name is called. When they do, their natural line of sight is down, looking at the super scrumptious food. It is certain their attention will be drawn away from the warning sign about the chickens (#1 in the picture below) as they focus on gathering their food (#2 in the picture below.)

Fine to keep the sign in the service window, but lower it so there’s a better chance the patrons will see it. Also, put it on white paper. Even better, put a duplicate sign on the inside of the shop viewable from where customers are paying for their food. While they are standing in line waiting to place their order and reading the menu on the wall for the 12th time they are more likely to read the chicken warning sign. Maybe include a cartoon image of a rooster running off with a croissant.

This won’t “fix” the problems the unaware types bring with them onto the island, but I suspect it will cut down on the number of self-entitled noob’s demanding compensation for their lack of awareness. I’d like for The Spot to do everything they can to succeed, which means controlling costs and satisfying customers. I’d also like for the noob’s to gain some self-awareness and take that back home with them.

Win-win.

(I dropped a note to the owners of The Spot with these suggestions. They replied that they liked them and plan to implement these simple changes. If you’re in the area, send me a note, maybe with a picture, as to whether or not the sign has changed. If so, ask if the the changes made any difference! Always good to know the results of any experiment.)

Frameworks vs Rules

Getting the job done is no excuse for not following the rules. Corollary: Following the rules will not get the job done,” said Somebody I Don’t Know.

When I was developing software under the draconian rules of CMMI there was the very clear message from the handlers (as we called them) to follow the rules or there will be consequences. So we did. Mostly. The problem was that amongst those of us in the trenches there wasn’t much of a feeling of actually getting work done. There was a lot of rework due to features being designed without our input. The design team would send us a design, we’d make noise that the design had problems but we’d have to build it anyway, we’d build the unworkable thing, demonstrate a flawed product to the design team, they’d redesign (without our input), re-document, and send us a new design.

And so we lurched forward. We followed the rules and weren’t getting the job done from the customer’s perspective. I’m sure the CMMI gods were happy, though.

This was before “Agile” was a thing. There were plenty of rapid application development ideas in the industry and in loose fashion we ended up implementing what we thought we could get away with. And that worked.

Our impromptu “water cooler” conversations in the mornings where we mostly complained but frequently suggested solutions for each other’s techno-pain would be easily recognized by any scrum master as the daily stand-up or daily scrum. The way we cut up (literally) copies of the official documentation and re-arranged the work to better match how we thought the work needed to be done looked a lot like a sprint backlog.

We were getting the job done, but not following the rules. As far as I know, none of us ever suffered adverse consequences. It’s hard to argue with success no matter the path taken to get there.

Imposing elaborate sets of rules to a fundamentally creative process will pretty much guarantee a slow boat to success. In the late 80’s and early 90’s that seemed to work well enough. But those days are long gone. It’s why the framework approach to many of the Agile methodologies are more successful in software and similarly creativity dependent projects. Frameworks leave room to adjust, adapt, experiment, and act.

And…

Rules are important. Frameworks aren’t devoid of rules. Far from it. Tossing out bits and pieces of a framework shouldn’t be done just to get the job done. The rules that are part of a framework should be considered a minimal set essential to success. None of them should be discarded without careful deliberation. Unlike the rules to something like CMMI that are meant to control as many aspects of the project as possible and squeeze out any trace of uncertainty and risk, the rules in an Agile framework are meant to serve as important guides. Operating outside a framework for extended periods is likely to put a project at significant risk.

Well-established and proven frameworks, such as scrum, have extracted the essential rules from previous methodologies and experiences and organized them in useful ways. They don’t reject all the previous rules in a quest to re-invent the wheel. They build on what has been learned to improve the wheel. This is reflected in the words of the Stoic philosopher Seneca:

Won’t you be walking in your predecessors’ footsteps? I surely will use the older path, but if I find a shorter and smoother way, I’ll blaze a trail there. The ones who pioneered these paths aren’t our masters, but our guides. Truth stands open to everyone, it hasn’t been monopolized.Seneca, Moral Letters, 33.11

The Stoics recognize that our predecessors weren’t entirely wrong. But they are very likely incomplete. It is incumbent on us to improve upon and extend their work.

This illuminates the importance and value of a good scrum master. Like a good cowboy or cowgirl, part of their job is to ride the fences, looking for breaches to the framework. If found, either repair the fence with coaching or decide if the fence line needs to move to accommodate a need dictated by circumstances and conditions.

Image credit: Wikipedia

How to Frame Team Development Challenges

When working with teams or organizations new to Agile and scrum, it’s common for scrum masters to face varying degrees of resistance to the new methods and processes. The resistance can take many forms ranging from passive-aggressive behaviors to overt aggression and even sabotage.

There are two things to consider when looking for ways to resolve this type of resistance.

  1. The specific issues are typically not Agile problems in the sense they won’t be solved by any specific Agile techniques, methods, or frameworks. Rather, they are people problems; issues with how people’s behavior is driven by their values and beliefs. We have to resolve the people problems in concert with implementing Agile or Agile will never be successfully implemented. We also have to be sure not to confuse the two.
  2. We need to look at these challenges as opportunities.

It’s the second point I want to focus on in this post.

To simply paint the often unpleasant experiences we have with coaching our teams in the ways of Agile and scrum as “opportunities” isn’t much of a solution. It’s weak tea and about as useful as “Let’s all just think positive thoughts and eventually it’ll get better.” Nor do I suggest we sugar coat the unpleasantness by sprinkling “It’s an opportunity!” language on our conversations. Losing your job or breaking your leg may be one of those “wonderful opportunities” born from adversity, but only after you’ve found that next better job or your leg has healed. Hustling for new work or sitting idle while in pain and healing is decidedly unpleasant.

I had something else in mind for thinking about the challenges we face as “opportunities.” It’s in the midst of the unpleasant phase where the opportunities are found that lead to success. Seth Godin speaks to this in his book “The Dip.”

The Dip is the long slog between starting and mastery. The Dip is the combination of bureaucracy and busywork you must deal with in order to get certified in scuba diving. The Dip is the difference between the easy “beginner” technique and the more useful “expert” approach in skiing or fashion design. The Dip is the long stretch between beginner’s luck and real accomplishment.

It’s the classic “things will get worse before they get better.” But as Zig Ziglar put it, “Anything worth doing is worth doing poorly–until you can learn to do it well.”

It’s important to recognize and acknowledge when you’re in The Dip. Not just as an individual scrum master on a particular team, but perhaps the entire organization as well. Solving the issues you’re encountering today is exactly what you need to do in order to be successful in the long term. The Dip is inevitable and unavoidable. Part of the scrum master’s purpose is to raise the awareness of this fact so that the underlying issues that need to be resolved can be amplified.

This is what can make serving in the scrum master role particularly unpleasant at times. It’s when you earn your pay. In general, people don’t like to look at themselves in the Agile mirror that scrum masters are charged with holding up in front of them.

The Dip is another way to describe Shalloway’s Corollary applied to teams and organizations. Unlike losing a job or breaking a leg, what we’re dealing with is actually something we most definitely should expect. The system was always going to push back. Now we’re discovering exactly how that’s going to happen. The system is showing us what needs to change in order to become a more Agile organization. No more guess work. It’s a gift. Knowing this should be cause for optimism and viewing the tasks ahead as an opportunity. The way is known. There is less ambiguity. Doesn’t mean the path ahead is easy, just better known. That alone is incredibly useful.

A final thought. “The System” that’s been in place at any organization is what it is. For better or worse, it’s been working, perhaps for decades. Anything that challenges the status quo is going to receive push back. It just happens that Agile is the current challenger. As scrum masters, we have to continually evaluate our own “system” in a way that prevents it from becoming the next version of the problem.

  • Is a particular tool, process, or method fit for purpose?
  • What problem are we trying to solve?
  • Are there aspects of the “old system” that actually make sense to keep in place?
  • Are the frustrations we’re experiencing due to the “old system” pushing back or are they the result of our own ossification around out dated or misapplied beliefs?

The Pull of Well-Crafted Product Visions and Release Goals

There was even a trace of mild exhilaration in their attitude. At least, they had a clear-cut task ahead of them. The nine months of indecision, of speculation about what might happen, of aimless drifting with the pack were over. Now they simply had to get themselves out, however appallingly difficult that might be. [1]

In the early 20th Century, Sir Ernest Shackleton led an expedition attempting to cross the South Pole on foot. He was unsuccessful in that attempt. What he succeeded at, however, was something far more impressive. After nearly two years of battling conditions south of the Antarctic Circle, Shackleton saw to it that all 27 men of his crew made it safely home. As Alfred Lansing notes, “Though they had failed dismally even to come close to the expedition’s original objective, they knew now that somehow they had done much, much more than ever they set out to do.”

There is much I could write about the lessons from Shackleton, his crew, and the Endurance that apply to our own individual endeavors – personal and professional. For the moment, I wish to reflect on the sheer clarity of the goal 28 men had in 1915-1916: To survive, by any means and nothing short of complete dedicated effort.

To be sure, their goal was self-serving – no one can judge them for that – and no product team is ever likely to be placed in a situation of delivering in the face of such high stakes. Indeed, the lessons from Endurance are striking in their contrast to just how feeble the drama is that is often brought into product delivery schedules. We call them “death marches,” but we know not of what we speak.

One of the things we can learn from Endurance is the power of a clearly defined objective. Do or die. That’s pretty damn clear. Time and time again, Shackleton’s crew were faced with completing seemingly impossible tasks under the harshest of conditions with the barest of resources and vanishingly small chances for success.

What kept them going? Certainly, the will and desire to live. There were many other factors, too. What interests me in this post is reflected in the opening quote. The emergence of a well-defined task that cleared away the fog of speculation, indecision, and uncertainty. Episodes like this are described multiple times in Lansing’s book.

Why this is important to something like a product vision is that it clearly illustrates a phenomenon I learned about recently called “The Goal Gradient Hypothesis,” which basically says our efforts increase as we get closer to our goals. But here’s the rub. We have to know and understand what the goal is. “Do or die” is clear and leaves little room for misunderstanding. “Let’s go build a killer app,” not so much.

From the research:

We found that members of a café RP accelerated their coffee purchases as they progressed toward earning a free coffee. The goal-gradient effect also generalized to a very different incentive system, in which shorter goal distance led members to visit a song-rating Web site more frequently, rate more songs during each visit, and persist longer in the rating effort. Importantly, in both incentive systems, we observed the phenomenon of postreward resetting, whereby customers who accelerated toward their first reward exhibited a slowdown in their efforts when they began work (and subsequently accelerated) toward their second reward. [2]

Far away goals, like a product vision, are much less motivating than near-term goals, such as sprint goals. And yet it is the product vision that can, if well-crafted and well-communicated, pull a team forward during a postreward resetting period.

But perhaps the most important lesson from the research – as far as product development is concerned – is that incentives matter.  How an organization structures these is important. Since most people fail The Marshmallow Test, rewarding success on smaller goals that lead to a larger goal is likely to help teams stay focused and dedicated in the long run. Rather than one large post-product release celebration, smaller rewards after each successful sprint are more likely to keep teams engaged and productive.

References

[1] Lansing, A. (1957) Endurance: Shackleton’s Incredible Voyage, pg. 80

[2] Kivetz, R., Urminsky, O., Zheng, Y (2006) The Goal-Gradient Hypothesis Resurrected: Purchase Acceleration, Illusionary Goal Progress, and Customer Retention, Journal of Marketing Research, 39 Vol. XLIII (February 2006), 39–58