Template Editato By Force Downs

Mountain Goat Software

Mountain Goat Software

Daily Scrum: Not Just for ScrumMasters

Posted: 08 Apr 2012 07:55 PM PDT

[

I never refer to the daily scrum (or daily standup) meeting as a "status meeting." The term "status meeting" is too pejorative for most of us. For me it conjures images of sitting around a table with each person giving an update to a project manager while everyone else feigns interest while either mentally preparing for their own upcoming update or wondering how much longer the meeting will last.

I prefer to think of the daily scrum as a synchronization meeting. Team members are synchronizing their work: Here's what I did yesterday and what I think I'll do today. How about you? Done well a daily scrum (daily standup) meeting will feel energizing. People will leave the meeting enthused about the progress they heard others make. This won't happen every day for every team member, of course, but if team members dread going to the daily scrum, that is usually a sign of trouble.

I want to offer one of my favorite tips for an effective daily scrum: If you're a ScrumMaster, don't make eye contact with someone giving an update. Making eye contact is human nature. When we speak, we make eye contact with someone. It's only natural that a team member will look at the ScrumMaster; call it a legacy of too many years under traditional management but a lot of people on Scrum teams do look at their ScrumMasters a bit like managers to whom they need to report status. By not making eye contact with someone giving an update, the ScrumMaster can, in a subtle way, prevent each report becoming a one-way status report to the ScrumMaster. Each person's report is, after all, intended for all other team members.

Check In, Don't Check Up

Posted: 02 Apr 2012 07:43 AM PDT

[

I've never been a micro-manager, especially not since using agile and Scrum. I could have turned into a micro-manager early in career, except I've always been too busy to spend my time checking up on people. But, while I've avoiding checking up on teams or people, I've never been reluctant to check in with them. I was recently reminded of this by reading an article about the importance of small wins. scoreboard

While checking up and checking in may seem similar, there are four key things a good ScrumMaster or agile project manager can do to avoid crossing the line into micro-management while still checking in on a team:

1) Be sure the team has the full autonomy to solve whatever problem they've been given. A good ScrumMaster ensures the team is given complete autonomy to self-organize and achieve the goal its been given.

2) Don't just ask team members about their progress; offer them real help. ScrumMasters do this, for example, by protecting the team from outside distractions and removing (or even anticipating) any impediments.

3) Avoid blaming individuals. Things will occasionally go wrong. Assigning blame when that happens will make people feel they are being checked up on rather than just being checked in with.

4) Don't hoard information. Micromanagers tend to view information as a resource to be retained and only shared when needed. A good ScrumMaster will share anything learned by checking in with others who could benefit from it.

So, stop reading this blog and go check in with your agile team right now. Just don't check up on them.

GASPing About the Product Backlog

Posted: 14 Mar 2012 08:40 AM PDT

[

I've been wondering lately if Scrum is on the verge of getting a new standard meeting--the Backlog Grooming Meeting, which is a meeting an increasing number of teams are doing each sprint to make sure the product backlog is prepared and ready for the start of the next sprint. a product backlog To see why a Backlog Grooming Meeting may be a few years away from becoming a Generally Accepted Scrum Practice, or what I call a GASP, let's revisit the early 2000s. Back then, Scrum didn't have a formal Sprint Retrospective Meeting. Prevailing wisdom at the time was, in fact, fairly opposed to such a meeting. The logic was that a good Scrum team should be always on the look out for opportunities to improve; they should not defer opportunities to discuss improvement to the end of a sprint. That argument was a very good one. However, what was happening on teams was that day-to-day urgencies took precedence and opportunities to improve often went either unnoticed or unacted upon. And so what most teams eventually realized was that of course we should improve any time we notice an opportunity, but at a minimum each team should set aside a dedicated time each sprint for doing so--and thus the retrospective became a standard part of Scrum. This was helped along tremendous by the great book, Agile Retrospectives: Making Good Teams Great, by Esther Derby and Diana Larsen. I've had more CSM course attendees recently asking questions about a Backlog Grooming Meeting as though it were a GASP. Many are surprised when I tell them that not every Scrum team has such a meeting each sprint. I still don't advocate every team conduct a Backlog Grooming Meeting each sprint--as with the early arguments against retrospectives, I'd prefer backlog grooming to happen in a more continuous, as-needed way--but so many teams are successfully using a Backlog Grooming Meeting, arguments against it may be on their last gasps. Share what you think below. Will a Product Backlog Grooming meeting become so common it becomes a Generally Accepted Scrum Practice (GASP)?

Interview on National Public Radio about Daily Standups

Posted: 24 Feb 2012 08:38 AM PST

[

Following the article in the Wall Street Journal on daily standup meetings a few weeks ago, a number of other places have interviewed me abut the topic. I don't know why they're asking me, but the interviews have been fun so far. The latest was on the National Public Radio (NPR) Marketplace show on Monday, 20 February 2012. You can listen to the whole show but Sarah Gardner's interview with me begins at 18:50.

Points Are About Relative Effort Not Ranking

Posted: 19 Feb 2012 03:24 PM PST

[

I'm thinking of buying a new car. So I've put together a list of cars to consider. Here they are in priority order:

  • Bugatti Veyron Super Sports
  • Pagani Zonda Clinque Roadster
  • Lamborghini Reventon
  • McLaren F1
  • Koenigsegg CCX
  • Porsche Carrera GT
  • Aston Martin Vanquish
  • Toyota Prius
  • Toyota Camry
  • Tata Nano

Unfortunately, though, I'm not sure I can afford my top priority car. So let me put some points on each car. I'll start with the least desirable car and put a 1 on it, a 2 on the next car, etc. That reorders our list so with points on each car we get:

  1. Tata Nano
  2. Toyota Camry
  3. Toyota Prius
  4. Aston Martin Vanquish
  5. Porsche Carrera GT
  6. Koenigsegg CCX
  7. McLaren F1
  8. Lamborghini Reventon
  9. Pagani Zonda Clinque Roadster
  10. Bugatti Veyron Super Sports

Now I think about my personal spending limits and I can spend between $25-$50k on a car. I'd like to be closer to $25k but a good salesman might get $40-50k out of me. Since the Tata Nano (at one point) goes for about $2500 that means I can afford between 10-20 points. So, looking at the list again and the points assigned to each car, I think I'm going to buy a Bugatti (10 points), a Pagani (9) and a Tata (1 point). Unfortunately, when I show up at the Bugatti dealer, I am somewhat informed that the Veyron lists for $2,400,000. What went wrong here? The problem is that points are not a ranking. When we rank product backlog (or car backlog) items we use ordinal numbers (such as first, second, third). We cannot add ordinal numbers together. We cannot say that the distance between first and second is the same as from second to third. The Bugatti in this example is not ten times the cost of the Tata. Ranking stories (or cars) like this is worthless. We want story points to instead reflect the relative effort involved. For cars we could put points on as follows:

Tato Nano 1
Toyota Camry 12
Toyota Prius 14
Aston Martin Vanquish 102
Porsche Carrera GT 193
Koenigsegg CCX 218
McLaren F1 388
Lamborghini Reventon 640
Pagani Zonda Clinque Roadster 740
Bugatti Veyron Super Sports 960

These points are of course based on the relative costs of these cars. I need to be able to do the math on these estimates that someone would want to do. Someone can afford 20 points on a car--which should they buy? Should I buy this item for 10 points or those other two for 5 points each? You can't do that when points are assigned via a ranking. Story points on an agile product backlog represent the effort to implement the backlog item. Since cost on most software projects is made up almost exclusively of labor (rather than buying parts), we can think of a story point estimate on the product backlog as being the cost, as in the car example here. And, when I look at the relative costs here, I can tell I belong in the Toyota dealership rather than the Bugatti dealership.

Agile Succeeds Three Times More Often Than Waterfall

Posted: 13 Feb 2012 07:22 AM PST

[

Agile projects are successful three times more often than non-agile projects, according to the 2011 CHAOS Manifesto from the Standish Group. The report goes so far as to say, "The agile process is the universal remedy for software development project failure. Software applications developed through the agile process have three times the success rate of the traditional waterfall method and a much lower percentage of time and cost overruns." (page 25) The Standish Group defines project success as on time, on budget, and with all planned features. They do not report how many projects are in their database but say that the results are from projects conducted from 2002 through 2010. The following graph shows the specific results reported. Agile and waterfall success and failure rates

Estimating and Planning Are Necessary for Maximizing Delivered Value

Posted: 06 Feb 2012 10:11 AM PST

[

Because I'm so interested in estimating and planning, I always take notice when I see a new blog post or news group posting claiming, "Estimating is waste! Don't do it!" The thing that never shocks me about these arguments against estimating and planning is that they never come from the business people for whom we are developing products or systems. They understand the value of estimates and plans (and the shortcomings of poor estimates and plans).

Let's consider that perspective for a moment. How many significant things in your personal life would do without at least some planning first? I doubt you would plan a wedding, a relocation to another city, a holiday trip, or any such event without first engaging in some amount of planning. Suppose you are considering a first-ever trip to Italy. You would plan that--which cities? how long in each city? what's your budget? and so on would be some of the questions you would consider. Now suppose you are planning your one hundredth return visit to the city in which you grew up. You will even plan this trip--even if the extent of that planning is to decide you don't need to plan at all. Planning is the act of thinking about the future. Sometimes that future holds risk and uncertainty. In those cases we plan more than when the future is highly predictable as a hundredth visit to your childhood home town would be. When a future activity is highly predictable, planning may consist of nothing more than a few milliseconds of rejecting the need to plan further.

Of course on a software project it is rarely this simple. What about estimating? Do we really need to estimate? Yes, because estimating is a pre-requisite to planning. You cannot plan without estimates in mind. Those estimates may be very informal and very implicit. As I write this I am on a flight to California. Before boarding the plane I got cash from an ATM. I estimated my upcoming need for cash to do that. $200 should do it. That estimate took less than a second and I was perhaps not even conscious of it, but it was made. When a product owner says, "I'd prefer to add this feature rather than that feature," the product owner is acting with at least some implicit estimate (perhaps guess) of how long each will take. When a programmer chooses late in the day to fix a bug rather than start a new user story before going home, that programmer has made an implicit estimate that fixing the bug fits better with the hours left in the day. Teams that say, "We won't estimate. We'll just make every user story the same size," are estimating. They are estimating that this user story is the same effort as all other user stories. I'd even argue that it's harder to make each story the same size than it is to use a small range of effort sizes on various stories. These estimates must be made. Yes, they can be subconscious but they are made. Those who blog and post to newsgroups saying "estimating is waste, don't do it" are ignoring these types of estimates. But are these casual, perhaps subconscious, estimates OK? Wouldn't teams be better with formal estimates? Perhaps but not in all cases. A team should estimate and plan only to the extent that further investment in estimating and planning will lead to different actions.

If you will do the same thing even if you estimate or plan more, stop. But if further planning is likely to lead to better decisions (more confidence in a delivery date, better prioritization of functionality, or so on), then estimate and plan further. As an example, we recently added quite a bit of functionality to this website to support our new eLearning course on Agile Estimating and Planning. I did not ask the programmer who did that work to give me more than cursory estimates. I'm still enough of a programmer to have an idea how long the new features would take. I've worked with him long enough to know how fast he is. Asking him for detailed estimates would not have changed anything about that project. So estimating and planning are necessary. They can (and should be) lightweight. You should stop when further planning is not likely to lead to improved decisions worth the extra effort.

Announcing an Online Agile Estimating and Planning Course

Posted: 31 Jan 2012 08:00 AM PST

[I'm very excited to let you know that we now have an online course on Agile Estimating and Planning. The course is a series of videos and interactive quizzes. Videos are a combination of screencast (slides) and live action of me. All videos are extremely professionally done--no handheld video camera or recordings of me talking into my iPhone. The entire course is now available on the Mountain Goat Software site. Check out the free previews. The course can be purchased for streaming or for streaming + download. We also offer group discounts and an innovative, easy way for someone such as a manager, ScrumMaster or similar to buy and distribute licenses to team members. The 44 videos are interspersed with 9 interactive quizzes. If you miss a quiz question, you get immediate feedback telling you what the right answer is. This approach may not hold up to some certification organization's rigor, but it's sure a helpful way to make sure you've learned the topic. You can see an example below. Sample quiz question from online agile training The course qualifies for 4 PDUs from the Project Management Institute and is perfect for PMPs or aspiring PMI-ACP candidates. At the end of the course, you earn a Certificate of Completion as proof of your participation. Overall this course has been in development for 16 months and we're hopeful you'll be able to see the attention to detail we put into it. I hope you find this news as exciting as I do. Please help me out by spreading the word to your friends, coworkers, grandmothers, and anyone else who might be interested. Thank you.

Rotating the ScrumMaster Role

Posted: 26 Jan 2012 07:18 PM PST

[Some teams that struggle with choosing the best ScrumMaster decide that an appropriate strategy is to rotate the role among all team members. I don't advocate this, as I don't think it demonstrates an appropriate respect for the challenges and significance of the role. In my family, we rotate who cleans the table and loads the dishwasher. Any of us can do that job. We do not, however, rotate who cooks dinner. My wife is a far better cook than anyone else in the family. We want the cooking to be the best it can be, so we don't rotate that job. If you want your Scrum team to be the best it can be, I do not recommend that you make a habit of rotating the job of ScrumMaster. However, there are some occasions when you may want to rotate. The most common is when you want to create learning opportunities. For example, if team members are struggling to understand the duties of the ScrumMaster, they may want to consider rotating each team member through the role. This may allow each to develop an understanding of what it means to be a ScrumMaster. Similarly, if a team identifies four or five good ScrumMaster candidates among their ranks, it may want to rotate among them, giving each a chance to try the role. Then by considering the performance of each, the team will hopefully be able to choose the most appropriate ScrumMaster. Bob Schatz and Ibrahim Abdelshafi of Primavera Systems point out another reason why rotating might be useful.
With time the team can begin to treat this position as their manager. And the person in that position typically detects and dutifully fills the apparent need. The result is a breakdown in the team's self-management practice. By rotating the responsibility at the start of each sprint, it diffuses the role and makes it a shared team responsibility and establishes a balance of power. (The Agile Marathon in the Proceedings of Agile 2006)
So, although it is possible to rotate the job of ScrumMaster, I recommend doing it only for specific reasons, such as those just given, and only temporarily. Rotating should not be a permanent practice. There are simply too many problems with it, including the following:
  • Someone who has rotated into the role usually has other, non-ScrumMaster tasks to perform during the sprint, and these often take priority.
  • It's hard to train enough people to do the role well.
  • Some people will use their time as ScrumMaster to try to push through changes to the process.
  • Designating someone as ScrumMaster for a sprint or two does not automatically make someone value the job, which can lead to ScrumMasters who think Scrum is a mistake.

Please Help Me List the Problems with Using Agile or Scrum

Posted: 03 Jan 2012 02:03 PM PST

[

I'm trying to create a list of the biggest, most common, or hardest to overcome problems that a team might face when adopting Scrum or agile. I could really use your help by contributing to the list by adding a comment to this post. I'm thinking of things like:

  • We have five product owners. What do we do?
  • We drop work from every sprint. How do we get out of that habit?
  • We can't ever get things "potentially shippable" at the end of a sprint. How can we?
  • We spend forever in planning meetings. How can we spend less time doing that?
  • etc...

So, what problems have you encountered or heard of teams encountering? Thanks for your help.

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)