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.


Post Footer automatically generated by Add Post Footer Plugin for wordpress.

About Derick Bailey

Derick Bailey is an entrepreneur, problem solver (and creator? :P ), software developer, screecaster, writer, blogger, speaker and technology leader in central Texas (north of Austin). He runs SignalLeaf.com - the amazingly awesome podcast audio hosting service that everyone should be using, and WatchMeCode.net where he throws down the JavaScript gauntlets to get you up to speed. He has been a professional software developer since the late 90's, and has been writing code since the late 80's. Find me on twitter: @derickbailey, @mutedsolutions, @backbonejsclass Find me on the web: SignalLeaf, WatchMeCode, Kendo UI blog, MarionetteJS, My Github profile, On Google+.
This entry was posted in Agile, Daily Standups, Education, Lean Systems, Management, Principles and Patterns, Retrospectives. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • http://www.lostechies.com/members/seanbiefeld/default.aspx Sean Biefeld

    I think it is a given that there will be issues, that’s what we do all day long, solve problems. Is it appropriate to state each and every minuscule issue, when it is not significantly impeding progress? If the team writes down each problem they encounter on a note card you are going to be wasting time.

    The only issues that I see worth bringing up in a stand up are those that are blocking forward movement, which require attention from the team. Unless it is one of those, I believe it is valid to say you don’t have any issues hindering the completion of a task.

    A stand up should not be the forum in which the team expresses their lessons learned from the previous day. They should be short and simple enough to give the team adequate information to determine where things are in the queue. Anything more detailed than that is waste.

  • http://www.lostechies.com/members/derick.bailey/default.aspx derick.bailey

    @sean

    so where do you draw the line? when do you know that you need to say “i’m having problems with NHIbernate mapping files” when you only spend an extra 15 or 20 minutes on them, a few times a day?

    there does come a point where writing down every single issue is a waste of time. however, defaulting to the stance of not writing down anything but the big issues is just as much (if not more) of a waste. until the team is fully capable of recognizing even the smallest of wastes on a regular basis, the team needs to be proactive about learning how to identify them. leaving a team with no ability identify and deal with the smaller issues will prevent them from being able to push their productivity past a very basic increase, once the “big” issues are dealt with.

    if your only focus in on the individual task, then you will never find the true optimizations that are possible when you look at the larger process as a whole. an individual “small” issue may not be worth mentioning, in the context of one or two tasks. but when that small issue is repeated hundreds of times, it adds up quickly.

    it is true that you need to identify and prioritize based on expected return – the issues with the most potential benefit in fixing them get done first. but don’t limit yourself to only looking for the big things or pretty soon you won’t be able to recognize that what was once a small thing is now the big thing.

    you’re right that the daily standups should be kept short and sweet. using this as an excuse to not identify issues, though, is an anti-pattern in itself. if a 6 person team has 2 minutes each during a stand up, and i am able to clearly express what i did, what i’m doing, and what these 5 issues are, in that 2 minutes – you better believe i’m going to. it would be irresponsible of me not to.

  • http://www.lostechies.com/members/seanbiefeld/default.aspx Sean Biefeld

    It seems you are advocating bringing up any problem that is solved in the stand up. If the problem is continuous/repetitious or preventing you from progressing, then by all means bring it up. If its an everyday problem of how do I design this to overcome said problem, then the stand up is not place for it.

    Follow the law of diminishing returns, not every problem that one overcomes is worth mentioning in a stand up. The stand up should be geared towards what the team wants to know about progress from a business standpoint. I’m not defining a specific line where you say what is valid or invalid because its context specific.

    I don’t think enforcing a specific number of issues should be required nor a specific amount of time per team member in a stand up.

    The stand up does not seem the appropriate forum to identify small wastes to me, that seems to be something you may want to tackle outside of the stand up. I do not believe project managers have time to listen to that level of detail, and it probably does not benefit them. Minute waste seems to be something that the tech lead and team should address outside of the stand up.

    I’m not advocating ignoring waste but when it is appropriate to identify and address waste.

    Overall it seems that the daily stand up is a daily executive summary for the leaders of a team. Anything that you would not include in an executive summary has no place in a stand up.

  • http://www.lostechies.com/members/bogardj/default.aspx bogardj

    It really depends on your goal. With new people, we’ll pair early and often, but eventually, we’ll “throw them in the water” to let them swim on their own. There’s a certain level of “learning through exploration” that I see as essential. It’s a fine balance between hand-holding, learning, and stumbling blindly.

    One piece I hate about blocking issues in a stand-up is, “Why are you waiting until _now_ to surface an issue?” Our stand-up doesn’t start the day, but I hate learning about new issues then, unless they just came up in the previous 15 minutes.

  • http://www.lostechies.com/members/derick.bailey/default.aspx derick.bailey

    @sean,

    “Overall it seems that the daily stand up is a daily executive summary for the leaders of a team. ”

    i think there’s a huge disconnect in what we put into and want to get out of the stand up, which is where our difference in opinions on this subject are coming from.

    i don’t see the daily standup as an executive summary for team leads. i see it as a team-member summary for team-members. it lets the team members know what the other people are working on, what issues they are facing, and where things are in the process of development. it gets us all on the same page, as a team, so that we can work more efficiently.

    if you see the stand up as a leadership tool and not something that benefits the team, then you should probably stop doing them. the leadership can get that information out of issue / work tracking systems and source control commits.

    the point of the stand up is to educate and facilitate the team members, first. the education of the leadership and executives is a secondary effect – albeit a valuable one.

  • Quincy

    Very informative Derick, thanks.

    I believe better time-management is essential for increased individual (and, subsequently, team) productivity. The best way to understand how you’re spending your time is to document and measure what you’re doing with your time. That will allow you to make adjustments to make better use of your time. Sure, you will increase your “workload” while you’re gathering data, but the end-result should be less time wasted. Similar to how lifting heavy weights actually causes (minor) damage to the muscles before the muscles get stronger. To continue the weight-lifting analogy, you may need a “trainer” (i.e., someone you trust and whose opinion you value) to identify issues that need to be addressed (e.g., “inhale on the lift, exhale on the release”, “two hours a day for research seems a bit high”, etc).

    So, even if all the issues aren’t worth bringing up before the team (as team/project issues), individuals can increase their productivity by documenting, measuring and removing as many of the “time-wasting” issues as possible.

  • http://www.lostechies.com/members/seanbiefeld/default.aspx Sean Biefeld

    @derick

    Maybe so, I have not seen any benefit from the stand ups I have participated in for the past few months. The only benefit for the team that I have seen is the surfacing of problems, which forces the team to tackle such problems, other than that it seems to be a waste of time.

  • Michael.Jones

    Rather than trying to educate a team to capture every issue, therefore creating the new issue of “I spent 2 hours recording issues”, does it make better sense to emphasize the capture of “major” issues? Those issues taking more than some agreed duration or frequently recurring issues, i.e. 10 min 5 times a day.

    Whereas the goal may be to drive out all extraneous time wasters, is an immediate shift to reporting all, a good implementation strategy? I would postulate that a staged approach would yield better immediate results.

    I view this as more of an eduational issue, educating team members to recognize issues and thereby creating a cultural bias towards identifying, reporting and addressing issues.

  • http://michaeladkins.blogspot.com/ Michael Adkins

    Your “No Issues” blog is closely related to a situation in the military structure that would always chap my hide. In the Army, each Company or Battery would have a morning formation and each Squad Leader/Section Chief would report his/her squad’s status to the Platoon Sergeant. Like clock-work, the Squad Leader/Section Chief would report, “All present and all accounted for.” I would question, (quietly of course) “well, which is it, are we all present or are we all accounted for?” So, I read the Army manual to find out how the daily reports should be performed. I found out the Squad Leader/Section chief is supposed to report like this: I have two soldiers on sick-call, one soldier on leave, and six soldiers on a mission to Grafenwoehr.

    After reading the Army manual, I finally worked up enough courage to let the leadership know about it and requested that the leadership follow the Army doctrine and start doing thing the Army way; not the traditional way that had been handed down incorrectly over the years. I won’t go into the Superior/Inferior schematics of the United States Military, but you get my point. It appears the same holds true for the daily standup.

    Just my two cents.

    ~AD

  • http://www.lostechies.com/members/derick.bailey/default.aspx derick.bailey

    @sean,

    sorry to hear that. i hope we can make the stand ups more valuable for your team, in the near future.

    @michael.jones,
    end-goal, i agree. we need to take care of the “big issues” first. but until the team is able to recognize the big AND small issues, and actually be able to quantify the difference, we need to capture everything. if you don’t know what a small issue is, how will you know what a big issue is?

    @michael adkins,
    excellent parrallel to the army! i can see how the same foundational issue you saw is present in what i was trying to address here.

  • michael.jones

    @derick.bailey
    Identifying any issue is a matter of training. If a person doesn’t understand what constitutes an issus, it must be pointed out to them. To simply insist on reporting all issues is not necessarily the best way to accomplish this goal.

    If the problem is that the individual doesn’t recognize issues, how will they be able to identify a small, seemingly insignificant one? Rather, as a training paradigm, does it not make better sense for leadership to instruct and the team to self-educate on what constitutes an issue? An in doing so, do not the larger and the recurring issues lend themselves more readily to identification and remediation?

  • http://www.lostechies.com/members/derick.bailey/default.aspx derick.bailey

    @michael.jones,

    training is the answer, yes. there are a lot of different approaches to this, as you and @jbogard pointed out. i think i could have stated this more clearly in the original post. good call from both of you.

    @quincy,

    great insight. monitoring/measurement is an absolute necessity for improvement. you can’t improve what you aren’t measuring.

  • http://devlicio.us/blogs/casey Casey

    A good approach here is to “enforce” an approach of:

    What I did yesterday
    What I am doing today
    Anything that is stopping me moving forwards

    This way, even if you don’t answer the last question with anything but “no issues” … other team members or the project managers should see patterns arising in you repeating the first two answers.

    Also, I have no problem with stand ups where people say “Yeah I can’t get X working, seems to be some bug in Y component” … this gives an opportunity for other team members to speak up if they can easily help. Don’t waste stand up time discussing in detail, but agree to take it offline right after the meeting.

  • http://blog.troytuttle.com Troy Tuttle

    The anti-pattern is assuming stand-up meetings must address a certain number of issues everyday. Truly mature teams get to a point where they resolve issues as they encounter them.

    If you don’t hear many issues during stand-up, and you observe the team during the day, and they still are not resolving issues, then you may have a point. But if you observe a team resolving their issues during the course of the day, then where is the problem? Because they didn’t turn the stand-up into a group therapy session? Software development isn’t social work. Well, some teams may seem like social work, but the healthy teams don’t need as much structure as immature teams.

    And besides, do you really want to take action on the software schedule when a guy picks his car up from the garage? You aren’t going to get anything done besides adjusting the schedule 8 times a day.

  • http://www.lostechies.com/members/derick.bailey/default.aspx derick.bailey

    @Troy Tuttle,

    “Truly mature teams get to a point where they resolve issues as they encounter them. ”

    so very true. perhaps the “no issues” anti-pattern is more applicable to an immature team, then.

    @All,

    The feedback on this has been tremendous – especially the counter-arguments and people pointing out the issues in what I’ve stated! There’s obviously some points that I completely missed in my original post, and I really do appreciate everyone’s input on this.