Skip to main content

Posts

Showing posts from January, 2010

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 need…

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 …

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…

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 …

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 …