Post

The three essential elements for successful software - people process and technology

The three essential elements for successful software - people process and technology

The drive for faster software development is everywhere, but all too often, it goes wrong. Broken software doesn’t just waste money; it creates frustration. In this blog, I want to explore three essential ingredients for successful software: people, process, and technology.

What I see time and again in organizations is that everyone wants to move faster. Software must be built quickly and pushed to production even quicker. As an impatient person myself, I understand that urge completely. But software errors are costly, our society lost an estimated €1.6 billion in 2014 alone. Many of these problems are highly complex and far from easy to fix. To truly improve software development, alignment between people, process, and technology is essential. Unfortunately, many organizations focus mainly on process and/or technology, often favoring process. Frameworks like Scrum or SAFe are rolled out to streamline production. But do they deliver on their promises? In my experience, things may improve for a while, but long-term progress often stalls. The organization as a whole doesn’t necessarily become more agile or faster.

Two sources of inspiration

One powerful, research-based inspiration is the book Accelerate and the DORA research behind it. Nicole Forsgren, Jez Humble, and Gene Kim identify (originally 24, now) 27 capabilities across three areas: technology, process, and culture. These capabilities drive both software improvement and organizational performance, highlighting once again the importance of aligning people, process, and technology.

Another eye-opener is [Leandro Herrero’s Viral Change}(https://www.google.nl/books/edition/Viral_Change/5yghwxEDpmUC){:target=”_blank”}, which makes it crystal clear that real change is about behavior. Every organization has two key performance drivers: the system and the behavior within it. The system is how things are organized—processes, teams, policies, agreements. Behavior is everything we do: how we communicate, how we collaborate, how we interact day to day. Behavior shapes culture. Herrero argues that systems account for about one-third of organizational success, while behavior determines the other two-thirds. In other words, people’s behavior is decisive!

People, process, and technology in balance

So how does this apply to development teams? The clearest example is the role of the Scrum Master. A poor Scrum Master focuses almost entirely on process. A mediocre Scrum Master goes a step further and also coaches the team on dynamics, behavior, and culture. A great Scrum Master brings technical knowledge as well, helping the team grow on all fronts.

That’s what I notice in the organizations I work with. Teams that treat Scrum as “just a process” often struggle. Teams that also pay attention to behavior, collaboration, and communication grow much faster. And the teams that improve across people, process, and technology really take off.

On the technical side, there’s huge potential for improvement too. Practices such as Continuous Integration & Deployment, Code Maintainability, Trunk-based Development, Loosely Coupled Architecture, and smart automation all contribute significantly to better outcomes.

I’m convinced that balancing people, process, and technology is the key to building better software. To make teams successful, these elements must reinforce each other. People come first for a reason: process and technology only succeed when people show the right behaviors. And behavior—though it’s the hardest thing to change—is ultimately the key to success.

So how does your team handle this? What do you focus on? How do you make behavior a deliberate part of your “inspect and adapt”? Do you consistently call out unhelpful behavior? And what kind of feedback do you give each other?

In future blogs, I’ll dive deeper into improvement within organizations—with a special focus on behavior, change, and learning.

This post is licensed under CC BY 4.0 by the author.