You have 1 article left to read this month before you need to register a free LeadDev.com account.
Don’t fix what’s not broken, as the age-old adage goes. Agile has been around for a long time, but is it the most reliable process that managers can turn to during these volatile times?
For the last two decades, engineering managers have leaned on agile methodologies to successfully deliver projects and run their teams. Despite its popularity, agile practices still raise questions, especially around how to employ agile methods effectively during times of change and, ever increasingly, if such an approach is even necessary for modern-day engineering teams.
To provide us with a little more context on agile processes ahead of his LeadDev Berlin talk on the topic, Ben Murray (BM), a senior engineering manager at Holland & Barrett, sat down with Scott Carey (SC).
The below conversation has been edited for clarity and brevity. Ben’s full talk will be delivered at LeadDev Berlin on December 6.
SC: What will you be speaking about at LeadDev Berlin?
BM: My talk tackles how teams organize the tasks they work on, how they might break those down, and then put them through whichever agile process they’re using.
Over the years, I’ve worked within engineering teams using different forms of agile, and I’ve led teams using different forms of agile. This talk will be about my experience of what has worked best for the teams I’ve been a part of and when these agile methods have allowed for the most productivity.
SC: What’s the biggest lesson you’ve learned about running agile teams, especially during the last few, quite disruptive, years?
BM: Although we’ve got frameworks that tell us how to do things, agile is all about flexing and adapting that process. In many ways, it’s like continuous improvement – perpetually changing structures in place.
Even if a team thinks they’re working well using one sort of approach, you’ll see that they still change what they’re doing from day to day. And that’s how they tend to be successful.
The other thing I’ve learned is that engineering teams are usually very good at being self-led, once they’re given the space to find what work cadence suits them best. With a little bit of guidance, most of the time, I think engineers tend to flourish in that sort of autonomous environment.
SC: How do you maintain that autonomy under pressure?
BM: In order for you to maintain your reports’ autonomy and also aptly answer questions from higher-ups about what is happening within your team and why they may not have done some things, your team members will need to be able to keep themselves in check. To achieve this, you need to trust the people that you work with and be able to hold each other accountable. I think that’s really what works best.
This approach may not always be seen further up or outside of a team. Those that you answer to may ask questions, but that’s where you, as a manager, need to be protecting the team.
SC: Do you feel that agile is fit for purpose in the modern-day enterprise?
BM: It really just falls to what works best. With agile, you adjust the process to meet both the business and the team’s needs. As a team you need to be able to answer questions on what you’re working on, what’s coming next, and the timeline on both those things. Because that’s always the big question: “When will this be done?” And it’s only really best answered once you’ve got the team working smoothly and in a consistent manner.
SC: What do you hope that people take away from your talk?
BM: I really hope to just start some conversations. This might mean that after my talk people will come to tell me I’m wrong, that there’s an alternate way of working, or simply asking questions. Conversely, maybe people will agree. But I think it’s healthy to challenge the status quo and come up with different or better ways of doing things.
Ultimately, I would like to share my experience and open the floor for others to discuss their own agile methods.
