please enable javascript

Daily Scrum: Not Just for ScrumMasters

April 8th, 2012

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

April 2nd, 2012

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

March 14th, 2012

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.
Read the rest of this entry »

Interview on National Public Radio about Daily Standups

February 24th, 2012

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

February 19th, 2012

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:
Read the rest of this entry »

Agile Succeeds Three Times More Often Than Waterfall

February 13th, 2012

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)
Read the rest of this entry »

Estimating and Planning Are Necessary for Maximizing Delivered Value

February 6th, 2012

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).
Read the rest of this entry »

Announcing an Online Agile Estimating and Planning Course

January 31st, 2012

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.
Read the rest of this entry »

Rotating the ScrumMaster Role

January 26th, 2012

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.
Read the rest of this entry »

Please Help Me List the Problems with Using Agile or Scrum

January 3rd, 2012

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:
Read the rest of this entry »