Agility for old dogs - Smart/tasking Optimisers

I am not sure why, but I’m always equally surprised and disappointed when I hear delivery methodologies being pitted against one another as if they’re so diametrically opposed and mutually exclusive that die hard camps are formed and projects fail for avoidable reasons. In this article, I describe how we helped two teams to bridge the divide, and what we learned along the way.

A few years ago, I ran a software development project which had been declared “Agile”. There would be two sprint teams, each complete with their full complement of ceremonies and people with appropriate coaching experience to keep things on the rails. So far so good…

The Indian application team was amazing. Jira was humming with issues and stories, code reviews were collaborative, the backlog was well-groomed and refined, and retros were active affairs and the show and tells drew crowds that Taylor Swift would be proud of. The sky was blue, the birds were singing, and the application was iteratively growing at a great velocity.

But trouble was brewing in the European infrastructure team. Jira was impenetrable, stories were untestable, and progress was, well, nonexistent. Team members were drifting in and out of focus like a dream sequence in a student film and a DevOps nirvana seemed like a distant ambition. They insisted they didn’t need tickets to manage their work, they just needed to be left alone to do what they had to do. But the fact was, they didn’t really know what they had to do. They didn’t know what each person in the team was working on, and releases led to the inevitable “well-it-worked-in-my-environment” tale of woe.

So… How did we get it back on track? In a word; coaching.

We didn’t have time to send the team away on a training course or overwhelm them with documentation. Instead, we worked with each person very closely to help write the tickets, groom the backlog, estimate effort, run effective standups and basically work as a scrum team. The intensive coaching happened for one sprint (2 weeks in this instance) and subsequent sprints reverted to normal levels of coaching.

I wouldn’t say it was easy, but it was impactful. There were high levels of resistance in the team to changing their ways. They were each highly regarded, well-qualified and seasoned professionals. But they were stuck in their ways; mostly used to being individual contributors and consultants. However, they quickly got to understand what they were doing as individuals and in the project’s context. Their contribution started to yield results and they learned how to plan and deliver infrastructure iteratively.

So, what techniques did we use to help?

Individual coaching; working on a 1:1 basis generally means a more fluid and open discussion.

Hands on assistance with unfamiliar tasks; “let me show you” can go a long way to help embed new ways of working.

Patience; sometimes it can take a while for new methods to land, be kind and remember we all learned this stuff once.

Persistence; don’t give up, if you’re doing it for the right reasons, it’ll pay off.

Acknowledgement and appreciation of successes: I’ve never met anyone who doesn’t like a pat on the back once in a while, even better if there’s a specific success attached.

Clarity of purpose; know why you’re doing something, understand the benefits.

Avoid jargon; endless acronyms and corporate lingo is a real barrier to adopting new ways of working, don’t assume anything you’re saying is “standard”; invariably, it’s not.

And what did we learn?

There’s always more than one way… but when team has decided to work in a particular way then things generally go more smoothly when everyone signs up

Respect the experience… remember that there are two sides to a coin. An expert brings experience and knowledge to a project, but diversity needs to complement, rather than derail, the project.