Have you ever been asked “how does the impact of an Agile Coach change as the team matures”? In an attempt to explore this question I will describe my experience as an Agile Coach working with one team for 2 years. I will examine how my impact within that team changed during that time, working through various maturity phases, and my attempt to find ways to measure my impact.
6 months: The Basics
In the first 6 months of working together with the development team, we did a lot of learning and finding out how we all wanted to work together as a group. We had an initial team kick-off where we discussed roles and responsibilities and learned more about each other as a group, and aligned on what our mission was as a team.
After the kick-off we ran your typical scrum process:
- We had stand-ups
- Visualized work on the board
- Utilized retrospectives for continuous improvement
- Held sprint planning, and backlog refinements.
During this time the team was able to build on these basic principles and practices and began to deliver business value iteratively. We were completing sprints and had a consistent velocity. I then had to determine what our next stage of maturity was.
Metrics used:
- We measured velocity and stories completed each sprint to help with planning. Were they consistent? Or improving?
1 year: Reducing waste & time to delivery
After the first 6 months, I introduced the team to kanban and lean principles (flow, WIP limits, and eliminating bottlenecks). As we applied these practices and solidified our Agile process, the team was also amping up their agile development practices, they were practicing continuous delivery, using XP practices (pair programming, code reviews). Now the challenge was to find ways to optimize our processes by reducing waste and decreasing time to delivery.
By observing and listening to the team, a theme emerged of wanting to simplify our release process and diminish knowledge silos within the team. I paired with an engineer on the team and ran an exercise mapping out the flow of our development and deployment pipeline.
- How does a feature go from start to finish?
- What environments does it pass through?
- Where do we see the most bottlenecks?
We took a look at this flow and started to identify areas where we can eliminate waste and remove steps not needed in our development process. We were able to identify we did not need an environment before our staging and were able to remove it. This in turn reduced waste by reducing environments the team members had to manage.
Metrics used:
- Deployment time and deployment downtime. Did these decrease? => Yes
- Throughput, did it increase, stay predictable? => Yes and no, as you can see from the graph it generally increased, but due to team size changes (members leaving), throughput changed over time.
- Cycle time (days from beginning work on ticket to production). => Decreased
1.5 years: Planning iterative development of larger projects
As the team matured in their performance, my day to day impact was slightly diminishing. The team was able to run standups, find ways to break down complex features to deliver value first, and drive projects on their own. It was now my next challenge to see how I could adapt my style to fit for a more mature team.
It was around this time the team was tasked with the job to develop a new customer facing application. This posed a new challenge to us, as the team was primarily a backend team for internal tooling. With this new challenge we had to plan out how to build a whole new public facing application, something we didn’t do often. In true agile fashion, we wanted to find the first slice we could deliver to our customer to get feedback early and also to meet a legal compliance deadline.
I worked with the Product Owner (PO) to think of how best to present the concept for the new application to the team. Using my knowledge of facilitation and group dynamics we paired together to plan a story mapping exercise. We ran a story mapping exercise where the PO presented the workflow of the basic user functionality needed for the first version using a physical board with sticky notes.
The team and PO discussed what they thought would be needed for basic functionality and were able to determine a first version which could be delivered by the deadline.
Metrics used:
Deadline for first version release. Did we reach our goal? Were users able to sign up with our service by Dec. 31st? => Yes
Did team members have more of an understanding of what we were going to build after the meeting? => Yes
2.0+ years: Promoting Agile Culture within the team and company
The most impact I have had on my team and my organization is through promoting and creating a culture of agile. The examples above provide specific activities that I have performed to instill and practice these values. As the team matured and did not rely on me much in the day to day ceremonies it allowed me to work on more organizational initiatives such as…
- Promoting the agile community through guild meetings /meetups and blog posts
- Kicking off new teams and coaching them
- Planning and facilitating larger plannings and workshops for different areas of the business
- Teaching agile to new business units
Summary
Reflecting back on my past 2.5 years with one team is a great way to showcase how the impact of a coach changes as a team matures. As in my experience, ensuring the scrum ceremonies are most effective may be where you focus most of your time, but as the team matures, you will find other areas to make a difference. Through working with the team day to day and listening and observing to the team, you will be able to understand how you can be most impactful and what changes are needed to do so.
How has your experience with teams changed over your team’s life cycle? How have you measured your impact in the different phases? How have you matured as a coach over the course of working with a team? We would love to hear from you in the comments below.
Image Credits: “The 8 Preferred Stances of a Scrum Master” from My Journey as a Scrum Master by Barry Overeem