Managers: how to maintain effective technical discussions (Part II: setting up for success)
…in which some techniques are proposed for increasing the chances that valuable, technical, open discussions will occur.
The Series
Part I: the goals
Part II: setting up for success ←you are here
Part III: facilitating discussion
Part IV: how to help when it falls apart
Setting up for success
As you know, trying harder is rarely the solution to a people problem. In order to succeed, we need to change the process or the environment in a way that will make success easier.
In this part, I give some advice about how you can set up your team for success through mentoring, productive meetings, and fewer meetings.
Preparing proposals
Before I use the word “planning,” I should probably address the sad association that word has to the despised “waterfall” process.
I believe that “planning” and “design” are absolute necessities in any process that claims the titles “agile” or “lean.” Planning and design, if done well, help with sharing understanding, avoiding surprises, and result in more agile solutions. I have another article in the works on this topic so I’ll say no more about it now.
When it is time to plan a solution, you will have some engineers who like to come up with designs to solve problems. Channel that strength without alienating the rest of the team.
Prior to calling a meeting, ask the team to document (preferably) more than one proposed solution. They can divide or share this work however they like. Encourage engineers who have an idea for a solution to prepare diagrams describing the proposal. But be available for mentoring.
Mentoring on sequence diagrams
In a discussion of complex designs, it is easy for confusion to arise from the fact that different people are talking about different parts of the solution. Things get contentious only because folks are just talking about two different things.
A good sequence diagram is extremely valuable for facilitating discussion of complex designs. It allows all participants to point at an arrow in the diagram and focus the conversation on a particular call.
Sequence diagrams can be tedious to make. I highly recommend Lucidchart.
If the problem has more than one flow or starting point, then making more than one sequence diagram will usually have a better result than trying to fit all the cases into one diagram.
Mentoring on state/activity diagrams
State diagrams are especially useful in facilitating discussions about complex designs in which events can occur concurrently or when there is any uncertainty about whether you’ve covered all possible cases.
If done right, a state diagram will expose (and force you to consider)
- race conditions and
- missed cases.
It is imperative that it is clear what it is that is having its state described in the diagram.
I recommend that a state diagram have a legend of states and a legend of events (transitions).
The legend of states allows you to use abbreviations for the states in the diagram proper but still include a more verbose name and description of the states.
The legend of events is helpful — even for the author — to ensure that each event is covered for each state. It is that feature of a state diagram that helps us catch race conditions and missed situations.
Other diagrams
Class or entity diagrams might be easy enough to whiteboard during a synchronous meeting. However, if they are complex or non-obvious at all, it is good to get them documented in a lasting artifact.
What to look for in the diagrams
- Does it communicate? Communication is the goal. Don’t fret over whether the arrowhead and the dotted vs. solid lines are correct to some standard (though it’s nice if it is close). The important thing is: “does this diagram communicate?”
- Will it facilitate discussion? Is it legible and open enough for folks to point at something and focus discussion in a way that will be understood by all participants? Is it mutable so that annotations can be added or changes can be made?
- Does it describe a solution to the problem?
- Is it clear what part of the problem the diagram solves?
Remember that we can always add annotations to a diagram to clarify or expand on details.
Coming soon
Once the proposals are prepared, the team may want to discuss it. In the next part, we address the discussion itself and how we can make it valuable, technical, and open.
