Banishing Blame with Agile Values

I recently got pointed to an article about some research done by researchers at Stanford and USC about the dynamics of blaming in organizations. People Like to Play the Blame Game says that it's quite easy to create a culture of blame.

Merely observing someone publicly blame an individual in an organization for a problem - even when the target is innocent - greatly increases the odds that the practice of blaming others will spread ...

The ways that you avoid a blame culture seem to fit well into an agile culture that values retrospectives, and continuous improvement. The article advises leading by example:

A manager can keep a lid on the behavior by rewarding employees who learn from their mistakes and by making a point to publicly acknowledge his or her own mistakes, Fast said. Managers may also want to assign blame, when necessary, in private and offer praise in public to create a positive attitude in the workplace.

This advice isn't just for managers; everyone on the team needs to acknowledge and learn from their own mistakes. And when you have a problem and find yourself trying to figure out who's fault it is, take the advice from the XP books such as Extreme Programming Installed
and decide that It's Chet's Fault, which is to say, stop trying to place blame and think about what the problem is.

In an agile organization you need to be careful to balance the need to figure out the root causes for why a project didn't go as well as it could have , and the tendency to place blame. Blame undermines collaboration, making it more difficult to improve. Accountability and responsibility help you figure out how to do better.  Create an environment where it is OK to accept responsibility. One way to  do that is to acknowledge when you made a mistake yourself. Another is to start having retrospectives periodically, and not just when things go bad.

Another quote from the article led me to think about another benefit of agile.

Another experiment found that self-affirmation inoculated participants from blame. The tendency for blame to spread was completely eliminated in a group of participants who had the opportunity to affirm their self-worth.

Agile projects, with a common vision, self-organizing teams, and good infrastructure to help you make forward progress and detect problems quickly are a perfect environment to feel like you are contributing.

While much of what's in the article sounds intuitive, it's good to know that there is data to support that blame is both contagious, and simple to avoid.

Estimates and Priorities: Which Comes First

When developing a release plan, product owners often want to factor cost (or estimates) into where items go into the backlog. For example, you might hear "Do that soon, unless it's really hard." If this happens once in a while it's a useful way to have a conversation about a feature. If this approach is the norm and nothing gets prioritized until the team estimates it. I'd argue that the default order of operations is that features should get prioritized before anyone spends any effort on estimation. My reasons for this are both philosophical and practical.

The philosophical reason is that the Product Owner should be the one to prioritize work. By asking for the estimate first, the product owner is deferring their authority to the engineering team. This creates a risk that the team may not end up working effectively.

The practical reasons for prioritizing before estimating are:

• Estimation takes time, and if you don't start with a prioritized list to estimate with, you spend a lot of time estimating items that may never be worked on. (And yes, you may need to re-estimate items when  they hit the top of the list, as estimates may change based on experience, staffing and architecture.)
• If you estimate as work appears, you lose some of the benefits of fixed, time-boxed sprints, and you increase the overhead cost of planning. 
• By allowing the team to estimate first, and pushing an item off the list because it is too expensive, you are missing an opportunity for a conversation about how best to meet the business need.

Often the first version of a story may seem large because it includes more functionality than needed. If the the team knows that there is a critical feature to implement in a sprint, but that there isn't time to complete it, there may be a simpler, less costly, version of the feature that meets most of the business needs. If the product owner simply let's a large estimate defer the item, then the conversation will never happen and the business needs may not be met, which would be bad for everyone. Likewise if the expensive feature is lower on the list, then you need not have the conversation until later.

This balancing act between estimates and priorities underscores a key principle of agile planning: User Stories are an invitation to a conversation.  By prioritizing first, you can understand where to focus energy on analysis and design. You also keep the agile team focused on delivering business value by placing priority first, and having the engineering team and the product owners communicating actively.

Review of Adapting Configuration Management for Agile Teams: Balancing Sustainability and Speed

Adapting Configuration Management for Agile Teams: Balancing Sustainability and Speed is a book that bridges the gap between tradition SCM and Release Engineering and Agile teams. Mario asked me to be a reviewer of the draft manuscript and I knew that Mario had great experience in establishing SCM processes in larger organizations, and that he was also a strong advocate of Agile methods. I was pleased to discover a book that, while being able to help those from a traditional release management background adapt their processes to support agile, also addresses the needs of those transitioning to agile who can benefit from using appropriate SCM processes to help them.

This book will help you to understand how SCM can be an enabler for agile, and will also help you to understand how to fulfill the SCM definition of Identification, Control, Status Accounting, and Audit and Review while still being agile.

This is what I said about the book on my books page:

This book is a good guide to both CM and Agile principles, and it demonstrates how to use software configuration management to enable your team to be more agile. This book can guilde you to understanding how to manage releases in an agile environment, and how to apply basic CM concepts like build and branching successfully. While not a replacement for a book on your agile method, this book is a primer on agile for those with a traditional release management background, and and a primer on CM for those who understand agile. After reading it you will have enough background to be productive, and a good sense of what you need to learn more about. In addition, this book covers topics such as how to leverage cloud service providers for infrastructure, how to leverage SCM to make off-shore development less painful, and how to evolve your SCM process in an agile (incremental) fashion. With a good structure that allows you to navigate the book quickly, and a good use of metaphor to describe concepts, this book will help a release managers, project managers, developers and architects use the SCM process to get the most out of their agile teams.

If you are transitioning to agile and want to know how your release management team can help, rather than hinder you, give this book a look.

Sprint Boundaries and Working Weekends

A core principle of agile methods is sustainable pace. While the precise definition of this is debatable, the basic idea is that you want your work load to allow for a life outside of work, which in turn means not planning on overtime. The reality for many projects is that there will be times that the team needs to work outside of "normal" hours to meet a goal, and this is consistent with the idea of a sustainable pace if it happens occasionally, and the team decides that to meet a goal the added hours are needed.

Another core principle of agile methods is transparency. In order to improve, you need to be honest about acknowledging changes in plans, mistakes which cause more work, and misunderstandings that cause you to get things done significantly ahead of schedule.

A decision that teams make independently of the number of hours that they need to plan for is what the boundaries of a sprint should be, particularly with a 1 week sprint. This question is especially relevant if you think that weekend work will be needed. If you are doing 1 week sprints, there are basically 3 choices:

• Have sprints be Monday thru Friday, with a review first thing Monday.
• Have sprints be Friday thru Thursday.
• Have sprints be Tuesday thru Monday

The first option sound good, since you're not working on weekends -- unless you are. In which case one might argue that the weekend is really part of Friday. I don't like that idea because not only does it  because it ignores that the sprint boundaries mean something. If your team is meeting its 5-day goals only by working the weekend, then your are hiding that fact by considering the weekend as a "buffer." I'm not saying that one should never work weekends;  I'm suggesting that you should evaluate the work done in the context of the weekend work.

The second option is better; the weekend is part of the sprint boundary, and if the team agrees to work weekends you can measure that. Early in the sprint you may be more optimistic and not expect that to work, and early if you front load the riskier work, then the you might find it more useful to plan to do this work during the week when you can count on everyone being around (assuming that weekend work is done at people's own schedule).

The third option means that the weekend at the end, so you'll know if there is a need for extra work. Typically the work at the end of a sprint involves more defined tasks; you may be wrestling with getting something to work, but you probably had the design discussions already and you've tacked all of the tricky issues at the start. At this point going into a corner on the weekend to work is less likely to adversely affect someone else's work.

While  each team should define what "sustainable pace" means, and how best to meet their goals, to get the full value of an agile process, keep any days you expect to work inside the boundaries of the sprint. And when you do your release retrospective, be sure to discuss how well the  team is managing its workload.

Estimation: Precision and Accuracy (and Economics)

I was listening to a episode of the NPR show Planet Money on the accuracy of economic forecasts and how economic forecasts often have precision, but are often inaccurate. Consider this exchange between two of the show's hosts:

Alex Blumberg: On average, the leading forecasters, like Prakken's Macroeconomic Advisors, have around a one percentage point margin of error, which might sound pretty good. But let's say you forecast a two percent growth rate for the year. That means you're saying the actual rate will be somewhere between one percent and three percent.

Adam Davisdon: Now those are two totally different economies. One percent, that doesn't even keep up with population growth. That's a bad year. Unemployment will go up. It'll feel bad in the U.S. Three percent is the opposite, a pretty good year.

In one of the interviews, Simon Johnson, (Economist, MIT, Peterson Institute for International Economics) said this about economic estimates:

I would call it a necessary evil. There's so much imprecision. There's so much, you know, lagging in terms of our updating, that in some sense, we'd be better off without forecasts. We'd better off, you know, making up our minds afresh every day. But the problem is the businesses, the institutions, all involve thinking about the future and planning for the future. And you can't do that without taking a view of the future.

Which sounds quite analogous to estimates on software projects. One of the reasons that Planning Poker estimation uses a non-linear scale (for example, a Fibonacci sequence)) is that, in general, as tasks get larger, you are less accurate. While it might be meaningful to talk about a 1 hour task as opposed to a 2 hour task,  it's less likely to be useful to estimate 6 hours as opposed to 5 hours for a task. (A Planning Poker desk might have 1,2,3,5,8, 13, etc, hours as possible values.)

Planning Poker is intuitive, and often matches experience, yet many people insist on estimating a task that takes more than 3 hours as 4 rather than 5. This is probably because everyone forgets that estimates are just that: "estimates." Estimation gets better as a team works together, but the estimates are only one part of the planning process. If the goal of the team is to make a commitment to deliver functionality, then the non-linear jump in estimates is a measure of risk. The best way to reduce risk is to work in smaller pieces. When faced with a task that is bigger than an 8, and 13 seems too big, see if you can decompose the task in to smaller tasks, thus improving your ability to estimate accurately.

Estimation is difficult, not just for software teams, but we need something to help us plan, so just be mindful to give estimates the appropriate precision. And reestimate work remaining as you go.