The particles, geometric art, line and dot of walking.

Beyond Agile: 4 Lessons to Better Software Development

The widespread adoption of Agile, coupled with the rise of DevOps, means you’d be forgiven for thinking software development is now an easy, stress-free process. But whenever I speak to developers in the field that’s not the experience they describe. Missed deadlines, accumulating technical debt, and high workloads are all common struggles in the developer community.

This begs the question: if Agile isn’t the solution, what is?

I spoke to Daniel Mostert, a director of infrastructure technology solutions with a large technology services company, to tap his experience leading projects for large-scale applications and helping companies address struggles in their development processes. We discussed the problems inherent in development, the role Agile can have in those processes, and the techniques managers can use to engage their teams and deliver projects on time and on budget. Our conversation produced four key lessons that Mostert says he has gleaned from his 30-year career in development.

1/ Break Down the Process

This is the key to improving any process, as Mostert explained to me, and the sheer simplicity of it means many managers forget to do it. But by breaking down a process, and evaluating each step’s importance to the overall goal, it helps create priorities and sharpen focus in the team.

“I came through the whole process of functional design, object orientation, even up to scale,” Mostert said. “It’s basically all the same: breaking the process into smaller pieces and understanding what you’re trying to do. That’s what it’s all about, but we call it all different things. But in the end, that’s what it boils down to.”

2/ One Size Does Not Fit All

Mostert believes the Agile concept can be very positive and productive in certain environments, but not others. Often, achieving higher productivity requires employing different and creative management techniques and processes.

“If you’re in a large project and you’re developing some functionality which is very clearly defined, I think there’s a lot of reasons for the Agile approach,” he said. “If you’re working in a hybrid environment where you’re doing some maintenance, some enhancements, some development, then the question becomes, ‘What is the priority of the day?’ There’s probably multiple environments that can be laid out, and different approaches for each of these different environments. But good leadership, I think, remains essential.”

3/ Avoid the Scheduling Trap

It’s a key part of many project management training courses: How to create a schedule. But, Mostert said, this is often a fatal mistake from management—looking to control a process from the top down, but with little knowledge of what the project actually requires and how long it’s going to take.

He suggested working with the development team early on to create rough timetables because they can provide better estimates of expected completion dates without setting rigid timescales.

“What’s absolutely not going to work is the story approach of people telling you: ‘This is the date. This is the plan and this is when you have to have it finished,’” Mostert said. “You can’t, from the top, assess the work and say, ‘This is going to be finished on this date,’ because you can’t plan a software project from a schedule. That’s just not going to work. How long does it take you to write a program? How long does it take you to test? How long does it all take? There’s a little bit of Agile coming back into that, that the team has got to assess the work and help with the scheduling.”

4/ Creative Structure, Positive Culture

Mostert is a proponent of adapting management styles and processes to the project at hand, but he has a few “plays” he recommends for specific problems. He likes to pair these plays with a positive team culture, where everyone buys into the new structure and supports each other to achieve various goals. But this approach can have its downsides too, Mostert warned.

One model I found intriguing was to separate teams into “firefighters” for addressing bugs and “heads down coders” for developing functionality. Mostert said this drive for creating good functionality is critical to avoid burdening the project or product with crippling technical debt.

“You have to structure the team so that you have one team that can pick up all this nonsense of changing priorities and things like that,” he said. “And then you have to have another part of the team that can just roll with the functionality that you want to create.”

Mostert said the danger comes from creating technical debt that never gets cleared. Teams lay down a solution and plan to refine it later, and then later never comes. Over time, Mostert said, “You end up with one or two people that know what’s going on in that mess and they are forever busy firefighting. And you never get out of that spin.”

The biggest challenge, according to Mostert? Keeping the team and the culture intact as different members roll in and out of the group. If one or two key members leave, he said, “then you almost start all over again.”

Conclusion

Mostert’s ideas struck a chord with me, especially the way they address the importance of flexibility in approaching a software development project. It’s a vital quality for project managers to possess, especially when operating at scale.

Agile processes have been very successful enabling the modern, efficient culture of software development, but it isn’t applicable to every environment, as Mostert so clearly expressed. His philosophy of changing processes and team structure to suit the project gives agency to project managers to assess the tasks in hand, evaluate their brief and team, and to make creative decisions that may or may not fit into a traditional Agile structure. In the end, all that matters is that it works.