Does WIP really tell you the story? Agile process woes

The infamous coach

Be honest. Do you really need an agile coach? I’ve been a part of two organisations where I’ve worked closely with an agile coach. In the first company it was for a short period of time but I learned a lot from those coaches, especially about breaking work into sizeable chunks but more importantly about sticking to the process. I was so happy when one day my favourite agile coach, Terry, bluntly told someone to stop rambling during a standup update - “what are you working, on what will you work on, any blockers? why are you going into all this detail?” he said.

In my next organisation I worked with an agile coach full time who was embedded into our team. I’d say it made us very reliant on that person to run ceremonies and help to resolve blockers. As soon as that agile coach took some leave from work, everyone stumbled through following the processes we had been following for months. The role of a coach, in my opinion, should be to help the team embed those rituals so we come to the realisation of their benefit for ourselves.

Process, process, process

The salient theme is: process. We don’t follow agile processes just because we should follow them. We don’t have standups just because it’s another meeting. We have standups because it’s important to inform your team mates what’s going on. You do not miss standup because you have a clash. You always attend standup. Period.

I actually faced a strange problem recently with regards to the process of tracking work in progress. On this particular day, I had planned to work on refactoring an existing codebase, followed by a grooming session with the project team I was working with at the time. I updated my team with exactly those details. A different developer, let’s call him Bob, was going to continue his work in migrating one of the legacy systems and he updated the team with exactly those details. Towards the end of the day I finished what I mentioned, so I started picking up some ‘foundational work’ (basically some improvements to our internal libraries). It took me a few minutes to raise my first pull request, only to have Bob ping me on Slack and tell me he had just done the same piece of ‘foundational work’ and he was testing it locally. We were both at fault here - we both started the story that was in the backlog and we didn’t move it to ‘in progress’, hence we were working on the same thing at the same time without each other knowing…

Who’s to blame? I think both of us. But really it exposes communication gaps where the process isn’t followed. We both acted lazily and its the team that suffers in lost time. We could have easily paired on the task together and we would have had a way better time. In my opinion, it is courteous to your team mates to at least share that you’re about to start something when it was unplanned. In my a previous organisation I worked with, we didn’t even begin a story without a ‘kick off’ meeting with an optional invite to everyone in the team.

But, but I just want to get shit done

Process feels like a drag sometimes. You might be thinking “but why should I move it to ‘in progress’ straight away when I could have just moved it during tomorrow’s standup, then it’d be obvious to everyone, who else would possibly pick up the story in the meantime because hey no one mentioned anything about it earlier”. True that may be, most of the time, but it’s the other times where this prevails and the process breaks down.

As much as I want the role of an Agile Coach to help in these scenarios, there’s not much more that they can say, perhaps, except to guide you in the already-existing process or invent new ways of working. I would really like to see examples of breakdowns in the process more from coaches, to show the implications of not following it well.

I guess we often run out of time to do agile scenario analysis when there’s a whole bunch of work to be done. I do wonder sometimes if developers generally see process as a hinderance in delivering their code. The code is where they want to be, not in Jira… As a self-confessed productivity freak I want to track tasks; I want the process. I like process. Process helps me learn and process helps me be productive outside of work. Process helped me never avoid exam failure during university and I’m proud of it. Even though it feels almost un-Australian to not be lazy, it seems to prevail across our industry.

What can we learn from all this?

Agile processes help to automate productivity between team members. It’s not a core agile principle but I think it’s a byproduct of the way we work as an agile team. If there’s a process in place then we should follow it and learn why it’s there. Don’t fall into the trap I did where someone else started on the same thing I was working on just because neither one of us knew the other one had started it until the last minute. Communication is a bigger problem than any technology problem and I can now first-hand relate to why we have such processes in place. Laziness is not a virtue.