Using Sprints for Agile Coaching

[article]
Summary:
Discussing the work to be done as a group, building in short iterations, getting feedback, and looking for ways to improve are not just practices for development teams—it is an effective way to achieve any goal. Here, Ben Kopel details his experience of working with other agile coaches in a sprint to hire a new ScrumMaster.

I recently stepped into a new role where I am now responsible for moving high-level, organization-wide initiatives forward. At the same time, I was trying to increase engagement within the Agile Practices group of agile coaches and ScrumMasters. I wasn’t sure of the best way to get the work done, but I had an idea: Why not use the same agile process we ask our development teams to use?

We could form a team, create a backlog, estimate how much work we could get done in a sprint, do the work, show off the work, get feedback, and then talk about how we could improve. It wasn’t exactly an original idea, but I thought it could be an interesting approach.

I started by identifying the first area of focus, which turned out to be improving the ScrumMaster hiring process. After learning more about the current process and discussing with others, it seemed like clarity could be added around expectations while making the new process more experiential and focusing on involving the right people.

I was looking to form a team to make this process better, and fortunately, four agile coaches with very different styles said they would be interested in helping. Three of them confirmed that they would be able to put in some effort over the next two weeks, although we ended up changing the sprint length to one week. 

Regarding the sprint length, we discussed and decided that because this was a side project, a shorter sprint length would help us focus and not procrastinate. For all of us, this was not our primary responsibility, but we agreed that we could spend time working on it. “After all,” someone said, “hiring is the most important decision we can make.”

Acting as the product owner, I wrote user stories about getting a shared understanding between product and engineering expectations, minimum requirements for potential candidates, various hands-on exercises, and several others. After adding acceptance criteria, I shared the stories with the agile coaches team for review before our first sprint planning meeting.

In sprint planning, we reviewed the stories, discussed them, edited and added to them, reprioritized, and wrote new stories. The feedback from the other coaches was extremely helpful, and the stories and backlog were in better shape because of it. Collaborating to get a shared understanding of the work was beneficial, and the conversations we had gave us a whole new perspective on what we were trying to achieve. Each person brought a unique view for what they thought was important and what could be done to get the most value out of the interview process.

Next, we estimated how many stories we thought we could complete, then discussed how we would get the work done. Even though we weren’t coding anything or dealing with legacy systems, we knew that unforeseen obstacles would come up, so we took that into account. Considering there were four team members and the work was relatively new to all of us, we decided to pair on our stories throughout the week.

During the week, each pair found a couple of times to collaborate and work through their stories. It was fun and energizing to bounce ideas off each other and consider new ways to approach problems, while knowing that we were creating a structure that would benefit all of us in the long run. Having great coworkers would benefit our Agile Practices group, our teams, and the organization, so keeping that in mind was motivation to focus on being creative but also pragmatic.

Near the end of the week we got back together and showed each other what we had accomplished. There was some feedback and discussion, and everyone was happy with the progress that was made. We updated the backlog to reflect the feedback and found that some of the stories were no longer relevant, so we removed them. Shortly after, we reconvened to have a quick retrospective, where we discussed some insights into how we could improve the process. We noted a couple of action items and even changed a story in the backlog based on the retrospective discussion.

We still had some work to do, so the following week we met to refine the stories. We continued the process until we were happy with the new ScrumMaster hiring process.

Overall, the agile coaches group thought it was a nice way to organize the work that was being done, keep people focused, and deliver value. It also gave us an appreciation for the way we encourage our teams to work. Discussing the work to be done as a group, building in short iterations, getting feedback, and looking for ways to improve are not just practices for development teams—it is an effective way to achieve any goal. 

We followed through with improving the process, and eventually we hired a talented ScrumMaster. That person has done a great job of supporting their teams and contributing to the larger Agile Practices group. We even had a retrospective about the new process that they experienced and discovered even more ways to improve.

The learning never ends, so of course, we continue to iterate.

User Comments

2 comments
new
Kathy Iberle's picture

Hi Ben.  Good story!  I've used agile practices for years to manage improvement projects.  Time-boxed sprints are a good fit when several people's work needs to be integrated together before proceeding further or there is a tendency to bite off too much at once.  Kanban or continuous-flow is a better fit if there isn't much integration needed but there is a tendency to stop working on the project midstream.  Most of my process improvement projects have been Kanban-style with standups about 3x/week.  I think this minimizes the management overhead.

I found it interesting that you found pairing was productive in developing hiring processes.  It's surprising how often pairing is a good idea!

November 10, 2017 - 7:59pm
new
Ben Kopel's picture

Thanks for leaving your perspective Kathy, and thanks for reading.

November 12, 2017 - 2:38pm

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.