Why “No Issues” Is Not An Acceptable Answer
Many of the software development teams at my company now practice the daily standup from Scrum project management. There’s a lot of great value in these meetings, even if a team is not practicing anything else from Scrum.
The Anti-Pattern
Several months ago, my team fell into a rut during our daily stand ups. At the time, I assumed that it was just our team – the mix of personalities and people on the project. However, I’ve noticed the same pattern emerging in many of the other teams in my department, recently. I’m almost convinced that the problem I’m seeing is a daily stand up anti-pattern – it is, at least, a smell that needs to be addressed appropriately. The anti-pattern in question is:
My team members (myself included) were consistently stating “No Issues” during our stand ups.
On the surface, it may seem like a person stating “no issues” would be a good thing. They didn’t have any issues that prevented or impeded their work and progress on the project, yesterday. While this may be a goal – a long term vision of a team that is entrenched in a process of continuous improvement – it is not a realistic, viable state for any team over any length of time. An individual person or pair may have had a great day – they may have been very productive and may not have run into and productivity losses during a single day. The problem is not that an individual stated “no issues” for a given day. The problem is that the entire team was stating “no issues” day after day after day, for weeks on end.
Unless your team is perfect, working in a perfect environment, with no constraints or external factors involved in their process, answering “no issues” consistently and constantly, is nothing short of lying to yourself and your team.
Reality Check
When was the last time you spent 10 minutes wrestling with a problem, spent 10 minutes in the debugger of your IDE or looking at log files generated by your code? When was the last time you hit up Google for an answer to a question, or struggled with a design before asking someone on the team for help?
Or worse: When was the last time an external factor had a negative impact on your ability to work? A boss asks you to join in a meeting. A coworker needs a ride to the mechanic to pick up a car. A department head decides that their support of your project is a lower priority, for whatever reason.
It does not matter how large, how catastrophic – or how insignificant and small the issue is. Any struggle, any minor distraction, any politics that need to be dealt with – anything that is a waste of time or other resources in the context of productivity… they are all issues that need to be reported during the stand ups. They all cause a drop in productivity. They all cause schedules to be adjusted (even if the project schedule accounted for them, from the start, the schedule was still adjusted for them). They all take your team’s efforts away from adding value to the project.
Some Conversation On “No Issues”
I tweeted the anti-pattern of “No Issues” this morning and it sparked some short, but great conversation. There seems to be some consensus on this being an anti-pattern. At the very least, the problem is recognized by several people, with several different causes and effects.
derickbailey: daily standup anti-pattern: stating “no issues” constantly, and consistently.
jbogard: @derickbailey doesnt that go away when you start tracking flow? i.e., something is stalled in one part of the process?
derickbailey: @jbogard only if the team is honest enough to admit something is stalled. a lack of trust, personal ego, and other factors can prevent that.
derickbailey: @jbogard only if the team is honest enough to admit something is stalled. a lack of trust, personal ego, and other factors can prevent that.
derickbailey: @jbogard it may only be an anti-pattern is ‘young’ teams or teams new to continuous improvement.
derickbailey: @jbogard but i have serious suspicions that it is an anti-pattern, period. even the most productive teams will have issues, regularly.
derickbailey: @jbogard it’s why “continuous improvement is necessarily continuous” (see @bellware ‘s blog post on that)
[link: Nothing Fails Like Success – Why Continuous Improvment is Continuous]jbogard: @derickbailey dont confuse honesty with lack of insight, or ignorance though. people don’t always know what a blocking issue looks like
jbogard: @derickbailey that’s why i see things like task boards and story/kanban boards essential. the data don’t lie.
derickbailey: @jbogard yeah, that’s for sure. we need to engage our teams in open dialog so that everyone can recognize the issues
jbogard: i see reporting blocking issues in the same vein as anecdotal evidence in science and eyewitness accounts in law. lots of bias to wade thru
chadmyers: @jbogard Yep. Repeatedly saying “no issues” might also be an indicator of a lack of perception of the problem. This clues the manager
derickbailey: @jbogard task boards and ‘flow’ charts help identify that there is a stall. it takes people and honesty to identify why its stalled.
caseycharlton: @chadmyers @jbogard @derickbailey repeated “no issues” can also be a good indicator of project in “dead mans walk”
caseycharlton: @derickbailey resignation to failure is often characterised by everyone saying “no issues” .. path of least resistance
jbogard: corollary to “the data dont lie” is “the ball dont lie”. basketball fans will get this one…
jbogard: @chadmyers perception, and ego too. it takes humility to ask for help
jbogard: whats the difference between a blocking issue and learning through figuring something out?
derickbailey: @jbogard there is no difference. all blocking issues are opportunities to learn through figuring something out, and vice-versa
jbogard: @derickbailey there is a difference in learning between solving a blocking issue yourself vs. someone else doing it with you though
derickbailey: @jbogard true. the distinction, in the context of daily stand-ups is only relevant if the issue is still blocking, though.
derickbailey: @jbogard if the issue has been identified and fixed before the next stand-up, it should still be reported during the stand-up
derickbailey: @jbogard we say “i ran into XYZ and fixed it with ABC”, or we say “i need help solving XYZ”. either way, issue XYZ is reported
Possible Causes
There is no shortage of causes for this anti-pattern. We can see a number of them mentioned in the conversation above, already.
Inability To Recognize An Issue:
Almost everyone suffers from this at one point or another. We just don’t recognize that the 10 minutes spent on figuring out XYZ, yesterday, is an issue. It may be that we don’t consider learning, spending time in a debugger while working on a feature, or figuring out a good design after having started with a design that didn’t work, to be an issue.
We may not recognize the pain and lost productivity because this is how we’ve always worked. We may not know that there is a better way. However, if we consistently run into the same issue, even if its masked by a different context, then there is an opportunity for improvement. For example, if a developer spends 30 minutes a day struggling with creating an NHibernate map that works correctly, but never reports it, we may never know that we are losing 2 1/2 hours per week. If, however, the person reports that time every day, we should notice the pattern of this issue and offer NHibernate training for the people that need it. We may also want to build an automated test that checks our NHibernate mappings against our object model and database schema, to give the entire team a repeatable way of proving that the mappings works. The point is, without the team recognizing the issue of time spent when there is a better way, we would not be able to improve our processes.
We can combat this cause by teaching ourselves and our team members to recognize the times that they are learning or researching vs the time that they are producing. That is not to say research and learning is bad. Quite the contrary – they are critical. It is to say, however, that we should track learning and research so we can recognize when we should provide formal or extended training.
Unwillingness To Report Issues:
There are many different factors that can lead to the unwillingness to report an issue. Sometimes our ego or pride get in the way – “I don’t need help.” Sometimes our fear of conflict gets in the way – “I don’t want to get into a fight about …” Many of the causes of this unwillingness can be symptoms of much larger issues in the team.
A person may not want to admit that they need help in some area of the system they are working on because they do not want to be seen as having any weakness. In cases like this, where there is an underlying absence of trust, the team likely has larger issues to work out before team members will be willing to report issues.
There is also a tendency for a project to move into “just get it done” mode. That is, the team members are tired of working on the project or have lapsed in their discipline on process and procedure, and are now tending toward cowboy coding techniques. In this situation, “issues” are never addressed appropriately because they are usually overlooked as minor obstacles. “We just need to hack away at the problem and get through it.”, or “We don’t have time to fix that. Just work around it.” These types of phrases are all too common in teams under tight deadlines and in high pressure situations. While there is a legitimate time and place for “we don’t have time”, this is not a decision for an individual person to make. Any issues that may need this type of decision should be brought up to the team so that the entire team can discuss and the appropriate business decisions can be made.
Worse yet – as Casey mentioned in the above conversation, the team members that consistently report “no issues” may be resigned to a fate of less than optimal performance, a “we can’t do anything about it” or “we’re doomed to failure” death-march attitude. This type of attitude and project culture is particularly difficult to fight. We have to find small victories on the items that we can directly influence, and monitor / track the effects of those that we can’t directly influence. We also have to find other ways of re-motivating the team. We need to find the teams sense of purpose and instill the notion of success – any success. It doesn’t matter if its big or small. Success makes people feel good about what they are doing.
When the death-march attitude is a direct result of external factors, we need to find ways to mitigate that external factor and then document it so it can be fixed properly. A single incident may not be noteworthy to the management structure. Documenting a trend of issues, though, and analyzing the cost associated with those trends – the things we do to mitigate the risk of delay, the changes we make to sub-optimize our process in order to account for the problems – can be a great way to effect change in an organization. It takes time to document the 2 or 3 hour delays that occur because another department is unresponsive or because the Foo-Server is out of Bar-Widgets, or whatever the situation is. Constant recognition and documentation of the issue is critical to fixing it.
Other Causes:
There are likely other causes of the “no issues” anti-pattern. For as many different people in as many different teams that do a daily stand up meeting, there are likely as many reasons for someone not to report any issues. It may be laziness or a false sense of security and productivity. It may be that the person simply doesn’t remember the issues they ran into yesterday – a sort of “meta-issue”: “my issue is that I can’t remember the issues I ran into yesterday.” Whatever the cause is, it must be identified and the team must be willing to state their issues.
Correcting The Pattern
If a team is simply not able to recognize a problem, take the time to train them appropriately. Help the team recognize the items that take time away from real productivity.
If they are having trouble remembering what problems they faced, get a stack of note cards and put them next to their keyboards. Have them write the issues down as they come across them. Then at the end of the day, or before the next stand up meeting, they can cross off the items that aren’t actually issues and report the real issues to the team.
Try this: every time you spend 10 minutes or more learning something – hitting up the blogs or Google for an answer, reading a help file, etc – write it down on a note card. At the end of a week, add up all of the time that you spent on these ‘non-blocking’ issues. How many hours were spent learning or working through “trivial” issues? There is likely a significant benefit in reporting these minor items in that we can help the next person avoid the same learning curves and issues.
Try this: change the rules of your daily stand up so that “no issues” is not an acceptable answer. We did this on my current project about 6 months ago and it helped tremendously. When we helped people recognize at least one issue every day, it became more natural for them to find their own list of issues. This simple rule that we put in place was a tremendous help in finding the root causes of our team’s productivity issues.
If a team is having foundational issues, though, like an absence of trust or the feeling of a death-march, then there are more foundational efforts that must be taken. The team will need to build a sense of trust, first. This is a major undertaking in itself. After that, creating a culture of collective ownership and working to eliminate ego and personal pride will help give people the freedom of bringing up issues. Then the team can get back to training themselves on how to recognize the issues they are having.
Whatever the cause is, it is highly recommended that a team work on a formal or informal process of improvement. Include documentation of the current issues, fixes that are being undertaken, and the current standards that a group follows as a result. Once a team is able to trust each other and openly admit that they run into issues and need help, then the team can begin to see a wealth of new opportunities for improvements. Each of the improvements put in place helps to build the team’s sense of unity, and drives productivity.
Conclusion
While some of the causes of the “not issues” anti-pattern are innocent enough – a team member simply not recognizing that something is an issue, for example – there are plenty of potential causes that are more insidious. Some of the reasons that people report “no issues” have a much deeper, foundational element in the team dynamics and capabilities. Whether the cause is a significant issue that underlies the entire team’s capability of being productive, or is simply a matter of pointing out the issue, the causes do need to be addressed. The teams that we work in must be able to recognize the issues that prevent them from being as productive as they could be. We must all learn to see the waste in our system so that we can eliminate it. If we are honest with ourselves and our team, we will almost always be able to state at least one issue during our stand ups.