Archive for the ‘Scrum’ tag
Short Answers #2: What to Focus on in 2009
It’s officially a series now. In this Short Answers video, I answer the question, “If my Scrum team could work on one thing in 2009, what should it be?”
New Benjamin Zander Video - “How Fascinating!”
There’s a new Benjamin Zander video over at the Pop!Tech conference website. There’s some overlap with the video from TED I posted back in June—most of the content in each video expands on the ideas in The Art of Possibility. Nonetheless, this video is well worth watching even if you’ve seen the few other videos of him on the internet.
In this video, Zander works with a 15-year-old cellist—who, as far as the boy knows, has come simply to perform for the crowd—and over the course of 20 minutes turns a technically sound performance into music, music that touches everyone there.
One moment that connects with me as an agile coach is when he teaches the young cellist how to respond to mistakes in a performance.
Short Answers #1: When Stories Are Larger Than Planned
I’m experimenting with video for what is likely become a new series here. In these “Short Answers” posts, I’ll answer an agile question in about a minute. Use the comments to suggest questions you’d like to see in future Short Answers.
In this post, I answer the question, “What should I do when I discover in the middle of a sprint that a story is larger than we planned?” Several people have asked me this, and the answer is not, “Suck it up and work 80 hours to get everything done.”
Are the Product Owner and ScrumMaster’s Interests Opposed?
The Chief Engineer role in the Toyota Product Development System combines parts of the Product Owner, ScrumMaster, and senior technical team member roles from Scrum. In addition to leading the technical design of a new product and facilitating the work of the other engineers, the CE must deeply understand and care about what the customer values—he has ultimate responsibility for delivering value to the customer and for the resulting commercial success or failure of the product.
CEs have gone to amazing lengths to gain that deep understanding of the customer’s needs.
Motivated Individuals
As agile approaches the mainstream, it’s easy to lose sight of some of the core principles, especially this one:
Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.
If agile is to apply broadly, we can’t reserve it just for those projects that start with motivated individuals. We need to learn how to cultivate them.
A Common, but Bad, Idea
Please don’t do this:
Free Agile Product Management Seminar - Nov 11, Denver
I’m hosting a free seminar on Tuesday, November 11 from 1:00-2:30 PM in the Denver Tech Center area. Please join me there and spread the word to others who might be interested.
Here’s a brief description:
The Most Useful Release Burn-up I’ve Seen Yet
I often advise teams against using a release burn-up (or burn-down) chart because I’ve seen too many managers try to use them as a stick to beat the team with their original pre-project release estimate. Since velocity changes from iteration to iteration, the size of the release needs to change, as well. Jim Shore has a great post describing how to do a release burn-up that takes into account changing velocity and the cone of uncertainty, giving a more and more specific estimated release size to burn up to after each iteration. Check it out.
Making Velocity Granular Enough
Predicting Mileage
Suppose I were considering leasing a new car. (I’m not, but it makes a good story.) I’d want to be sure that my mileage would fit within however many miles are included in the lease. To figure that out, I’d look at how many miles I’ve driven the past few years. In 2006, I drove 12,000 miles. I drove 10,000 in 2007 and I’m on track for 6,000 this year.
I could use Yesterday’s Weather and predict that I’m going to drive 6,000 miles per year in the future. Or, I could look at the decreasing trend and predict that I’m going to drive somewhat less in the years to come. Either of those options would likely cost me money at the end of my lease because they leave out an important detail: I’ve been a traveling consultant. For me, a year is not a year when it comes to driving. I only drive when I’m working at a client in Denver. Over the last three years, my time at local clients has varied:
In 2008, I’ve traveled far more than in the previous years. In 2009, I hope to find more local work and travel less. (Obligatory plug: If you’re in a Denver-area software organization that could use some help becoming happier and more productive, contact me.) So if I predicted 6,000 miles or less and signed a lease on those terms, I could well end up driving 12,000 or 15,000 and spending a lot of money on miles at the end of the lease.
Since I can’t use my miles in a past year to predict my miles in a future year, I need to get more granular—to a level where there’s more stability in my mileage—and extrapolate from there back up to the year. Dividing the total miles per year by the weeks at home shows that my weekly mileage when I was home was stable across the three year period.
It’s likely to remain that way going forward. (There’s only so far you can drive in Denver.) So if I can predict the number of weeks I’ll be in Denver in 2009, I can predict how many miles I’ll drive that year.
What Does This Have to Do With Scrum?
In Scrum, velocity is a measure of work per unit of time. I usually see work measured in story points, ideal time, elapsed time, or task count. Time tends to be measured in sprints, days, or hours. Most Scrum teams measure their velocity in story points per sprint. For the ideal Scrum team where all team members work exclusively on a single project this high-level measurement is a simple, fast way to predict how much work the team can do in future sprints.
For many teams, however, a sprint is not a sprint. Team members do work on other projects, maintain production systems, go on vacations and holidays, go to training; for a variety of reasons, the team doesn’t work the same amount of time in each sprint. Measuring velocity in work per sprint, then, doesn’t give us the predictability we need to make commitments.
(Note: As a coach, I try to get an organization to transition to fully dedicated team members, but that’s not always a quick change and I’d prefer not to defer predictability until then. Regularly missing commitments is discouraging.)
For these teams, we need to get more granular. So far, every team I’ve seen has been stable at the work per hour level, so I usually go there. Just as we can use points per sprint to predict a future sprint’s capacity…
…we can use points per hour…
.
At the end of a sprint, I look at how many points of work the team completed, and I ask them how many hours it took to complete that work. I want to know not just time spent on their tasks, but all the time they spent on the project. (By asking that, I now have an empirical way to handle overhead instead of just guessing at a buffer or reducing hours per day.) I ask how many hours they plan to spend on the project in the next sprint. From there, I can solve for the points they are likely to be able to complete in that sprint.
The least granular velocity measurement is usually the easiest to track and use, so when I have a team measuring velocity in points per hour (for example), I’m checking at regular intervals to see if the team has stabilized at points per day or points per sprint so that we can start using that less granular measurement instead.
The Power of Small Experiments
Change can be scary. Change at work is particularly threatening. After all, most of us spend more time working that doing any other single thing. Even a potentially good change, one that promises a better future, is risky. The better future might not pan out. It might be worse than the status quo. It’s that risk that makes talking someone into accepting a change so ineffective.
To gain acceptance of a proposed change, stop trying to persuade on the merits of the change. Very few changes have to be permanent, so you don’t need to convince people to accept the change forever. Instead, look at ways you can remove the risk, ways to make the change undo-able. Frame your change as an experiment that can be rolled back if it doesn’t work. Set a date to evaluate the results and make a decision whether to continue with the change or roll back. And then stick to that plan, even if the change is going overwhelmingly well. It’ll remind people that you’re trustworthy and that when you propose an experiment you really mean it—you’re not just being sneaky.
When you consider how long to make an experiment, remember that it can take 21 or more repetitions for a new practice to become a habit. Think about the learning curve associated with your change. Try to make the experiment longer than that initial learning, habit-building period.
Scrum’s sprints and retrospectives give you a nice built-in cycle for experiments. It’s easy to propose trying something for 1, 2, or 3 sprints, to be reevaluated in the corresponding retrospective. Want to adopt TDD or pair programming? Want to move QA people into your team? It doesn’t have to be permanent. Just try it for a few sprints. Maybe measure cycle time or defects while you do it. If it doesn’t work for, you can always go back to what you’re doing today. It’s just an experiment.
