A group of uniquely skilled individuals working towards a single goal forms a team. On a good team, every player is contributing and looking out for their fellow teammates. On development teams, I’ve found that paying attention to the things that cause rambling in meetings — that is speak about a topic for an extended period of time — gives a good insight into the parts of the team that are causing issues or will cause issues in the future.
…rambling when describing a feature
If your feature can’t be described simply, it’s a hint that the behavior is not well defined. Features are usually simple actions that mean something. Detailed information of what exactly displays in various cases are certainly important information, but are not needed for describing the basic behavior. If you find that it takes more than a simple sentence to describe your functionality, maybe it’s time to refactor your story.
…rambling when giving a development status
On the development side, if a developer is unable to explain their approach simply, that should be taken as a warning as well. I find this to be especially true when the developer is talking about their approach on a micro implementation level, for example, saying that you:
added a 12 pixel margin-left to the nested div of id classroom-name
rather than a more understandable description such as:
centered the classroom name on the page
If this is the case, your teammate may need someone to jump as a pair to help clarify and straighten out the development approach.
…rambling when estimating
If you spend a long time discussing the vision or the basic implementation when estimating a feature, it’s a sign that there’s more than the obvious involved in the feature. I take this as either a sign that the story needs to be rewritten, or that the estimate should be a bit higher. In my experience, this has been a fairly accurate tell, and a good way to anticipate stories that might have previously gone over estimate.
…rambling when discussing project practices
If you find yourself playing a primarily listener role in a 10-minute discussion with one or more of your teammates that revolves around one of your team practices such as code reviews, it’s a big clue that your teammate is feeling some uncertainty. It could be that the practice isn’t providing the value you think it is, or perhaps that your teammate doesn’t understand the value it provides. Rather than letting that uncertainty continue to build up, it is much more effective to address it by either refactoring the process or providing a clear explanation of how the process works and what value it provides to the project.
Conclusion
We talk a lot when we’re uncertain — it’s so natural that we don’t always realize we are doing it. But if we watch for it in ourselves and others, we can find and address causes of uncertainty in our project and reduce risks in our stories, teammates, and estimates.
What other kinds of subliminal messages do you use as warnings?