info@netfork.io

The Green STE B Dover, DE 19901, United States

Agile Coaching Scrum

How to replace your daily scrum with daily coaching?

Agile Coaching Scrum

How to replace your daily scrum with daily coaching?

Discussing progress of work

Have you ever attended a daily scrum that felt like a complete waste of your time? People discussing issues you do not fully understand, referencing parts of the system you are not familiar with, or discussing some random personal topic? And all that you have in your mind at that moment is that strange production bug you cannot seem to get resolved for several hours.

According to the definition: “the Daily Scrum is a 15-minute time-boxed event for the Development Team to synchronize activities and create a plan for the next 24 hours”. For an average-sized development team of 5 people plus Scrum Master, it means you are expected to invest 1.5 hours a day of team’s capacity or 3% of your entire 2-week sprint capacity (not counting the time lost due to people being late or not respecting the set timebox). This is a rather expensive sprint activity, hopefully, it achieves good value in return.

The value it promises is synchronization and plan for every 24 hours. There are plenty of tools that will help you visualize dependencies, impediments, and keep your team in sync using the Scrum Board. Even tools that will automate standups as a whole and save that time for other activities. And when it comes to a value of a 24-hour plan, as Dwight Eisenhower said, “planning is everything, the plan is nothing.” In a software development context, we make decisions on implementation, architecture, design, priority, and dependencies continuously and rapidly to safeguard quality of delivery. We make decisions carefully but then stick to them ferociously. This is our plan always, every day, every hour, every sprint.

planning is everything, the plan is nothing.

Dwight Eisenhower

Is there a better activity you could do instead to improve your quality of delivery? Yes there is, and it is daily coaching of each team member to improve their individual quality of delivery. Let’s first clarify what the quality of delivery stands for:

  1. Team is able to deliver fully working software. All features included in the product increment are “Done” done, meaning they are thoroughly tested and satisfy all functional and non-functional requirements (the “quality” aspect)
  2. Team is able to consistently deliver the sprint goal. All the features they committed on delivering during the sprint planning meeting are included in the product increment (the “productivity” aspect)

As a Scrum Master, schedule a coaching session each day with every team member individually for 15 minutes. Take the time to inspect the delivery of the team member and problems the developer is facing with the feature at hand. You need to define a single driving question for these meetings to be effective. A good driving question could be: How does your code ensure quality of increment? As a Scrum Master, use the driving question as a tool to coach what is the most important for your team.

In the coaching sessions, you want to be as specific as possible, down to the finest level of details. This is no high-level brainstorming session or exchange of ideas on industry trends or practices. You want to:

  • see the code he/she wrote to implement a certain feature he/she is working on. 
  • hear the end-to-end approach of how the feature will work in the developer’s mind. 
  • inspect the principles he/she is following in organizing functions, how variables are stored, named, initialized, etc. 
  • use the information you received to find coaching opportunities to help a developer improve professionally and ensure the quality of the product.
  • use the information you received to spot true impediments that may hurt your product increment in one way or the other

There are four important aspects you need to take care off every session to ensure success:

  1. Constantly reinforce the message “quality aspect is always more important than the velocity aspect”. That is what you first need to build in your newly formed team, no exceptions. Keep the driving question formulation the same until you see that the developer is well familiar with your expectations and has owned the definition of “Done” for your team standards. Only once the developer is building perfect quality you can start coaching on the velocity aspect.
  2. Let’s pause for a brief moment to align on what the essence of coaching is, at least in the context of this article. Coaching is clear feedback to your teammates on what they are doing right and what they are doing wrong. It has to be very specific and concrete, ideally on a code level (you see now why you have to be in detail to be an effective coach). Generic feedback like “we did a great job this sprint” or “you did a great job with that user story” is simply not effective, as people will not perceive it as genuine. It will inevitably become a “formality we need to take care of every sprint to be considered as a transparent team”. That is not transparency. Equally, bad coaching is observed in statements “you should be more focused on your task” or “you need to always think about scalability when you implement a feature like that”. We will explore this topic in more depth in another article.
  3. Now, the cherry on a cake benefit of such a meeting is that you and your teammate will begin to find true impediments way earlier in the process before they manifest themselves into actual problems or blockers that cost time and money. Being in this level of detail offers a much better inspection opportunity than asking a default, generic Scrum daily question to the whole team: Are there any impediments in your way?
  4. When you are in the developer’s shoes, you can also help your teammates set specific and ambitious daily goals that will stretch them as professionals but at the same time will help the project stay on track. In my experience, standard Sprint Goals never worked out for me quite well, they always seemed a bit artificial and too high level (in other words too obvious). Goals can be about specific improvements in code or progress you and your teammate think is achievable today or giving a hand with resolving some of the open impediments at the moment. Use goals to reflect on the previous day and don’t forget to acknowledge and praise achievements. There should be equal effort put into recognition and corrective feedback, as both are crucial to personal and team growth.

Let me give you a practical example. After we together inspected the code that the developer wrote yesterday we noticed an addition of complicated if statements. She explained that it was because of the changes required in the user story related to the mobile landing page. The Product Owner was requesting a particular logic on how the elements will be presented in mobile-based on user parameters. However, the change caused problems as the existing shared endpoint did not work anymore for the web app. We immediately contacted the Product Owner to see if this change request is worth the additional complexity and see if there is a way to simplify the logic. Turned out he was happy to remove the part of the logic that made it much more simple to implement, and code was quickly rewritten without any technical debt introduced. 

When would we find this impediment in scrum standup? Perhaps only in later stages of the sprint when we discuss why the story was delivered too late to be fully tested or in the retrospective when we discuss why our sprint caused regression bugs in the staging environment (in the web app part).

You may argue that a Scrum Master needs technical knowledge to apply coaching in a manner described here. Indeed, the person coaching needs to be able to understand the code, to see what is being built and how it is being built. In order to coach people to become better developers you need to be an expert in the field yourself. This could be a good opportunity for you as a Scrum Master to grow as well and understand better the quality of product your team is delivering. As a non-technical Scrum Master you always have the option to delegate the coaching to the most senior person in your team, but then agree with him/her on the process of coaching and what are the outcomes you want to see. And just watch and learn.

Let’s take a final look at both techniques and compare the differences:

Scrum Daily StandupScrum Daily Coaching
Team member time investment15 minutes each day15 minutes each day
Scrum Master (or Coach) time investment15 minutes each day15 minutes for each member each day
TransparencyWhat did you do yesterday?
What will you do today?
Automated status updates on who is doing what and scrum board
InspectionGeneral high-level question: Are there any impediments in your way?Specific low-level question: How does your code ensure the quality of increment?
AdaptationLog of action points to follow up on after daily standupDecisions being made now together with the developer to ensure the highest quality first.
Expected benefits for the time investmentSynchronize activities and create a plan for the next 24 hours (including solving of impediments)Spot and remove true impediments, continuously grow the expertise of your team, ensure every line of code is according to the definition of done