Organizations whose needs or interests in agile grow beyond one or two teams giving it a try, who are newly embracing agile transformation, or are attempting to scale their agile adoption will benefit from the role of the agile coach. Agile coaches bridge various roles in agile. They take a strategic and long-term view and will work across multiple agile teams and projects to help organizations using agile to get the most benefit from this work.
Agile coaches help the teams, scrum masters/agile project managers, product owners, and executives and other leaders in agile environments all understand and execute their roles. In addition to team and project success, agile coaches are also focused on enabling long-term change so that organizations can successfully implement their chosen agile framework and see tangible and sustainable benefits.
Agile coaches work with specific people and roles to help them better understand the role and identify opportunities to improve their performance in that role. Agile coaches will work with teams, observing their processes and communications in order to identify and share opportunities for team improvements. Agile coaches may provide just-in-time training, helping new teams leverage the basic agile or Scrum training they may have had by providing more applicable insight and situational examples to add dimension to this training.
Organizations that are implementing agile at scale will create a cohort of agile coaches to assist their agile teams. Typically, these coaches will not only have significant experience and training in one or more agile frameworks, but they will also have experience and training with one or more of the approaches to scaling agile, such as Large-Scale Scrum (LeSS), Scaled Agile Framework (SAFe), or Scrum@Scale.
Agile coaching is something I personally have done a lot of, but not always intentionally. When I joined CloudCraze in early 2012, the nascent product development team knew enough about agile and Scrum to be dangerous and to aspire to using it effectively but had a mix of training and references. In addition to acting as a scrum master, I became the default agile coach for the whole organization. As I transitioned to leadership of our implementation delivery organization, I found myself coaching not only our teams but also customer teams in use of agile practices on our joint projects.
As a professor and trainer, I’ve provided coaching examples in classes and coached agile practitioners in exploring ways to handle challenges encountered in new and maturing agile organizations. As an executive leader, I’ve coached scrum masters, project managers, middle managers, and peers, helping them assess and address a variety of challenges and situations in various settings. Having done all of this, I have helped a lot, learned a lot, and above all, know that there are better and more experienced practitioners than me whose entire focus is agile coaching.
There are excellent books dedicated completely to agile coaching. The two that are on my bookshelf are Agile Coaching by Rachel Davies and Liz Sedley and Coaching Agile Teams by Lyssa Adkins. For truly in-depth and insightful reading beyond what my practical experience and examples can offer you here, I point you to these wonderful books by truly amazing agile coaches.
That said, I’ll share here some practical experiences and tips that illustrate some coaching techniques and how coaching can be effective at various points in a project or in a team’s development.
Coaching New Teams – Sink or Swim
Imagine being handed a new project and project team with no agile training or experience and being told “by the way, senior leadership knows that you are an experienced agile practitioner and trainer and wants you to lead the team and the project using agile practices.” This is the situation I faced a couple of years ago while consulting for a large health insurance company that was figuring out that its usual ways of running projects were not always appropriate or successful.
I asked for a four-week “sprint zero” to develop a backlog and provide the team with some basic training in agile – they gave me two weeks, with about 2–3 hours total allocated to bare-bones familiarization with agile concepts and terminology. After pushing back and describing how the four-week planning and training timeframe would be a good investment, eventually I bent to my client’s will.
The comparison I make to this situation is coaching a swim team that had little or no formal swimming training. The team plunged into their first swim meet and started a race without the benefit of formal swimming instruction. The team jumped into the deep end, began thrashing, and the only goal was to swim a lap and make it to the other side. Once there, the team caught its breath, assessed what it would take to swim another lap, and dove back in. In these early laps, style and technique mattered far less than striving to complete a segment and keep from sinking.
In a situation like this, as the team executes each sprint, experienced practitioners must be mindful of the need not only to coach to improve the team’s immediate execution, but also to keep long-term maturity growth in mind. This means that the senior practitioners must be aligned on organizational goals for proficiency and maturity in agile frameworks as well as in overall project delivery. It is also important to be alert for team members with an interest and aptitude to take on scrum master and product owner roles.
User stories – Teaching a common format and consistently reinforcing the purpose of user stories
Definition of done – Reinforcing a rigorous definition of done to ensure the team embraces value delivery each sprint and avoidance of technical debt
Improved estimating using relative sizing – Encouraging the team to review and improve their assessment of user stories and their velocity to create more reliable estimates for every sprint
Commitment and accountability – Creating and reinforcing the expectation that the team makes a realistic commitment for each sprint and then holds themselves and each other accountable for delivering
Efficient meetings – Coaching so that the stand-ups, backlog grooming, and sprint planning meetings becoming progressively more efficient and effective
Impediments – Coaching the team in quickly identifying and acting to remove or overcome impediments during a sprint
Candid and transparent metrics and retrospectives – Facilitating and expecting transparency, accountability, and respectful feedback during sprint reviews so that the team is focused on continuous improvements in a safe yet demanding environment
Agile coaching with desired end states in mind through a logical maturity progression will help the team deliver continuous value as well as continuous improvement. Deliberate and intentional guidance from skilled agile coaches and team members will help the rookies progress through the thrashing stages and quickly learn to perform with both power and style.
A First Release and Sprint Planning Scenario
I was asked to coach an agile project team within an organization for whom I had done some agile training. They had an enthusiastic scrum master, a dedicated project team, and engaged product owners – a great foundation. They were attempting to plan their first release and early sprints and sought some coaching to help them.
The vision – What needs to be built, and how it will provide value to customers and the organization.
A product owner – Someone with the knowledge and passion to own the vision and to provide information and direction to ensure the team builds with that vision and value in mind.
A team – A dedicated cross-functional team to deliver this project.
A backlog – Work with the product owner to create a wish list of the capabilities needed to provide the desired value.
Refine the backlog into user stories – The team and subject matter experts used their training to turn the wish list into user stories.
Prioritization – The team worked with the product owner to prioritize the backlog and user stories.
Decision on sprint length – The team determines the length of their sprints: no longer than four weeks.
Rough idea of how many sprints – The team and the organization develop a rough idea (subject to ongoing refinement) of how many sprints might be necessary, or that they are willing to invest in the release, to achieve the desired outcome and value.
Coming on the heels of a multiday investment in agile training, this seemed like a lot of work to the functional managers who had not participated, but it was a critical investment necessary to ensure the first release to be delivered using agile provided value to their organization. This first sprint set the team up for success, and the first release would set the tone for successful agile transformation and use of agile on future projects.
Step 1 – Prioritize the backlog of user stories using the MoSCoW rules (Must Have, Should Have, Could Have, Wish/Won’t Have).
Step 2 – Use t-shirt sizing to size the user stories; keep it simple: use XS–XL.
Step 3 – Organize the user stories into sprints based on the team’s gut feel and initial understanding of the project.
Step 4 – Overlay a numeric scale to the t-shirt scale (1, 2, 3, 5, 7, 9, 11, 15, 21, or similar), and then update the user story sizing, replacing the t-shirt scale with the numeric scale.
Step 5 – Estimate initial velocity. How many points of work does the team think they can complete in their first sprint? This is a total guess for new teams and will fluctuate in the early sprints.
Step 6 – For Sprint 1, identify the tasks required for each user story and estimate these in hours.
Step 7 – Develop a solid plan for Sprint 1, a soft plan for Sprint 2: it will be revised based on the team’s experience in their first sprint.
Completing these seven steps in collaboration with an experienced agile coach (in this case, me) enabled the team to exit their first release and sprint planning session with an initial release plan as well as a solid plan for their first sprint. This in turn positioned that team for a successful opening sprint, which delivered value to the organization and earned credibility for the team and the initial use of agile practices.
Coaching During Sprints
Coaching teams in their daily stand-ups and their normal work routines is like coaching a sports team during an event. The opportunities to coach come at breaks in the action and coaching must be offered without disrupting the flow of the game. In some instances, the coach may have the opportunity to take a player aside and offer tips prior to sending them back into the game. In rare instances, the coach may call a time-out to address a specific issue or reset the team if they’ve gotten away from the game plan.
New teams may benefit from reminders that agile thrives on team collaboration and commitment. One issue I have encountered is the tendency of teams and individuals to focus on individual assignments rather than treat the work as commonly owned by the entire team. In agile, “my tasks versus your tasks” is the wrong way to think. Teams used to getting task assignments and then focusing on “their” work will, without successful coaching to get past this, not adopt agile ways of working.
It is worth noting now that the behavior described here is less likely to occur if the organization itself has moved away from individual reward (i.e., individual bonuses and other performance-based variable compensation) and moved toward team-focused incentives. Because agile works best with team accountability and commitment, it follows that any incentives reward the team to think about “our work” versus “my work.”
Coaching in Sprint Reviews
Sprint reviews are excellent opportunities to observe and to coach agile teams. The coach sees the work product from the sprint, hears feedback from the product owner and other stakeholders, and sees and hears the team’s own assessment of how things went. Much like a coach evaluating a team’s performance after a game and working with key team members to identify specific items to focus on for the next game, the agile coach works with the scrum master/agile PM and product owner to identify specific things to improve on for the next sprint. Remember –plan-do-check-act.
The team member whose update to the team every stand-up is “worked on bugs, working on bugs, no impediments.”
The update given by a team member for the last three stand-ups indicates that they are impeded somehow, but they have not indicated this or asked for help.
The team provides standard updates but is not problem-solving or collaborating on impediments or making sprint commitments.
Coaching at Releases
If coaching at sprint reviews is like coaching after each game, then releases are like coaching a team at the end of a season. The release retrospective and release planning provide opportunities to help a team evaluate their performance over an extended period of time. Review of the sprint retrospectives and any incremental improvements the team made throughout the release cycle will help to build a picture of the team’s learnings, progress, and improvement. This will also reveal items the team may have identified but either failed to address or were beyond the team’s power to address.
In the breaks between releases, the agile coach can also identify, recommend, and help deliver specific training that could help the team and the organization as a whole improve and grow its adoption and implementation of agile. We did this at CloudCraze – in 2016, I added an experienced agile coach and scrum master to the development organization. In our subsequent onsite gatherings as we wrapped one release and started up the next, we assessed the outcomes from the sprint retrospectives during the release as well as our assessment of the overall process improvements needed and geared specific training sessions to these needs.
Summary
These examples have shown you how an agile coach can work in different scenarios with a team to help them become more effective. The agile coach helps teams and organizations improve their use of agile and the value that they get from the practices and the projects they deliver by doing so.
The next chapter begins Part 3 of the book: advanced topics in agile. Chapter 10 discusses design thinking. Design thinking is an approach to product development that helps the practitioner really understand the customer and what problem they’re trying to solve. Design thinking takes that understanding of the customers’ perspective and uses rapid prototyping to gain feedback before reaching a decision on what product to develop. Design thinking with agile helps the project team and the organization work closely with customers and rapidly determine the best product to build using agile.