Posts
Mountain Goat Software |
- Daily Scrum: Not Just for ScrumMasters
- Check In, Don't Check Up
- GASPing About the Product Backlog
- Interview on National Public Radio about Daily Standups
- Points Are About Relative Effort Not Ranking
- Agile Succeeds Three Times More Often Than Waterfall
- Estimating and Planning Are Necessary for Maximizing Delivered Value
- Please Help Me List the Problems with Using Agile or Scrum
| 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. | ||||||||||||||||||||
| 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.  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.  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 opportunites 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:
| ||||||||||||||||||||
| 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.  | ||||||||||||||||||||
| 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. | ||||||||||||||||||||
| 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:
|
| You are subscribed to email updates from Mike Cohn's Blog - Succeeding With Agile To stop receiving these emails, you may unsubscribe now. | Email delivery powered by Google |
| Google Inc., 20 West Kinzie, Chicago IL USA 60610 | |
No comments:
Post a Comment