Healthy value streams in software engineering
Photo by Jopwell (Pexels)

Healthy value streams in software engineering

This article is also available (and more nicely formatted) on Medium

A healthy software engineering team is aware of the “why” and “who” of what they do. They should spend a lot of time understanding their stakeholders at both ends of the value chain.

No alt text provided for this image

Unfortunately, software engineers often don’t know the business initiatives driving prioritisation. They can also often lack an awareness of how software is being received. This produces a phenomenon I call the?Anaemic Value Stream.

Software teams abstracted away from business decision making can exhibit several telltale symptoms. These include building the wrong thing, problems with throughput, and motivation problems. To avoid this, software engineering teams usually need to stay close to strategy and sales.

No alt text provided for this image

Teams abstracted away from their customers, or from their live environments, do too. Testing tends to suffer — leading to bloated or broken test suites. And, fragments of the user experience (UI, API or platform) start to undermine the product.

No alt text provided for this image

At Armakuni, our AK Insights product helps teams to identify areas for self-improvement. As part of the Insights process, we do a Stakeholder Mapping exercise. We identify stakeholders (internal and external) and consider communication styles.

Reactions can be heated! We have had engineers robustly debate the merits of this exercise. Is this information relevant to an engineer? Isn’t this the delivery manager’s job? Don’t UXD worry about users?

But, factory line style software engineering is a past we’re moving beyond. The vast majority of us are more successful when we include the human dimension in what we do. The idea of the technological savant communing exclusively with their code is largely fantasy.

Modern software companies are shortening the value chain. Both strategy and users need to be part of the engineering process.

It’s been popular in recent years to pooh-pooh Agile. I still find it amazingly relevant. It was originally a simple focus on doing things better.

Two of the four key statements from the Agile Manifesto emphasise the need for a joined up value stream.?Customer collaboration over contract negotiation?requires us to keep the user close.?Responding to change over following a plan?means constant, close contact with strategic, sales and delivery concerns.

Product Management practices often deviate from (or evolve beyond) agile theory. However, product specialists have a key role to play in?enabling?product teams. Whether “Agile” or not, understanding the problem being solved is a key part of engineering.

Stephen McFall

Senior Manager Solutions Architecture at Deloitte

2 年

We'd call it domain driven design.

要查看或添加评论,请登录

社区洞察

其他会员也浏览了