By Mitch Lacey
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.
