.NET Musings

We’ve all heard it in our personal relationships, whether it’s a partner, parent, or child.  You ask a question, and the dreaded answer comes – “Fine”.  What’s wrong with that answer, you ask?  It’s not the word.  It’s the deep ambiguity behind it.  What I have learned in 15 years of marriage is that there is always a story behind that simple word, and have learned how to probe to find it.

Think about this in your work environment.  One of the problems with the traditional (or waterfall) development methodology is a lack of continuous, structured communication.  Oh sure, there might be status reports (written or verbal), or periodic meetings, but what do you usually hear from the team members? “It’s fine.” This can continue on until the team gets closer to the release, then all of a sudden, problems start “appearing” where before everything was just “fine”.

How can this happen?  Why didn’t the team just bring up their impediments or issues when they appeared, instead of waiting until the last minute?  Were they hiding them?  Not likely.  People aren’t generally deceitful.  More likely, they were overly optimistic.  Sure, they had issues. But there was plenty of time in the schedule to make up for them, right?  It’s easier to just report “Fine” than to raise the alarm and draw attention to your self.

Typically, if a coworker tells you everything is fine, you just accept it and move on.  It’s in our personal relationships that we’ve learned the subtleties of that word.  We don’t typically have the type of relationship with our coworkers that would cause us to question someone who declares that everything is “fine”.  But what if things aren’t really fine, but your coworker still reports their status as fine?

It’s happens all too often – team members are going through a drop in productivity (for a variety of reasons), yet they don’t report it.  Those issues might be blocking bugs, overly optimistic estimates, or simply a lack of experience.  They might not think the issues are a big deal, or they maybe afraid to bring them up to the team for fear of repercussions or embarrassment.  Maybe they have some personal items that are interfering with their productivity that they want to keep personal.

In development, we call this “Going Dark”.

How does a team expose when one or more developers go dark? You might say that communication is the key. Only by increasing communication amongst the team can we get a better understanding of the pulse of the project. However, if a developer doesn’t want to come forward with their issues, having a standup isn’t going to fix that problem.

Then burn down charts are surely the answer!  As I’ve always said, before you can fix anything, you have to expose it and measure it.  That is true, but just injecting standups and burn down charts into your development process alone doesn’t necessarily surface when developers go dark.  Take the burn down chart shown in Figure 1.  There is definitely a problem with the project, and it’s been going on for several days.  But what is the problem?  It’s impossible to tell.  Maybe in the standup, the team has been stating what is holding them back. Then again, maybe not.  If they are still reporting that nothing is holding them back (“Everything is fine”), then it’s a classic case of developers (maybe the whole team) going dark.

Figure 1

If the problems aren’t being raised in the standups (or maybe your team isn’t holding daily standups), the only indicator of developers going dark is a drop in velocity.  Even worse, if the problems aren’t caught early enough, they can lead to missed deadlines and cost overruns. If your team is working in sprints and using burn down charts (and more importantly, keeping them up to date and accurate), the problem becomes apparent before the deadline is missed.  The scrum master/project manager knows to dig into the project to see what’s going on.  But where to start?  Do you spend the time and energy probing every team member? Do you have the resources for that?

What we need are personal burn down charts so the scrum master/project management can quickly see who’s gone dark, and not have to spend the time trying to interpret whether “Fine” means “Fine” or “I’m totally in the weeds here!” Something like the People Status screen shown in Figure 2 would help to take all of the guesswork out the equation and simple show that three of the team members have “gone dark”. Red lines indicate nothing being produced. Not completing any tasks on a single day might not be that bad (it all depends on how your team sizes tasks), but several days in a row certainly indicates a problem.

Figure 2

We need to keep advancing our transparency if we want to keep advancing our teams.  The more low-friction tools we have at our disposal the better we can manage all aspects of our projects.  Communication is hard.  If it was easy, we would all be doing it so much better, and we would need to incorporate processes into our lives to facilitate it.

Remember – Fine isn’t always fine.  If you ask someone how their day is, and they answer “Fine”, and you truly care how their day is, you need to dig deeper.  But when their day really is “fine”, than digging deeper is a waste of precious time, and moreover, can lead to problems (like feelings of mistrust) between team members.

If someone asks you how things are going, don’t answer with “Fine”.  Tell them specifically.  “It’s going pretty well, we are still on track” or “We’ve hit some snags, but we will be able to make our deadlines” can both be distilled down to “Fine”.  After all, both groups will probably hit their mark and make their commitment, but the latter case would warrant some extra love from the project manager…

Happy Coding!