"Four"warned Is Forearmed

How adding a new question to your daily standup can uncover hidden bombshells

28 May 2008

Mitch Lacey, PMP
Mitch Lacey & Associates, Inc.

You are on a team that is both newly formed and new to practicing agile. Your daily Scrum meetings (standups) appear to be going well. You can see the trust building and are looking forward to your team’s first demo. The big day comes, you get in front of the customer and then the floor drops out. Your app starts acting in a way that is definitely not as intended—all because of a hidden blocking issue.

You wonder to yourself, “Didn’t we do everything right? Didn’t we ask all the right questions?” The team dusts itself off and gets ready to start the second sprint. How do you ensure that going forward the team drives out those blocking issues in the daily Scrum? 

Add the fourth question.

The Story

My team, we’ll call them Eagle team, had all been individually burned on projects in the past; we were looking forward to working together because we saw Agile as a way of alleviating pains and creating a killer work environment.

On the second day of our first Sprint, we had our first team daily Scrum meeting. Our plan for the Sprint had been solidified in the planning sessions the previous day and we were ready to rock! Unfortunately, it turned out that we were about to get rolled.

We did not have formal training at the time on Scrum or XP, so we weren’t quite sure what we were supposed to do at these standups. One of the team members, Robert, asked, “OK, so now what?”  The project manager on the team, Steve, looked around sheepishly and then began fumbling through Ken Schwaber’s Agile Project Management with Scrum looking for the guidelines at the back of the book (Ken calls them rules; I like guidelines).

After two embarrassing minutes, Steve found what he was looking for: The Three Questions of Scrum. Steve said to the team, “We need to go through this list of questions.” He rattled them off:

  • What did you do yesterday?
  • What will you do today?
  • What blocking issues do you have?

“Who would like to start?” asked Steve. The team jumped right in. Each person answered what they did yesterday, the work they wanted to accomplish today, and stated their blocking issues.

These blocking issues ran the gamut from “waiting to pair program” to things we never would have brought up in the past, such as, “It’s too hot in this little space.”  It was hot, about 80 degrees Fahrenheit. There was a lot of hardware in the little team space, so this was going to be a recurring issue—and it was one Scrum let us do something about. The team was pleased with our first daily Scrum meeting and immediately felt good about ourselves. We were communicating!

The daily Scrum meetings continued to go well as the sprint went on. The team held itself accountable and the blocking issues that were being raised, even the heat issue, were being addressed. Our happy little ship was moving in the right direction, never mind that monster iceberg on the horizon—the iceberg that only one person saw but didn’t say anything about.

The first demo meeting could not come fast enough. The team behaved like kids on Christmas Eve. We had accomplished a lot of work over the first thirty-day sprint and wanted to show it off. We prepared a slide deck, a mandatory element when presenting at this company, listing out the accomplished work, the work that was not accomplished and what it meant for the team to be done.

One of the stakeholders, Thomas, was also the executive sponsor of the agile experiments the team was running. I noticed him throughout the meeting, perhaps because his face lacked the emotion that the other stakeholders exhibited. It was as if he almost knew what was about to happen.

The team was demonstrating the last component when suddenly the system crashed; well, crash may be too strong a word, but it definitely behaved in a way they did not intend. This caught the team and the stakeholders off guard, but not Thomas. He sat there, watching the team flop around like a fish out of water, looking for answers. One of the team members, Marcelo, said to himself under his breath, “I knew this was going to happen.”

The team was astounded!  Steve looked at Marcelo and asked, “What do you mean? How did you know this was going to happen?” Realizing the entire room had heard what he had said, and hearing Steve’s response, Marcelo became quite embarrassed and looked away, not making eye contact or speaking with anyone while the rest of the team fumbled around trying to save the demo.

The stakeholders let the team off the hook and in the end, everyone had a good chuckle. The team was building a mission-critical system to support an online business for millions of subscribers. They were expected to find issues like this, early, and address them. Plus, the team was also experimenting with agile, so the communication breakdown was accepted as an early failure, but one that would not be tolerated by the stakeholders again in the project. Our failure to communicate was as critical to fix as the bug that surfaced in the system—Thomas thought it was the most important thing for the team to address to date, bug be damned!

After the meeting, I grabbed Steve and Thomas to talk about what had happened. The first question out of Thomas’ mouth was not about the system. “What happened with the team?” he asked. This clearly caught Steve off guard. Steve was confused and asked for more clarification.

“You clearly had some blocking issues that were not being addressed throughout your Sprint, why weren’t you resolving them?” Thomas said.

Now Steve was even more confused. The team had been answering the three questions of Scrum. They had raised blocking issues and addressed them. Heck, even the heat issue was resolved after $5,000 of duct work to pump more cold air into the space! Steve was convinced that Thomas didn’t know what he was talking about, and challenged him. “Thomas, I’m not sure you have all the data you need to say that.”  Steve went through the Sprint backlogs with him, showing him the work being done daily. He walked Thomas through our risk and issues log, highlighting the fact that the issues were being resolved.

Steve thought he was making a pretty good argument. Thomas held his ground, “I’m not talking about the issues that are being surfaced by the team; I’m talking about the issues that are not being surfaced by the team. Those are the real issues you need to look for; they are the ones that will cause you to have more demo meetings like you just had.”

Steve and Thomas spent the next two hours analyzing what happened. They discussed the importance of recognizing nonverbal communication and discussed techniques that would help to address it. They discussed the personalities of the team members and most importantly, tied them together. This was the “ah-ha” moment for Steve.

One of the team members, Marcelo, is very introverted. He does not like to make eye contact, often goes out of his way to avoid small talk with people and likes to keep to himself. Yet, here he was working with four other people that he had no history working with, in a team workspace, pair programming no less! He had signed up for this project based on the hope that it would go well, that it would deliver value and that it would stretch his skills. What the team had failed to realize was that it would also stretch his personality and working style habits.

Marcelo knew the team was going to see an issue in the demo, yet he never raised the concern during the Sprint. He was the proof that the team had missed rooting out the real issues that most teams encounter, like communication.

That was when Steve came up with “The Fourth Question.”

The Fourth Question

What is the fourth question in Scrum?  Its simplicity is embarrassing, but it is a valuable tool to ensure that the team is on track—especially for new teams. In the daily Scrum meeting, start with the three questions as you normally would:

  • What did I do yesterday?
  • What will I do today?
  • What blocking issues do I have?

Now add the following:

  • What is your confidence, on a scale of one to ten, that the team will accomplish the goal of this Sprint?

That’s it. Why does this work?

In the story above, what Steve and Thomas theorized, and later validated, was that Marcelo was not comfortable with conflict. He was going through the motions in the daily Scrum meeting, but he was not yet vested in the team. The trust among the team was not as well established then as it was as the project progressed.

Another factor why Marcelo was not stating what he truly felt was that other team members were strong extroverts. These people were very comfortable with conflict and, in the beginning, dominated the daily Scrum meetings. This behavior caused introverts (and sometimes the rest of the team) to agree despite their misgivings because the strong personalities would not back down.

In these scenarios, team members do not state the real issues, only surface issues. I have witnessed the implosion of teams because they were not able to root out real team issues. They stayed focused on the software, not on themselves. When they failed, and they all do, they blamed the process, not themselves. The teams that succeed are the ones that are open to change, to experiments, to trying new things. It is these teams that realize they need to improve to succeed, so they remain focused and disciplined.

The fourth question gets past surface issues and carves right down to the core issues—the ones that have long-term (and negative) impacts.

As the Eagle project progressed, and the team bond and trust became stronger, the team found that the fourth question was not needed. Individuals became comfortable with conflict, and those extroverts with strong personalities learned to “tone it down.”

Keys to Success

So, when should you use the fourth question of Scrum? I recommend using it at the beginning of any new project. Even if people know each other, they may not have built the trust required to have the open and honest conversations that ensure project success.  I’ve made it a required element for any team that is either new to itself or agile practices and principles. Eventually, the team will grow to a point where the fourth question is no longer necessary. The team will know when it is no longer needed, so the team should decide if and when it should be dropped.

When using the fourth question, look for the following:

  • Nonverbal communication. What is being communicated through body language is often as important as what is being said out loud. Being aware of it and monitoring for it is essential.
  • Project issues that are not surfacing. If you are going through your daily Scrum meeting without uncovering many impediments, yet during the Sprint, issues “keep cropping up,” you need to add the fourth question of Scrum. This also applies to stakeholder demonstration meetings.
  • People who are not comfortable with conflict. This closely relates to nonverbal communication; however, the ScrumMaster or project facilitator may not be skilled in identifying nonverbal communication. Seek out the advice of others that have worked with the members on the team in past projects to better understand how people work.
  • Opportunities to practice continuous learning. Two elements that have helped teams that I have worked on and coached are the Myers-Briggs assessment and workshop and Bolton’s People Styles at Work. Providing the team with the tools needed to stretch themselves personally and to develop their competencies will have a lasting impact on the current project and all future projects.

 

Article Rating

Current rating: 0 (0 ratings)

Comments

Angela Druckman, CST,CSP,CSM,CSPO, 5/29/2008 4:36:59 PM
I like this idea a lot. One of my current teams is having a hard time meeting their committments. In a nutshell, they over-commit every sprint and indeed do not seem to view the Sprint Backlog as a "committment" at all. I would like to use this question to help them recognize sooner when they have wandered into "wishful thinking" territory.
Chad Eaves, CSM, 5/29/2008 9:54:32 PM
If Marcelo is avoiding conflict, is there not a risk he would say things are fine if everyone went before him saying they had high confidence? Perhaps this fourth question can be extended by using a tool like the planning card deck for its answers. This way an accurate response could be given prior to being influenced by other team members?
Bent Myllerup, CST,CSC,CSP,CSM,CSPO, 5/30/2008 4:30:09 AM
I find the fourth question quite clever figured out by Steve. Those kinds of questions are named Scaling Questions and are one of the techniques that are used in several coaching models.

I think that the main problem in this case is lack of developing the sufficient level of team identity. Well formed teams doesnΓÇÖt just happened by coincidence. Building up a strong team identity will hopefully help Marcelo to feel calm as a team player and help him bring the unpopular information forward.

Spending some time on building up trust and acknowledgement inside the team can be quite valuable for the performance and outcome of the team. I typically plan one day of team building before project kick off with several follow-ups in the early phase of the project (in addition to holding the Retrospectives at sprint end, of cause). I have a pending article on the matter, so get back in a couple of weeks.
Andy Murthar, CSM, 5/30/2008 6:48:35 AM
I am all for adding any 'tools' that the team feel will help them to acheive their commitment in a satisfactory manner. However, i have a few comments to make on the general story. 'No formal training' I would always recommend a workshop run by the Scrummaster before leaping into Scrum practices. I recommend the scrummaster reads the book, then reads it again, and again......Then distributes a package including the 1st chapter and the 3 roles.Where was the Scrummaster? He\She was not mentioned in this story. A good Scrummaster has to have 'extra sensatory perception' :) to enable him\her to read the team and it's personality makeup and address the Marcelo issue at an early stage.The Scrummaster is also the only role responsible for dealing with sorting out impediments\blocking items.
What are the iterative testing procedures? Also the team has two hours to prepare the review\demo meeting.
Having said all this, Agile is iterative in it's development practices and I think this is also true of the learning curve for its process practices "if at first you don't suceed; call it version 1"
Bent Myllerup, CST,CSC,CSP,CSM,CSPO, 5/30/2008 7:11:33 AM
I agree in AndyΓÇÖs views about formal traning. As a Scrum Coach, I have a slideshow that I present at the initial workshop. This slideshow introduces all the basics of Scrum. In the first two or three sprints the team will have parts of this presentation repeated just before a new activity starts ΓÇô meaning: The day before Sprint planning, the team get a quarter to half an hour of repetition on the objectives of Sprint Planning; The day before Sprint Review, the team get a quarter to half an hour of repetition on the objectives of Sprint Review; and so on. I find this quite useful in helping the team to live out Scrum.
Scott Downey, CSP,CSM,CSPO, 5/30/2008 4:55:09 PM
Good article, Mitch. I started asking that question daily when I was on a mission critical project in January and found it tremendously useful. We had to somehow pack three months of work into just 30 days. I found that fourth question, regardless of the team's Scrum maturity, helped them make that critical shift from "me" to "we" when evaluating the Sprint's health. I highly recommend it. By the way... we delivered 150% more value in 30 days than the waterfall team had estimated could be done in 90 days at 60% confidence. Our success was, in part, due to that crafty fourth question. Thanks for sharing your thoughts.
Victor Szalvay, CST,CSP,CSM, 5/30/2008 6:08:49 PM
Great article, Mitch! I like the scale of 1-to-10 idea very much.
Mitch Lacey, PMP, CST,CSP,CSM,CSPO, 6/1/2008 1:33:37 PM
Hi folks, thank you for the comments and feedback. This article is part of a book that I am writing for Addison Wesley titled "adopting agile: 101 tips for surviving your first year" - you can read more sample chapters on my site at http://www.mitchlacey.com

Now comments on the comments:
<b>Angela</b> - thank you.
<b>Chad</b> - in this case, no. The person on the team (names changed) was not comfortable with conflict, but was comfortable with stating a number. This was because the team was new and the bond between them had not formed.
<b>Brent</b> - thank you.
<b>Andy/Brent</b> - as a Scrum Trainer, I'm all for training up front - however not every organization works that way. I consider formal training to be a CSM course or some other course taught by some experienced practioner. The team did end up going to a CSM course with Ken but only after it proved that it was committed, meaning the organization would sponsor the activities of the team but the team needed to prove itself before the organzation spent money on training. Everyone read books - about 14 to be exact, on leadership, engineering practices and project management practices.
<b>Scott</b> - I agree, it does help make the shift from me to we, and I like that.
<b>Victor</b> - long time no chat - thank you for the comments.
Anonymous, 6/3/2008 9:24:44 PM
Hi Mitch. Good stuff. I have long used a variant of your fourth question, but it is asked at the end of the standup to the whole team and everyone answers it at the same time by using a thumb vote -- thumb up means absolute confidence, thumb down means zero confidence. I call it taking the team pulse. The advantage of all voting at once is the same advantage we see in planning poker: no influence. And you are right, it is the most effective way of telling if we are on target to completion of the work committed; it overrides any burndown chart data we may see. I have used both analog and digital/binary versions of thumb voting, with a more recent preference for the latter. I tend to only use it if the sprint appears to be in trouble, or a team member or stakeholder has expressed concern based on work remaining.

Gut feel overrides hard data every time.
Alicia McLain, CSM,CSPO, 6/4/2008 2:06:47 PM
Excellent coaching tips Mitch! What people are often ill-prepared for with a 'move to agile' are all of the organizational issues associated with a culture shift. This is organizational change and there is a big picture to this process... Andy's points are well taken and I'd add that I completely agree with training. I led a grassroots effort to adopt Scrum at my previous company and I believe the fact that we focused on the role of 'Team' and created a 1 day interactive, hands on training that included simulations and exercises in conflict resolution, communication and team dynamics, and the Scrum workflow/process helped everyone who would have the role of 'team' understand what was expected of them when they began the process. To Bent's points, I'd add that also having an understanding of possible cultural issues associated with how people may work together on teams can benefit the Scrum Master's ability to still get what he/she needs in terms of data on a daily basis. IMHO, 'Kiss Bow or Shake Hands' is a timeless business asset to anyone who needs to work with and understand different cultures (ISBN-10: 1593373686). Love Tobias' approach as well. Finally a technique that I have found also works well in situations like this is a little 'meeting before the meeting'. This may take some extra effort on the part of the Scrum Master but it can possibly prevent a train wreck down the road. Take Marcelo aside for a casual one on one and ask a few questions about how things are going. Ask Marcelo how he'd like to add his feedback on a daily basis...maybe he'd respond better to something a little different. Certainly not exempting him from the stand up but find out what's happening with him in a one on one and its possible you can find a way that works for all.
Manoel Pimentel Medeiros, CSP,CSM, 6/5/2008 11:02:26 AM
Hello Mitch,

I liked from their tips to resolve common problems in the project management.

Thank you for the excellent text.
Dave Bales, CSC,CSP,CSM, 6/7/2008 9:09:38 PM
On the second half of our sprints I start asking the team if they think that we are going to make the commitment or if we need to think about descoping, and then I repeat it during the daily stand ups all the way up until the sprint review. It sounds like a slight modification of your fourth question although less formal and more subjective than a 1-10 scale. This can then lead to additional questions and conversations if the team think that there are some areas that are weaker than others and apropriate actions such as monitoring the situation over the next few days or out right descoping are needed.

In terms of managing conflict within the team, it takes a while to foster a "safe" environment where team members feel that they can talk openly about issues or their concerns and does not happen over night. The team need to be bonded and have a sense of compassion to other team members and thinking in the "we" as opposed to the "I" is definately where they need to be. How to get there? Well that can be another article...

I have taken some inspiration from Peter Senge's "The Fifth Discipline" where he talks about the differences between collaborative dialog to arrive at new ideas rather than clinical discussions that are no more than positional postering. And this is where I have tried to grow the team to be a self thinking and self healing team considering all views and removing all threats to those views. In addition, we tend to do sprint backlog items as a group rather than individual tasks, pair programming for example, and this results in no single individual being responsible for any items that may be compromising the commitment. This then reduces the "anxiety" of any one person relaying bad information back to the team.

It has taken a while, around 6 months or so since we started using scrum, but the team are more accepting of bad news and look at the overall picture with a realistic take on where their commitment is heading, and what actions they need to get a good outcome. Keep going with your team. It does get better as the confidence grows.
Piotr Uryga, CSM, 6/12/2008 8:41:48 AM
Great article Mitch. I have to agree with Your statement, that new teams working on new projects tend to hide some problems under the surface. As ScrumMaster I started asking "Are we gonna make it?" question at the end of Daily Scrums when Sprint was finishing. Sometimes it had positive effect and new impediments were rose by the team, sometimes not. I'll definitely try out "the Fourth Question" on my new projects, maybe it'll work better.
Becki Block, CSM, 8/25/2008 3:38:17 PM
Thanks Mitch. I'll be adding this to our scrum meetings. And I'll be checking out the chapters of your book as well! :-)
Huet Landry, CSM, 8/28/2008 2:46:28 PM
Well stated!
Last year, I served as ScrumMaster for a new team, and the "fourth question" naturally came up as part of our discussions. It wasn't a formal part of the daily scrum, but team members would raise the issue whenever they felt that the sprint goal or product goal was being threatened..It began during our Sprint 0, because the team was concerned about how they would be sure that all of the expected product functionality would fit within a fixed set of sprints. That led us to create a nominal view of stories across all sprints. Our sprints were 20 working days, and we generally the issue of comfort with both the sprint project goals was raised by various team members several times each week in the first two sprints, but far less in the subsequent ones.
Danny (Danko) Kovatch, CST,CSM, 8/29/2008 6:16:04 PM
Indeed great article, Mitch!

However, instead of asking a forth question I encourage the teams to paint the wording of sprint goal (e.g. "Creating the login page") with the "right" color (and the scale is 1-red to 10-green). This way I kill two cannon balls in one bird...:-), not only the team members keep checking themselves (inspect and adapt) but all the other (chicken) can understand the situation even if they did not arrive to the daily scrum meeting (visibility)

Danko
Vinay Krishna, CSP,CSM, 11/9/2009 6:57:53 AM
Nice article and great idea!!

Definetly it would help a lot in all critical projects to keep checking the team's confidence by the team. I would like to use this and update you my experience.

You must Login or Signup to comment.