Stay up to date with enterprise technology trends
Get updates that impact your industry from our GigaOm Research Community
The widespread adoption of Agile, along with the rise of DevOps, means you’ll be forgiven for thinking software development is now an easy, stress-free process. But whenever I talk to developers in that field it’s not the experience they describe. Delayed deadlines, cumulative technical debt, and high workloads are all common struggles in the developer community.
This begs the question: if Agile is not the solution, what is it?
I spoke with Daniel Mostert, the infrastructure technology solutions director of a large tech services company, to tap into his experience with leading projects for large-scale applications and Help companies deal with difficulties in their development. We discussed the issues inherent in the development process, the possible Agile role in those processes, and the techniques managers can use to engage their teams and provide grant projects on time and on budget. Our chats gave four key lessons that Mostert says he has learned from his more than 30 years of development career.
1 / Break down the process
This is the key to improving any process, as Mostert explained to me, and its sheer simplicity means many managers forget to do it. But by breaking down the process and assessing the importance of each step to the overall goal, it helps to create priorities and increase focus within the team.
“I went through the entire functional, object-oriented, even scaling process,” Mostert said. “Basically it’s all the same: break the process down into smaller chunks and understand what you’re trying to do. That’s all it is, but we call it all different things. But in the end, that’s what it boils.
2 / One size doesn’t fit all
Mostert believes the Agile concept can be very active and effective in certain environments, but not others. More often than not, achieving higher productivity requires the use of innovative and different management processes and techniques.
“If you’re on a large project and you’re developing some very well defined functionality, I think there are a lot of reasons for the Agile approach,” he said. “If you are working in a mixed environment where you are doing some maintenance, some improvement, some development, then the question becomes, ‘What is the priority of the day?’ There can be multiple environments that can be set up and different approaches for each are different. But good leadership, I think, is still essential. ”
3 / Avoid Scheduling Pitfalls
This is an important part of many project management training courses: How to create schedules. However, Mostert said, this is often a fatal mistake from management – looking to control a top-down process, but with little knowledge of what the project is actually asking for and when. execution time.
He suggests working with the development team early to create preliminary timetables as they can provide better estimates of the expected completion date without setting rigid timelines.
“What’s absolutely ineffective is the narrative approach of the people who tell you: ‘This is the day. Here’s the plan and it’s time to get it done, ”Mostert says. “From the top, you cannot rate work and say, ‘This work will be done by this date’, because you cannot plan a software project from a schedule. That won’t work. How long does it take to write a program? How long will it take you to test? How long does it all take? There is a bit of Agile returning to that, where the team has to evaluate work and help with scheduling. “
4 / Creative structure, positive culture
Mostert is a proponent of tailoring processes and management styles to the current project, but he has a few “ways of playing” he recommends for specific issues. He likes to combine these plays with an active team culture where people buy into new structures and support each other to achieve different goals. But this approach could have downsides as well, Mostert warns.
One model that I find interesting is separating teams into “firemen” for error solving and “programmers” for functional development. Mostert says this impetus to create good functionality is crucial to avoid burdening a project or product with crippling technical debt.
“You have to structure the team so you have a team that can take all the nonsense about changing priorities and so on,” he said. “And then, you must have another part of the group that can function with the function you want to create.”
Mostert says the dangers of creating technical debt are never erased. Teams come up with a solution and plan to improve it later, and then never happens. Over time, Mostert said, “You end up with one or two people knowing what’s going on in that mess and they’re forever busy with firefighting. And you never get out of that reel ”.
The biggest challenge, according to Mostert? Keep the same group and culture as different members come and go. If one or two key members leave, he said, “then you are almost starting over”.
Mostert’s ideas impressed me, especially how they address the importance of flexibility in approaching a software development project. It’s an important quality for project managers, especially when operating at scale.
Agile processes have been very successful in facilitating a modern, efficient software development culture, but it is not applicable to all environments, as Mostert clearly states. His philosophy of adapting team structures and processes to the project gives project managers the autonomy to evaluate the tasks at hand, evaluate their summaries and teams, at the same time making creative decisions that may or may not be consistent with traditional Agile architecture. In the end, all that matters is that it works.