With my current role, I am working with a number of teams transforming the way they work. Only a small part of this journey is technical, but I still wanted to document this journey for reference in the future. In this first post, I’ll be talking about the first session with a team looking at transforming to agile working.
- Posts in this series:
Start with why
First of all, I want to reference material that even though I know it and understand it well (due to the number of times I have watched it), I still refer back to it. This is the TED talk from Simon Sinek, How great leaders inspire action. I’m a big fan of Simon’s, watched numerous videos of his talks, read his books and followed his articles online. I completely buy into the theory he lays out in the video I’ve linked and use this in day to day life, I’ve used it to help build teams, deliver training and architect new products.
The concept is basically to begin addressing the why you are doing something, then how and what. The messaging and examples are clear and will resonate with everyone. It’s simple, articulate why before anything else.
For that reason, when I run an agile workshop with a colleague recently, which was the first introduction to agile for this team who are based in our operations team, that is exactly what we did, we started with explaining, why agile, how agile and then what.
Introduction to agile
It’s a common misconception that operations teams cannot operate in an agile manner, it’s my opinion and my experience that this is simply not true. In later posts you will see why and how we can address some of the common concerns of operations teams who are working to agile methods. We start by asking three simple questions, each attendee has a stack of Post-It notes (other sticky notes are also available):
- Why is it worth doing?
- How is it difficult?
- What is agile?
Each attendee is then given around five minutes to write down answers and put them up under the appropriate heading. Then we head to a discussion with the team, we talk about the notes they have written down and try and get an open conversation going. When appropriate either of us running the workshop can then use our experience in this field to provide examples to back up or counter the discussion.
We also invited someone from a team which is already on an agile transformation. I did some work with another team internally who were similar in many ways to our operational team in that demand on them was from a number of different parties, they had difficulty closing work down after development and an element of their work was ticket based. For this reason, we asked for someone from the other team to come in and join the discussion. This worked well for a few reasons, mainly because the team we were delivering the workshop to had someone from another team who is going through this transformation and can attest to the things we were saying. Mostly, that above all, this really works.
Planning to transform
The plan to transform the team comes in three steps. Individually the steps are small but together they form the journey.
- Introduce daily standups
- Introduce work management such as stories and start introducing Scrumban
- Introduce planning, sprints and retrospectives
During the initial workshop, we held the teams first ever standup. Even if you are not on an agile journey with your team or organisation, I would highly recommend that you at start doing daily standups with your team. The concept of the daily standup is aimed at answering three things:
- What did I work on yesterday?
- What am I working on today?
- What issues are blocking me?
In sport a huddle is strategic, keeping everyone informed and connected throughout the game. For technology teams, the standup is a huddle, it’s designed to enforce the “we” and “one team” culture and mentality. Highlighting issues to the team often results in someone else in the team helping unblock them. Your standup should be no longer than 15 minutes, don’t go into minute detail of your day, keep it high level, keep it relevant. Highlight issues but don’t discuss them in detail.
I attended the second daily standup this team ran on Tuesday 21st January, they only started the day before, it took around 5 minutes to complete, everyone kept it simple, everyone highlighted what they worked on and what they are working on, a couple of blockers were discussed at a high level and agreement was taken to move the conversation offline. So from a session the week before, in less than 30 minutes of meeting time, this team are already in sync.
For our operations team, we are running the daily standups for two weeks, before having a check in with the team to see how it’s going. Between then and now I will be introducing the tooling we use internally, which for us is Azure DevOps. I will be introducing the tooling, key concepts of adding work to backlogs and starting to introduce the idea of working on a Kanban board. Check back in the future for more posts on the agile journey of this team.
The key message here is when speaking to a team about agile, no matter what their experience, always start with why you are doing it. People have worked in different ways for most of their career, don’t expect people to drop it overnight, explain why agile, how they will do it and what makes it exciting.