#NoEstimates: The Division of Scrum

Have you encountered the #noestimates hashtag yet? If so, you likely have strong feelings on the topic, whichever way you lean--it’s just about the most divisive topic you can find in the Scrum world these days.

Devotees on either side will be happy to tell you why they’re right and the other side is wrong: State your mild opinion on the topic in the wrong crowd and you could find yourself feeling like a Democrat at a Republican convention, or vice versa.

At its core, the argument is over the benefit of spending a team’s time on estimating stories. Those who support estimates will tell you it’s a valuable tool that provides businesses with fact-based projections on when a project might be complete. Opponents will say that the benefit of estimating--namely, being able to predict when a project might complete its work--is not worth the time devoted to creating that projection and that a team is better off reclaiming that time to develop software.

It's important to recognize that, when it comes to the issue of estimates, the Scrum framework is Switzerland. It takes no official position on estimating and it’s considered an optional practice, though one widely used by Scrum teams. If you take a Certified Scrum Master course, you are likely to find a module devoted to the topic and time spent practicing Planning Poker. The entire concept of User Stories comes from the XP framework, not Scrum.

If you trace the history of the #noestimates hashtag, you will undoubtedly come across the name of Mr. Woody Zuill. Woody came through my town last year and spoke at our local Scrum Alliance sponsored meetup group to discuss the topic.

Having considered myself to be smack dab in the Mike Cohn camp on estimating at the time, I was skeptical of this whole #noestimates concept. My experience when researching it involved mostly argumentative individuals intent on proving those of us who were still estimating to be relics of a time gone by. My expectation then was that Woody would take a similar stance and spend his time trashing the estimating crowd.

As it turned out, I could not have been more wrong.

Woody Zuill is one of the kindest, most humble and intelligent speakers I’ve ever heard. His demeanor will instantly disarm even the harshest critic; the impression he gives is of someone who has vast experience in software development and has experimented with numerous ways in which to optimize the agile process with his teams. Plus, all his illustrations are drawn by his daughter. How can you not respect that?

After hearing Woody out on the topic, I realized that his stance on the issue was incredibly different that I’d previously assumed. Woody teaches that, to him, #noestimates means using estimates only when there is a clear value to doing so. He suggests that many are spending far too much time estimating because that is what they have always done or have been taught; they haven’t stopped to ask if they are really getting a benefit from the time they spend estimating with their teams.

I found myself in complete agreement with him. In fact, I would go even further and say that any practice we find ourselves repeating with our teams should be examined from time to time to make sure we are getting the intended value out of them. How often do we have teams blindly recite the three questions for the Daily Scrum without making sure they understand why we are asking those questions, and what the point of the Daily Scrum is in the first place?

Since being exposed to #noestimates, I have found that when I am coaching a team I now make a regular practice of stating at the outset of every meeting our reason for attending that meeting and what we hope to get out of it. If my teams can better self-organize at their Daily Scrums by abandoning the standard three questions in favor of some other communication to organize their daily work, more power to them! After all, that is the point.

I would invite you then to attempt to see Scrum’s practices with new eyes. We all know what to do in our ceremonies but do we all know why we do them? Could we accomplish our goals for these meetings more fully by experimenting with alternatives? If our goal is to empower our teams to become the highest performing incarnation of themselves as possible, why wouldn’t we seek out new and unique ways to encourage this?

While I might never call myself a #noestimates supporter, I do wholeheartedly endorse the spirit behind the movement as Woody presented it. Examine why we do what we do and ask yourself if there might be a better way.

What do you think about the #noestimates movement? Do you find value in estimating with your teams? What practices have you taken a fresh look at in an attempt to enhance the benefit to your teams? Let me know in the comments section below.

Diagnosing Dysfunction Using The Product Backlog

My first car was a ’79 Oldsmobile Cutlass Supreme, and I think I was the third kid in my family to drive it. My friends and I nicknamed it the “old-mobile,” and like any car that could be considered “numerically challenged,” mine had its issues. Of particular concern was an ongoing radiator leak that could cause the car to overheat. 

I quickly learned to pay close attention to the heat indicator light on the dashboard to help me gauge the car’s daily usefulness. Growing up in Texas, you can imagine how this could be a severe problem during the summer months! However, as long as I kept a close eye on that heat indicator gauge, I could determine if I was ok to continue my journey or if I needed to pull over and add extra antifreeze to the tank. If I ignored that gauge, I risked breaking down and derailing whatever plans I had for the day.

Just like that old car, in Scrum we have our own set of indicator lights and gauges. Our ceremonies and artifacts are built in part to help us recognize potential issues before they become bigger problems. If we pay attention to them, we can successfully navigate our course. If we ignore them, we risk breaking down.

In a recent conversation I had with Kert Peterson, he mentioned that when he consults with a new client the first thing he does is ask to see their product backlog and their definition of done. I’ve since come to realize that these two artifacts can be key to diagnosing the health level of a team.

The definition of done (or lack thereof) can tell you quite a bit about what a team considers important in producing a potentially shippable product increment. The product backlog, however, is revealing in a way I had not previously considered and has become one of the main tools I use in coaching a team.

Looking at the product backlog is like looking at tree rings or a core sample: it provides you with an insight into the partnership between the development team and the product owner. A healthy Scrum team exists in a collaborative environment, so the product backlog should reflect this delicate balance.

If there are problems with the partnership between business and developers, you’ll likely notice it in the makeup of the product backlog. Like shorter tree rings in times of drought, a product backlog reveals the work that was done to produce it and how the various personalities of the team members work together.

In some cases, you can see that the product owner has isolated himself or herself from the development team, resulting in a very business-friendly product backlog: stories are all customer-focused, and little regard is given for the technical architecture of the project. Input from the team has not been considered or worse, not solicited.

The partnership in this case is one-sided and the team is simply taking orders. They deliver exactly what’s been requested but are never given the chance to address technical debt or to contribute their own ideas.

The opposite can also be true for a product backlog that is too developer-centric. In this case, you will see a product backlog full of technical stories with more acronyms than a government agency. Stories will likely not make any sense to the product owner, who is trusting that the technical experts know what they are doing even though he or she has very little visibility into what they are working on.

There are likely strong personalities on the development team that have crossed the line from deciding how to deliver the product increment to defining what the product increment contains. 

Of course, there are a thousand permutations between the two as well, each with their own story to tell about how the Scrum team is collaborating and discovering the requirements as they make the journey toward producing the product.

If you know what you are looking for, though, you can look through the tree rings of your product backlog and find the signs of issues that are preventing your team from realizing its full potential. The product backlog then becomes an incredible diagnostic tool for coaches and can reveal where their time is most needed on the team.

While that “old-mobile” has likely found its way into a scrap heap by now, the lessons I learned from it are just as valid today as they were in high school. When you have a valid indicator that gives you an early warning that a problem is developing, it’s wise to pay attention to it and take corrective action. It’s far better to spend the extra time addressing your issues now before they grow and derail your plans down the road. 

What is your experience? Have you ever looked at the product backlog as a diagnostic tool that reveals the health of your teams? What else do you feel the product backlog reveals? Feel free to share your thoughts in the comments section below.

Culture Wars: The Battle for Hearts and Minds

Recently, VersionOne released their 11th annual State of Agile report detailing the current state of agile across multiple organizations spanning the globe. 

In the report, VersionOne listed the top challenges respondents reported having experienced in adopting and scaling agile. Their number one response (with 63 percent of respondents citing it as an issue) was that company philosophy or culture was at odds with core agile values.

This issue jumped out to me as getting to the heart of the problem that many who adopt agile experience: the great culture war, or the battle for the hearts and minds of your organization. When adopting agile, we must recognize that extensive knowledge of the framework is not enough and that changing the culture of a company is the more necessary and arduous task.

Why are so many seeing this as a challenge to their agile adoptions? What is it about company philosophies or cultures that conflict with core agile values? More importantly, what could we do better as an agile community to address this issue and provide solutions to this widespread concern? 

Agile values are best represented by the four main statements put forward in the Agile Manifesto. These statements are not buried deep within the training material and should be well known by any company looking to implement an agile transformation.

In fact, I would imagine that if there is one thing executives or other sponsors for an agile transformation certainly know about agile before they pull the trigger on an adoption, it is the Agile Manifesto. Why, then, do we find our companies at odds with the most fundamental concepts associated with agile?

What I have heard multiple times from various organizations is that there exists a very real disconnect within their companies between some layer of the management structure and the teams who are implementing agile.

In other words, parts of the organization are implementing agile while other parts continue to use waterfall methodologies. The team level will practice iterative, incremental development while reporting up to layers of management that still operate on what David Hawks calls “a requirements delivery model rather than a requirements discovery one.” 

What this creates is a mushy translation layer within organizations where some poor souls are asked to translate agile concepts into traditional waterfall-speak. That group is given the impossible task of translating iterations and story points into a Gantt chart with hard deadlines for delivery. They are asked to take overly complicated requirements documents and translate them into user stories. 

These are insurmountable challenges which will only produce frustration in both those trying to translate and those expecting the translation. There is no Rosetta Stone to accomplish this translation because the concepts simply don’t translate. Any translation that a company might settle on must compromise on one side or the other, and it is usually the agile side that takes the hit.

If an organization wants to change its culture and realize the full benefits of an agile transformation, a more holistic approach is needed. Both management and team layers need to understand not only the “how” but the “why” behind each change that is being made.  

Two suggestions for organizations that are seeking a more holistic approach:

Consider arranging training not only for your teams but also for your directors, vice president and C-level leaders as well. Within the past few years, The Scrum Alliance has created the Certified Agile Leader (CAL) certification course that many of those in management and leadership positions would be wise to consider investing in. This course will help organizational leaders understand what to expect and learn how they can encourage and fan the flames of their organization’s agile transformation. Consider “seeding” your transformation by contracting outside coaching to help teach not just one-time concepts but overall culture on a day-to-day basis.

Now, you might be thinking to yourself, “Of course you would say that! You’re an agile coach and consultant!” And you’d be partially correct. One of the main reasons I decided to do what I do is because I wanted to focus on an area where I felt I could make the greatest impact. However, there are many great coaches and consultants out there and most of them would tell you the same things. 

Culture isn’t something you can transfer in a one- or two-day course. Culture takes time and is learned through osmosis and by example. When a team member suggests that a sprint be extended so that the team can finish all the work, a coach is needed to explain not only that Scrum is timeboxed by rule but also that we do this to establish a definitive point that we can review the work to see what adjustments we need to make to move forward.

This leads a team to think of the steps of the process as more of what they were intended to be – a framework. When that shift occurs, a team begins absorbing the cultural concept rather than simply parroting back answers from a book. That leap, in both organizational leaders and in teams, is what will transform the culture of an organization and it is the best way to combat any disconnect between a company’s culture and core agile values. 

Hearts and minds will always be more difficult to change than procedures and processes. However, in order to change the culture of an organization, that is exactly the target we should be attempting to hit. Our job as agile leaders is to draw this clear distinction and point our teams in the right direction. Only then can we begin to address the number one issue organizations face in their path towards a successful agile transformation.

What do you think is the hardest part about transitioning to agile? Are there any culture clashes you’ve observed in your own organization? Let me know in the comments section below.