7 Principles for Improving Software Delivery
As a large global consultancy firm, UST focuses on helping companies innovate and improve technology delivery, and much of its work grew out of DevOps practices. While working with clients, the company regularly grapples with questions such as how to reduce time to market while improving code quality and engineers’ engagement.
Eugene Sazhin, head of engineering, digital agility platform and solutions at UST Global, often found himself thinking, “There should be an overarching set of principles that we can formulate, adhere to and recommend our customers also adhere to in order for them to achieve better results in their transformational journeys.”
This is exactly what UST’s recently published Delivery Improvement Framework aims to do.
7 Principles for Improving Software Delivery
The framework combines ideas derived from lean, agile and DevOps, as well as Conway’s Law, Team Topologies, DORA and UST’s own experience. It consists of seven core principles:
- Flow is king.
- Positivity fuels flow.
- Team Topologies orchestrate the flow.
- Key performance indicators (KPIs) guide, not govern.
- Lean principles drive optimization.
- Navigate Conway’s Law purposefully.
- Value trust over performance and desire to learn over expertise.
The concept of “flow” is a big part of the framework, and UST is using flow in the lean/organizational sense, rather than to refer to individual developer flow state (although the two concepts are closely related). In defining “flow,” UST writes:
“Drawing inspiration from lean principles, we prioritize optimizing the entire value stream, not just isolated pieces. We eliminate waste, minimize context switching and build a system where development work flows seamlessly from conception to delivery.”
The overall framework is employee-focused. The second principle, “positivity fuels flow,” talks about work-life balance, autonomy, recognition, personal growth and learning. Engaged and happy employees are more productive, but another factor is that a successful organizational transformation requires everyone involved to be on board, from the senior leadership to the employees on the ground. I’ve described elsewhere how three of the five organizational transformations I’ve been involved in didn’t work as intended. In each case, lack of leadership buy-in or focus was a major contributing factor to the failure.
Articulating Your Core Principles
UST’s logic for publishing its Delivery Improvement Framework draws on Simon Sinek’s idea that if you publicly articulate your core principles, other people will be encouraged to join you. By making the framework public, the consulting group is also inviting a conversation, which should enable them to iterate and improve the framework. Fast feedback loops are essential in any learning organization.
Sazhin also says publishing the framework helps the company’s consulting business. He says that if a UST customer “understands where we are coming from when we are tackling a problem with a transformation, then we can connect and work together, and we have a greater chance of success.” Conversely, if the client doesn’t agree to the principles, then “we have a core disconnect and it simply isn’t going to work.”
If a company claims a set of core values but no one pays much attention to them, they are meaningless. “If you are committed to the core values in the framework,” Sazhin told The New Stack, “that means you’re evaluating all your actions and ideas against those core values and should filter out the ones that don’t align. For example, if you’re committing to a core value of positivity, then your communication with the employees should follow that. You shouldn’t allow HR to issue a communication with threats in it; to do so would be to break one of the core principles you are claiming to adhere to, and you’ll lose trust. Recovering lost trust is extremely hard.”
The Difficult Question of Developer Productivity
In an organization, trust flows from the top. It is also disconcertingly easy to lose; not exhibiting the values you espouse is one way, but others include large-scale layoffs when a company is profitable or linking performance reviews to easily gameable statistics.
I suspect nearly everyone has been asked to implement something they strongly believe won’t work. As a responsible partner, you sometimes have to push back — even if you’re a consulting firm that relies on making clients happy. For example, UST customers frequently ask for a way to measure developer productivity and incorporate that into their flow. However, Sazhin said, “In most companies, developer productivity has been widely misunderstood and misused.”
McKinsey was heavily criticized for its article on measuring developer productivity. But the underlying attitude still prevails: programming is reducible to typing, so productivity equates to Git commits, lines of code, bugs fixed or another meaningless statistic. The reality is that typing isn’t the difficult bit of programming, and, as Sazhin pointed out, “None of these things are pertinent to the business goals of the team.”
For example, a senior engineer who spends her time helping the more junior members of the team solve their problems is likely doing the best thing possible to improve team performance. But none of that will be visible if her performance reviews are based on her Git commit stats.
The desire to measure developers this way comes from a desire to micromanage team members and individuals, according to Sazhin. It grows from lack of trust in a team’s ability to self-organize. But that thinking is not in line with UST’s core principles. Instead, leaders should let the teams figure out if anyone is not pulling their weight, make it safe for the teams to express their concerns and help this person improve (or make more drastic changes).
Experimenting and Avoiding Magical Thinking
Rather than micromanaging, Sazhin argues, managers need to be “making sure that the team understands what the goals are, removing the impediments, then measure whether what the team is delivering meets those business goals.” This is reflected in the fourth principle in the framework, “KPIs guide, not govern.”
This matters because the tech industry is prone to magical thinking. If nothing hits production without the approval of a change control board that meets only twice a year, no amount of microservices will make IT move any faster. But plenty of organizations seem to think it will.
Likewise, “companies say they want to be agile,” Sazhin said, “but then they adopt SAFe [Scaled Agile Framework], and that is baffling to me. It means they completely misunderstand what agile is about. You can implement SAFe for years without any results — and you can claim this is because you didn’t implement SAFe correctly, but it isn’t.”
As agile consultant Dan North put it “SAFe’s stated business model is ‘a provider of the framework, platform, professional training content and certifications.’ There is nothing about customer success, nothing about accountability, nothing about whether the framework even works.” It all feels a long way from the Agile Manifesto’s mission of “uncovering better ways of developing software.”
Despite this, the industry has made progress, particularly when it comes to reducing time to value, or how to advance an idea quickly to test it with customers.
Enterprises including Amazon, Google, Intuit and Netflix run thousands of experiments every year. “I encourage [Amazon’s] employees to go down blind alleys and experiment,” Jeff Bezos has said. “We’ve tried to create tools to reduce the cost of experiments so that we can do more of them. If you can increase the number of experiments from a hundred to a thousand, you dramatically increase the number of innovations you produce.”
You also need to make it safe for experimenters to fail, since the vast amount of experiments won’t do what you hope. This, in turn, means employees need autonomy with strong trust and psychological safety at the core. To avoid monocultural thinking, a company needs diverse hiring, and flexible remote work plays a significant role by increasing the diversity of the available talent pool.
What This Means for Accelerating Software Delivery
Software delivery, in particular, needs small, autonomous, cross-functional teams building independently deployable units of software. Typically, this implies microservices or Function as a Service (FaaS), like AWS Lambda. Releases to production need to occur as often as needed, with a low failure rate — and a fast recovery time from any deployment failures. We’ve known this for two decades or more: the DORA Accelerate research, expertly led by Nicole Forsgren, even provides benchmarks.
Sazhin emphasizes the importance of validating your ideas and the progress you are making so that any decisions are made based on data rather than instinct. “You need to specify a hypothesis, gather the data as best as you can, then use a scientific approach to improve,” he said. “There is a common thinking pattern that some things are too hard or impossible to measure, so gathering data for scientific analysis is too hard or not feasible at all. This cannot be farther from the truth.” He recommends the book How to Measure Anything: Finding the Value of Intangibles in Business, by Douglas W. Hubbard, which showcases how to accomplish this with the help of calibrated estimation, statistical analysis and simulations.
Finally, Sazhin suggests having a network of influential people who support your work. “If you don’t have them, you won’t get the cultural change you need for continuous improvement,” he said. “You need to grow the number of agents of change in your organization, people who are actively helping the teams in this journey. They should be completely aligned and committed, but most importantly they should be passionate about these changes.”
For more insight, download UST’s white paper Unleash developer flow: A framework for improving enterprise software delivery.
