please enable javascript

Deciding What Kind of Projects are Most Suited for Agile

January 15th, 2011

I was recently asked what kind of project is most suited for an agile approach and I’d like to address that here. In my view, the most appropriate projects for agile are ones with aggressive deadlines, a high degree of complexity, and a high degree of novelty (uniqueness) to them.

We want to use agile when we are doing something that is new, or at least new to the team building it. If it’s something the team has done before over and over then the team probably doesn’t need an agile approach. To my mind, this is where some of the manufacturing analogies come in. If we are building the same car day after day, we learn pretty quickly all the nuances of building that car. We don’t need an agile approach because the novelty of the situation is low.

Novelty alone does not mean we should use an agile process. I went to my favorite Chinese restaurant for lunch today. I ordered an entree “triple extra spicy and with jalapenos.” It was probably the first time they cooked this particular dish that way and so it was a novel or unique order. The cook prepared it wonderfully though and because I could see into the kitchen I’m sure they didn’t need a daily standup or even TDD to make my lunch. (I might have noticed a kanban back there, however. :) So, in addition to novelty, the project needs a certain amount of complexity.

One final element I believe is required in making a project appropriate for agile is urgency. The timeboxes and iterations of an agile approach are devised to keep the intensity and focus going on a project. If there’s no urgency to the project, those are unneeded.

So let’s see how these three factors–urgency, complexity, and novelty–mix on various projects, starting of course with software projects. There couldn’t be a better fit. Software projects are notoriously complex. Each software project is largely a new endeavor. And in today’s world, there is almost always a sense of urgency.

But let’s look at one other situation where we commonly here about Scrum (in particular) being applied: getting married. At least a couple of times a year I hear about a couple who planned their wedding using Scrum. There is always a wedding backlog–buy cake, pick photographer, send invitations, pick dress, etc. How does planning a wedding do against the three factors I’m proposing. Sense of urgency? Check. There’s always a deadline and it’s usually pretty fixed. Complexity? Well, it’s not like a software project but it does have its own complexities often enhanced by non-functional requirements such as a fixed budget, who sits next to whom, the type of food to be served, the need to let Cousin Ira’s band perform at the reception, etc. Novelty? Yep. Most people don’t get married enough times with large celebrations that planning the event becomes second hand.

So, agile is most appropriate on any urgent project with significant complexity and novelty–and that includes software development and weddings. It does raise the question though of whether a couple’s first kiss at the end of the ceremony is a product backlog item or part of the done criteria for the overall product.

Announcing Q1 Agile Software Development Training in the U.S. & Europe

January 6th, 2011

Mike Cohn, author and scrum agile expert, will bring his Agile software development training classes, Certified ScrumMaster, Succeeding with Agile, Certified Scrum Product Owner, Agile User Stories and Agile Estimating and Planning training to parts of the United States and Europe.

Layfayette, CO November 29, 2010 — ScrumMaster and agile expert Mike Cohn has announced his new agile and scrum training class schedule in Europe and the US for January through March 2011.

As in years past, Mountain Goat Software is once again bringing Scrum expert Mike Cohn’s agile software development training knowledge and expertise to Norway, and England as well as the Silicon Valley, Irvine, San Diego and Dallas in the United States in 2011.

Mike Cohn personally teaches agile project management classes for both new and current Agile teams and team members and class participants benefit by learning new ways of working and practical skills that can be immediately applied. All classes include an appropriate mix of lecture, small-group discussion and hands-on exercises. As a Registered Education Provider through the PMI, attendees earn Category 3 PDUs.

According to Gabrielle Benefield, Former Director of Agile Development, Yahoo!, “Mike’s classes at Yahoo! have been incredibly useful. I recommend him to anyone who is serious about implementing Agile in their organization. ”

A veteran of agile projects since 1995, Mike Cohn teaches how Agile software development training teaches teams how to emphasize teamwork, produce frequent deliveries of working software, develop close customer collaboration, and achieve the ability to respond quickly to change. For additional information and to register, visit the Mountain Goat Software website and learn more about the certified scrum and agile training available.

About Mountain Goat Software and Mike Cohn

Mountain Goat Software is an Agile Methodology Training and Project Management Consulting Company founded in 1993. Owner, lead trainer and author of three very popular books on agile, Mike Cohn has also written numerous articles for magazines, journals, and websites. He has a blog on succeeding with Agile and is a frequent participant in agile and scrum discussion groups.

Contact:
Mike Cohn, CEO and Lead Trainer
Mountain Goat Software
888-61-AGILE
mike@mountaingoatsoftware.com

http://www.MountainGoatSoftware.com

###
Layfayette, CO November 29, 2010 — ScrumMaster and agile expert Mike Cohn has announced his new agile and scrum training class schedule in Europe and the US for January through March 2011.

As in years past, Mountain Goat Software is once again bringing Scrum expert Mike Cohn’s agile software development training knowledge and expertise to Norway, and England as well as the Silicon Valley, Irvine, San Diego and Dallas in the United States in 2011.

Mike Cohn personally teaches classes for both new and current Agile teams and team members and class participants benefit by learning new ways of working and practical skills that can be immediately applied. All classes include an appropriate mix of lecture, small-group discussion and hands-on exercises. As a Registered Education Provider through the PMI, attendees earn Category 3 PDUs.

According to Gabrielle Benefield, Former Director of Agile Development, Yahoo!, “Mike’s classes at Yahoo! have been incredibly useful. I recommend him to anyone who is serious about implementing Agile in their organization. ”

A veteran of agile projects since 1995, Mike Cohn teaches how Agile software development training teaches teams how to emphasize teamwork, produce frequent deliveries of working software, develop close customer collaboration, and achieve the ability to respond quickly to change. For additional information and to register, visit the Mountain Goat Software website and learn more about certified scrum and agile training available.

About Mountain Goat Software and Mike Cohn

Mountain Goat Software is an Agile methodology training and project management consulting company founded in 1995. Owner, lead trainer and author of three well read books on Agile, Mike Cohn has also written numerous articles for magazines, journals, and websites. He has a popular blog on succeeding with Agile and is a frequent participant in agile and scrum discussion groups.

Contact:

Mike Cohn, CEO and Lead Trainer
Mountain Goat Software
888-61-AGILE
Mike@MountainGoatSoftware.com
http://www.MountainGoatSoftware.com

###

5 Free Agile & Scrum Tools for Project Planning and Prioritizing

January 6th, 2011

Mountain Goat Software and Mike Cohn, author and Agile Scrum expert, have announced the release of four free tools used in agile and scrum projects for planning and prioritizing.

Layfayette, CO November 6, 2010 — Mountain Goat Software, an agile training and scrum certification company, has released five free agile and scrum tools ScrumMasters and Agile teams can use when planning and prioritizing software development projects.

The tools, a velocity range calculator, relative weighting worksheet, theme scoring tool, theme screening tool and project success sliders, have all been developed to help Agile and Scrum teams with their software development projects. From velocity values to comparing and prioritizing, these free online tools will help Agile and Scrum teams stay on time and on top of projects.

Mike Cohn, creator of these Agile tools, says that “software development plans created with a 90% confidence interval, are more likely to be accurate than plans created with a point estimate of velocity.” In other words, the better the plan, the better the outcome and these tools will help Scrum and Agile teams build better plans with confidence.

Mike Cohn teaches classes for both new and current agile teams and team members. As a Registered Education Provider through the PMI, attendees earn Category 3 PDUs. A veteran of agile projects since 1995, Mike Cohn teaches how Agile software development training teaches teams how to emphasize teamwork, produce frequent deliveries of working software, develop close customer collaboration, and achieve the ability to respond quickly to change.
For additional information visit the Mountain Goat Software website and learn more about certified scrum and agile training available.

About Mountain Goat Software and Mike Cohn

Mountain Goat Software is an agile methodology training and agile project management consulting company founded in 1995. Owner, lead trainer and author of three well read books on Agile, Mike Cohn has also written numerous articles for magazines, journals, and websites. He has a popular blog on succeeding with Agile and is a frequent participant in agile and scrum discussion groups.

Contact:

Mike Cohn, CEO and Lead Trainer
Mountain Goat Software
888-61-AGILE
mike@mountaingoatsoftware.com

http://www.MountainGoatSoftware.com

###

Announcing an upcoming PMI Webinar

December 11th, 2010

I’ve been invited by the PMI Agile Community of Practice to present a webinar. It will be held on February 15, 2011 at noon Eastern time and will last one hour. The topic is “The Seven Sins of Project Management.”

PMI

Here’s the session description:

Agile approaches to software development promise many advantages: shorter schedules, more productive teams, products that better meet customer expectations, higher quality, and more. In this talk, Mike will explain how agile teams achieve these goals by avoiding the seven deadly sins of project management. Covered will be sins such as gluttony, sloth, lust, opaqueness, and more. Giving in to one of these temptations can result in a failed or canceled project. Along the way you’ll be introduced to key aspects of agile development and hear stories of agile success and failure.

There’s no charge to participate but you do need to be a member of PMI’s Agile Community of Practice. But, hey, that’s a good thing to join anyway. (And I think it’s free, too.) You need to register in advance, which you can do on the PMI website.

Scrum Alliance Update

November 21st, 2010

By now you may have heard that I am the new chairman of the board for the Scrum Alliance. Esther Derby, Ken Schwaber and I cofounded the Scrum Alliance a handful of years ago and it’s grown tremendously since then. We have over 100,000 members, which is pretty amazing when I think back to the days when the people who knew about Scrum would have fit in a conference room.

There has been a lot of criticism aimed at the Scrum Alliance over the past two years, much of it quite deserved. I want to let you know that we have plans to address as many of the issues as we can. As a start we’ve hired a new managing director, Donna Farmer, who has been wonderful to work with during her first six weeks on the job. Donna comes to from outside the Scrum community (which is probably a good thing) but brings a solid background in leading non-profit organizations, including ones in the high-tech industry.

The Scrum Alliance board met in person in Denver in September and established a number of goals for the coming year. These goals were presented to Donna as our vision for the organization, and Donna has produced a document describing that vision which is available for download. Highlighting just a few things that will make up the Scrum Alliance future direction:

  • A focus on being more transparent to our members. The first meeting with Donna as managing director and me as chairman was open to anyone to dial in and join. We took questions from the dozen or so people who joined us. We will repeat this and with more advance notice next time so more can join us. As part of being transparent, we will also publish Scrum Alliance financials on the website.
  • An improved Certified ScrumMaster exam. We want to get to the point where the exam following a CSM class can be a true pass/fail exam. There’s still a lot of work to get there but this is important. We’ll also introduce a pass/fail exam to follow Certified Scrum Product Owner classes at some point.
  • Open membership. People will be able to join the Scrum Alliance without first taking a ceritification course. They won’t be Certified ScrumMasters or Product Owners, of course, but they will be able to become members of the organization.
  • A better Certified Scrum Trainer application (and renewal) process. This thing has been a disaster for years. There are hardly any two CSTs who became such under the exact same criteria. The board of directors gave Donna a proposed vision for a two-step process featuring an application form and review followed by in-person interviews. She is reviewing that for feasibility and I’m sure will make some changes to it but we’re all committed to fixing this process.
  • Continued improvements to the website.
  • An initiative to make sure that newly-minted ScrumMasters (well, everyone, really) knows that “Scrum Is not Enough” and that there is a whole world of great, agile ideas out there. We want Scrum teams to look beyond the Scrum framework and experience the great ideas found in our sister approaches of lean, Extreme Programming, Kanban, Feature-Driven Development, DSDM, Crystal, Adaptive, and more. To start this off, the Scrum Alliance website and newsletter are soon going to feature articles from Bob Martin on XP and Alan Shalloway on lean. I asked these two well-respected authors to share their insights and the Scrum Alliance 100,000′s members will soon benefit from their thoughts. I’m sure we’ll have many more articles like this.
  • We plan to add a second level to the CSP (Certified Scrum Professional) designation. The new level, CSP2, will be rigorous and a very significant accomplishment for those who achieve it. CSP2 will require three years of experience and what we plan to be a tough exam that will probably be taken in-person and proctored. You’re going to need to study for this one. (So will I.) Since we know that the best teams pull in ideas from beyond Scrum (see previous point) we want to make sure that a CSP2 is a well-rounded agilist familiar with key ideas from the whole wide world of agile.
  • To help emphasize the importance of knowing more than just Scrum, we will continue to emphasize the Registered Education Provider program. We want the Scrum Alliance to be the first place when you think of for any type of agile training. Again, see the point above that Scrum is not enough. We want all world-class trainers to join us as Registered Education Providers.
  • More gatherings. The Scrum Alliance will probably *run* only two Gatherings a year but we want to support more. We want local groups who want Gatherings to contact us, tell us what you need, and we’ll provide as much as we can whether it’s financial support, promotion, or whatever you can think of. I’m hopeful that there’s a request for sponsorship form or instructions on the Scrum Alliance website soon.
  • If I didn’t mention it, don’t worry. Certified Scrum Developer is continuing. So is Certified Scrum Coach. So is probably everything else I don’t have room to mention.

    I’d love to hear your suggestions of other things we can do. Please make your suggestions as comments to this blog post. Please help by making your suggestions as actionable as possible. A suggestion of “let anyone listen in on board meetings” is easier to implement than “be more transparent.”

    It’s a good time to be agile.

Should Story Points Be Assigned to A Bug-Fixing Story

November 13th, 2010

When migrating a product from a traditional approach to an agile one, teams commonly bring along a large database of bugs. These are the result of an inadequate focus on continuously high quality. Shortly into their agile initiative, many teams (and their product owners) decide to aggressively work through the bug backlog. A common approach for doing so is to plan to fix x bugs per sprint or spend y hours on bugs per sprint. Sometimes teams write a user story for this activity such as “As a user, I want at least 15 bugs fixed” or “As a user, I want you to spend about 50 hours this sprint fixing bugs so that the application becomes gradually more high quality.” Even a team that doesn’t explicitly write such a user story will usually include a row on its taskboard to make the bug fixing visible and to track it.

In these situations a common question is whether the team should assign some number of story points to the work of fixing these legacy bugs.

If the team does not assign a story point value to this work, velocity will show the amount of “forward progress” the team is making each sprint. This has the advantage of making visible that the team is going more slowly through the work than it could if these legacy bugs had been fixed when originally found.

On the other hand, if the team does assign points to the bug-fixing effort, velocity comes to represent the team’s true capacity to accomplish work.

My usual recommendation is to assign points to the bug fixing. This really achieves the best of both worlds. We are able to see how much work the team is really able to accomplish but also able to look at the historical data and see how much went into the bug-fixing story each sprint. Knowing this can be helpful to a team and its product owner. For example, imagine a situation in which the product owner is considering suspending bug fixing for the next six sprints in order to add a valuable different feature into a release. If we know that the team’s full historical average velocity was 25 but that 5 points went to bug fixing each sprint, we know that suspending bug fixing for the next six sprints will result in 30 (6*5) more points of new functionality.

New Book from Steve Denning on Agile at the Company Level

October 22nd, 2010

Leader's Guide to Radical Management

If you want to see want agile look likes when applied at the corporate level, check out the new book, The Leader’s Guide to Radical Management, by Stephen Denning. Denning is the author of a handful of other excellent, award-winning books and this one is his best yet.

As he describes in the book, Denning set out to discover why so many of today’s organizations are struggling. His research led him to agile and Scrum where he found that these processes were reinvigorating teams and even organizations.

His new book looks at what he saw in these teams and companies and distills it into seven principles. The seven principles of radical management are:

  1. Delighting Clients
  2. Self-Organizing Teams
  3. Client-Driven Iterations
  4. Delivering Value to Clients in Each Iteration
  5. Radical Transparency
  6. Continuous Self-Improvement
  7. Interactive Communication

Sound familiar, don’t they? This book takes these principles we’ve uncovered from doing agile software development and describes how they can be applied at the level of the organization as a whole, not just a single team or even a product development group.

This is the book you give your managers and company executives. It could be the book you’ve been looking for to help you get agile or Scrum spread outside the development group so that it can transform your organization.

I highly recommend it.

A Special Offer on this Book

Here’s something you don’t want to miss. Buyers of this exciting new book can receive an amazing set of bonus gifts and tools, in some cases worth thousands of dollars, when they purchase the book during the initial launch period beginning on Sunday October 24 at 4pm US EST. Check out the offer on SteveDenning.com. I promise you won’t regret it.

Chinese Edition of “Succeeding with Agile” Is About to Be Published

October 16th, 2010

The Chinese edition of Succeeding with Agile will be available in about two weeks (end of October). The book was very kindly translated by Luyu Yang, Jingbin Liao, Andrew Lv, and Zhengyun Chen. They used Scrum to work together on the translation in the ScrumCN.com community. The book will be published through Tsinghua University.

Thank you to everyone for making this translation possible.

Chinese edition of Succeeding with Agile

Avast Combining the ScrumMaster and Product Owner, Matey!

October 10th, 2010

A common question is whether it’s acceptable to combine the role of product and ScrumMaster and give both sets of responsibilities to a single person. In general, combining these roles is a very bad idea. To see why, let’s look back in history and the job of the 17th-century pirate ship captain.

In a recent issue of the Harvard Business Review (October 2010), Professor Hayagreeva Rao wrote about the results of asking his MBA students to design the job of a 17th century pirate ship captain. His MBA students designed a job that lumped together two areas of responsibility:

  1. star tasks–the strategic work of deciding which ships to attack, commanding the crew during battle, negotiating with other captains, and so on
  2. guardian tasks–the operational work of distributing their pirate booty, settling conflict, punishing crew members, and organizing care for the wounded

The problem with this job description is that it mixes star and guardian tasks. As Professor Rao points out, there are very few individuals who excel at both types of task. Star tasks require risk-taking and entrepreneurship whereas guardian tasks require conscientiousness and consistency. A pirate captain good at identifying ships to attack and at leading his crew into battle would likely be bored by the administrative minutiae of the guardian tasks.

Professor Rao claims that people tend to spend most of their effort on the tasks they are good at (and presumably enjoy). My experience certainly bears this out.

Pirates avoided this problem by having a captain responsible for the star tasks and a quartermaster general responsible for the guardian tasks.

So what does the decidedly non-collaborative, non-agile environment of a pirate ship have to do with agile project management? Well, it turns out that the product owner is largely performing star tasks and the ScrumMaster is largely performing guardian tasks. And so, for the same reason that pirate ships had separate individuals as captain and quartermaster general, our agile software development projects should have separate ScrumMasters and product owners.

The Problems with Estimating Business Value

September 19th, 2010

I occasionally see teams that want to put an estimate of “business value” on each user story. They usually do this for either or both of two reasons:

  1. to be able to measure the amount of “business value” delivered to the organization, usually graphing this sprint by sprint
  2. to be able to prioritize user stories by comparing the business value of each story to its cost

There are, unfortunately, some problems with these practices.

First, the value of small bits of functionality are often intertwined. When we get features that are too small (as good user stories are), it is very difficult to put a discrete value on each. Economists call this hedonic pricing. The classic example is putting values on the individual components of a house’s value—size, location, view, etc. How would you value each of those aspects of your house? You can see more on hedonic pricing on Investopedia and this example of pricing clothes dryers shows how complex hedonic pricing can get.

Second, the value of a small bit of functionality can often be said to be the total value of the product. For example, what is the value of the left front wheel of a car? Well, since I don’t want a car without that wheel, the value of it is the total value of the car.

Having identified two problems with assessing the “business value” of a user story, let’s look at a problem with determining the cost of the story.

The Problem of Shared Cost

Finally, when attempting to put business value points on small features (such as user stories) there is the additional problem of determining the cost of the feature. There is often a desire to do some form of return on investment (ROI) analysis on features by comparing the business value points to the cost in story points. However, with small features it is often the case that the true cost of implementing a feature is the sum of the cost of implementing multiple smaller parts of the system, some of which (e.g., architectural work) may not be separately estimated.

For example, the cost of refunding money to a credit card purchase should include some of the infrastructural work done to accept credit cards in the first place. That cost, however, was likely estimated as part of the story to “buy the items in my shopping cart.” Failure to share the cost of this credit card processing infrastructure between both the purchase and refund stories will lead to incorrect ROI decisions.

As with hedonic pricing, this is something economists have wrestled with for years. A simple example is a cow raised and sold for beef and leather. How should the costs of raising the cow be apportioned between the user stories of “beef” and “leather”? We could say the beef cost it all and we get the leather for free but that would be no more correct than the opposite. The benefits (beef and leather) need to be considered together in comparison to the cost of raising the cow.

What Do We Do?

So does this mean that we should never assign business value to features and that we should forego ROI analysis of user stories? Not necessarily. But this type of analysis is best used at the level of epics (large user stories) and themes (groups of stories) because value and cost can be appropriately assessed at those levels.