- Resisting the Urge to Provide Unsolicited Expertise
- Handling Explicit Requests for Expertise
- Sharing the “Minimum Viable” Amount of Expertise
- We All Have Blind Spots
- Applying a Coaching Mindset to Teaching
- Creating a Self-Serve Knowledge-Sharing Environment
- Guidelines for Sharing Feedback and Expertise
- Additional Considerations for Sharing Feedback and Expertise
- Receiving Feedback as a Coach
- Chapter Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
Applying a Coaching Mindset to Teaching
In our experience, teams that increase their Agility the fastest also have the most involvement in choosing how they work. The difficulty in supporting this approach is finding ways to impart knowledge while allowing the team to make their own choices. The Agile Manifesto does not dictate a specific way to align with its values and principles. One way to teach a team and yet allow them to choose how they will work is to separate the teaching from the choice of what to do.
To separate the two, teach the most common Agile practices with the explanation that “these are things you can do,” and then separately facilitate a session to help the team decide what they will do. For example, we were working with an organization that wanted to implement Scrum, with the exception of one team that said that while they did want to be more Agile, they didn’t think Scrum out of the box would work for them. The team was doing infrastructure work, such as rolling out new firewall rules, provisioning servers, and the like. There was no one performing the equivalent of the Product Owner role, and no one in the organization was looking to fill that role. Many organizations use Kanban for infrastructure teams.
Rather than suggest a particular framework or mash-up of techniques, we ran a workshop that taught the team the basics of Agile, Scrum, and Kanban and then enabled them to pick the practices that appealed to them. They ended up choosing the following practices:
T-shirt sizing
Visualizing their work with a simple card wall
Having the entire team act as the Product Owner
Using a backlog
Describing the work just as they had before
Choosing work-in-progress limits
Having a daily huddle to check progress
Triaging new work as it comes in
Deciding who was going to work on what as people completed their previous work
Having a retrospective every other week
We made it clear as part of the workshop that they should consider these practices as their starting point and refine their choices as they go, leveraging the retrospective to do so. Is that Scrum? Kanban? Scrumban? They didn’t care about giving it a name, and neither did we. They were very excited about what they had come up with as a team and moved forward with enthusiasm. Over the next few weeks, they significantly reduced their turnaround time and were happy with their custom-crafted “flavor” of Agile.
By using this approach, you give choice to the team and coach toward Agility, rather than choosing a specific Agile framework for the team and then teaching them that framework.