In a previous article, we explored the concept of daily coaching sessions and compared them to daily scrum. In this article, I would like to deep dive into the intricacies of the coaching sessions to hopefully give you some ideas on how you can strengthen the quality culture in your team.
Let’s do a quick recap on some of the points mentioned already:
- Coaching is clear feedback to your teammates on what they are doing right and what they are doing wrong
- Involve yourself deeply to provide specific coaching. Understand the work in great detail.
- Good coaching sessions start and end with a discussion about goals
- Coaching sessions should make true impediments visible so you can combat them in the early stage. Way before they start causing damage to the project (via time, cost or scope)
In the book The New One Minute Manager by Ken Blanchard, there are three specific techniques (so-called “secrets”) that the main character learns about. He learns this during interviews with the employees of the most successful company division which is managed by a great manager (called “One Minute Manager”). The manager seems to be both people and result oriented (not one or the other) and people love working with him as he is consistent in his behavior. The three secrets mentioned in the book are about one-minute goals, one-minute praisings, and one-minute redirects (more affirmative word than the dreaded word “feedback” or in some companies “negative feedback”). He uses the secrets to direct, motivate, and engage his people to the company’s goals and they take care of the rest.
Although it is questionable if one minute is really enough time to have a meaningful deep level discussion with your teammate on technical or user story level, all of the secrets are applicable to agile coaching and sit well with agile practices in my view. I believe you should start with a 15-minute timebox and focus on doing the coaching session right rather than fast.
Here are the 5 steps to nail down your coaching sessions:
- Ask a single driving question that will set the main theme of the meeting (1 minute)
- Review goals from the previous day (3 minutes)
- Capture and resolve impediments (5 minutes)
- Give praise/feedback (3 minutes)
- Agree on goals for the day (3 minutes)
What is a good question that will drive your coaching?
You need to define what is the single biggest challenge your team is facing. Is it that they are delivering poor quality code that ends up being returned from the test multiple times due to bugs before it is approved? Or we are building the wrong thing and our Product Owner is always unimpressed? Or even perhaps it might be the right thing but we don’t send it out enough every sprint? All three? We already spoke about the quality of delivery. Always focus first on fixing your quality before you put focus on your velocity issues. Bad quality always ends up causing more damage to you and your customer.
With your goal in mind, define a question that will drive your coaching sessions. It needs to be specific and set the tone of the meeting (in terms of what is important to us as a team, what is the part of the work where you want your teammate to put extra attention, etc.). It will also not let you drift away into some general discussions. One example of a good driving question is: “How does the code you committed yesterday contribute to the quality of increment?”
How to set goals in an agile context?
I have mentioned in my previous post that I was never able to make Sprint Goals really work. There are simply too many different user stories and different kinds of business value we are delivering that phrasing it in a single simple goal would almost always lead to some kind of artificial high-level statement that usually would translate to the same thing, every time – “let’s deliver everything we committed to in the sprint planning”.
From another point of view, we could say that every user story is a goal on its own. It represents a feature and by definition it:
- has a specific user acceptance criteria,
- is valuable to the business, and
- has a list of stakeholders who care about that goal.
This is true from stakeholder’s or business’s point of view. When you look at it outside the team, it appears as finely granulated work. They represent features stakeholders need in order to achieve their marketing, operational, or other kinds of tactical or strategic business goals. However, from a developer’s point of view, it might still be way too vague. It is because a single user story usually requires the work from different people in the team (think developers, designers, QAs, POs, etc.) in particular order where anything can happen from the day you start until the day you deliver it to production. Obviously every user story has a level of risk associated with it and usually risk correlates with the user story size, as you can see in the graphic below.
This is a convenient visualization of the standard sizing technique using relative story points. I borrowed it from another article. A story point represents the effort to deliver a user story (according to the standard definition), and it consists of three aspects:
- The amount of work to do
- The complexity of the work
- Any risk or uncertainty in doing the work
How to deliver set goals through daily coaching?
Now regardless of how big a certain user story is, the way to deliver them is always the same and it consists of various actions (order may differ) like: write some code, analyze internal code structure, analyze dependencies, debug, write test scenarios, execute test scenarios, report bugs, deploy, update documentation, etc. We need a correct list of actions and the correct sequence of actions defined to deliver a story. These actions represent your daily goals and the sequence of actions you are going to take is your delivery plan. Let’s take a look at one specific user story from the graph and see how it could be broken down into goals and a single plan.
We noticed that in the first refinement meeting we were able to estimate the feature to be 3 story points, although we still were not aware of what exactly we would need to do. However, due to our previous experience and comparison with similar features we had already built, we are able to rely on relative estimation. At this point, the risk is still high as we did not dive into the details yet.
What is the right level of detail?
In an iterative approach, we should go a bit deeper to understand some specific details about the feature. Look for stuff such as weird validations or test scenarios. This is a collaborative effort, but usually, some developers spend more time in one story, some in another. As we finished our analysis we hopefully were able to generate more questions. Questions that should reveal more details on specific aspects we did not think about earlier.
As we go further down, we start answering questions and every answer is usually translated into a new goal we need to achieve. We might also find things we were not aware of at the beginning which might change the whole way how we perceived the complexity or effort for a story. These are the purple boxes, impediments, which actually can pose a more serious threat to the delivery of a story. As we become aware of the risk, we should be communicating and addressing it immediately.
We should stop when we are comfortable with the work that needs to be done. The first output will be a list of daily (or shorter) goals we should accomplish. Then we define the order of goals in our second output, which is a delivery plan. Finally, assign people and get it done.
Notice that goals might be related to a specific task at hand. But may also be a bit looser, to encourage teamwork and synergy when needed. Also, a single person can have goals that are related to two different features on the same day. As long as goals are specific and measurable, we have the capability to zoom in detail. However, we can also zoom out on the bigger picture (feature or sprint level). With both perspectives, we see perfectly how everything fits together from the scope or time aspect of the project.
Now your teammate has a clear target and a predictable environment to work in. And he/she understands what is expected and how success looks like. Go through it daily and repeat until the feature is done. And then move to the next feature. Is it ever this smooth in reality?
“I am blocked, I have an impediment”
Of course, impediments might happen even after thorough analysis, although less likely. This is because of the nature of software development. All the implications of complex abstract structures and relationships might not be fully comprehensible. Not before you really write the code and test it out yourself. This is what being agile is all about, reacting, and adapting to new circumstances.
Firstly, you need to figure out what is the true impediment you have on your hands. You always want to target the real root cause. This way you spend your time and energy into solving the right cause for today’s problem but possibly many other problems that would appear in the future. During the meeting, you need to solve the impediment if possible, or take some actions after with appropriate people (you both should agree on the course of action) and solve it latest by tomorrow’s coaching session.
You need to approach the impediment directly and solve it immediately by applying one of the resolution strategies. I will write more about this in one of the coming articles where I will explore the topic in depth.
Besides daily coaching, what else can I do for my team?
Doing daily coaching is one aspect of your work and it is to primarily generate insights about your team’s challenges. But you also need to make tactical decisions or actions that will solve your team’s identified challenges. Don’t skip this step. This is the adaptation part and without it, there is no continuous improvement cycle. After your daily sessions, you should think about how to use the information you heard. Then you need to transform it into a few key actions you will focus on today. Start with the toughest challenge and list key actions you need to take it to resolve it.
We covered two essential aspects of coaching: driving questions and goal setting. Next time we will explore in greater depth the practice of frequent praise and feedback and impediment resolution strategies. What are your thoughts on the described goal setting technique?