A day in the life of an agile coach
Agile coaches and their assignments are diverse. Some work only with individual teams (I don’t), some equals “agile” with “Scrum” (I don’t). My goal is to help organisations become more fit for purpose, and be able to stay there in the face of continuous change. I’d also like employees to enjoy themselves at work, and to keep a sustainable pace.
So how does my day look?
08:00 I’m sipping my coffee and booting my laptop. The development team manager asks if I have five minutes for a quick chat. Since I know that means at least twenty minutes, I nod and grab my notebook and my coffee. We discuss how we recently discovered that several people are doing stuff that are not present on the Kanban boards. They are mostly working alone, and I suggest that they don’t see much value in the boards. They don’t have anyone to share their work or their progress with.
09:00 I’m in a retro between operations and a developer maintenance team. Operations are using Slack to communicate with the team, and use it to report incidents or problems in production. Operations are unhappy with the response time. I propose the following two overarching goals for the maintenance team:
People who submit tickets are satisfied with how their issue is resolved
Tickets are solved permanently, meaning the same problem does not occur again
Then I ask them what changes we need to do to the current process to achieve this. They have a good discussion, while I write down key points on the white board.
10:00 Standup with a three person development team next to their Kanban board. One of them is explaining a bug he is working on. I’m not actively participating in the meeting, but I notice that the bug isn’t present on the board. Towards the end, I comment on the missing bug. I mention a couple of tasks that appears to be in the wrong column compared to the status the team presented. I also ask about another issue that I heard about from sales before the meeting.
11:30 Lunch. We’re discussing threading problems. Thanks to my technical background I’m able to take part. I tell the ancient story of a caching mechanism I once wrote that were thread unsafe by design to be fast enough. A couple of the senior guys realise that I actually know what I’m talking about. It only took four months. Since I’ve learned a lot about the company history during that time, I respect their suspicion to “experts” who barge in and think they know everything.
12:00 I’m in a product forum meeting. We are discussing estimates and predictability. I mention that to have predictability, we need to have speed. Someone jokes that we’re predictably slow. We agree to reduce the scope of new requests, and that the development team should analyse the complexity when needed. At the same time I disagree that the result should be estimates. I explain that based on rough buckets (less than a week, more than a week, less than a month) we can provide an SLA indicating how long we will take to deliver. I’m surprised to find that everyone thinks that’s actually a good idea.
13:00 A developer complains to me that we have a problem sticking to whatever we agree to in meetings. I comment that perhaps not everyone did agree. “We can’t agree to everything! This democracy thing isn’t working!” he argues. I reply that there’s a difference between I disagree, and I won’t do it! and I disagree, but I am willing to try the alternative. Afterwards, I ask the team how we can reach the second state. How can we move forward without consensus? I explain how experimenting is a useful way of adjusting how we do things. I point out that this allows us to actually try what works, and the need to agree or disagree in advance fades away. A couple of the guys disagree.
14:00 I’m in a discussion with a couple of service managers and a guy from sales. After reviewing problems with a recent and complex customer, we realise that we’re missing a role in the department. Sales are handing customers over to a service team tasked with setting up the customers. But, with customers as large as this one the coordination efforts involved to ensure everything is set up are extensive. We need a person to coordinate between the team, sales and the customer. On top of that we often have several third parties involved in technical integration. If I hadn’t been so agile that I no longer believe in project managers, I would have suggested hiring one.
15:00 I’m on the bus on my way home. Got Slack open on my phone, discussing change management and how to be able to release quick enough. We have to submit a request for production changes almost two weeks in advance, but of course we want to release more often than that. I struggle with the fact that my role should be advisory more than operational, but agree to lead discussions with Central change management to find a solution. I plan to transfer this responsibility to the department change coordinator as soon as possible.
Wrapping up..
Looking back, what did I do? Definitely more than coaching. Most of it is nudging people in the right direction. Participating in and knowing about as much as possible of whatever is going on is crucial. The more information I have about the business, the better I understand each individual, the easier it is for me to suggest the right path forward in any given situation.
The tough part is to know when to replace suggestions with open questions. When to allow people to figure stuff out by themselves. As a coach it feels great to take credit for leading, but that’s not my job. So I try my best to stay quiet when the team agrees to do something that is obviously a detour.
The thing with the detour is that getting to where you need to go with a map you made yourself, is way more rewarding than just following someone else.
