Agile in the Value Stream

Many organizations claim to be agile without ever having understood what makes a company agile. They bought an "Agile Transformation" - and think that afterwards, agility is achieved. What does this look like, why is it fake - and what is the difference?

Fake Agile

Let's take a look at a typical organization value stream for software delivery:

Being agile without customer contact never worked!

In the beginning, there's Marketing, Presales and Sales, all talking with the customer, discovering what the customer needs and is willing to pay for. Once a contract is signed, the project is planned, requirements are formulated, some code is written, tested and then deployed.  All straightforward.

When the organization realizes that customers aren't getting what they want and/or are getting it too late or expensive, managers are looking for a way out. Enter: "Agile", most notably: Scrum. Scrum uses terminology like "Development team", and since most people equate "Coding" and "Development", Scrum is being introduced as the miracle pill in the Coding stage of the value stream and the organization expects all problems to be solved.

Developers are still not in touch with customers, work off specifications and hand off bulk increments into testing, where then defects are discovered, reworked, launch is delayed - and nothing has improved.
Even though this form of "Agile" might improve the amount of work done by developers and slightly reduce the overhead of getting code finished, in the big picture, even a 100% effort reduction in Coding would still only reduce the overall effort of getting a project to "Done" by a mere 12%.
Since a 100% capacity increase in coding - which is a massive stretch for most organizations - performance is merely a 50% reduction in duration, it's almost impossible to achieve a statistically significant (thereby, visible) improvement in organizational performance across the value stream.

This kind of organization tends to be trimmed for efficiency, where each department tries to both maximize utilization and minimize their own cost.

Even if coders were absolutely perfect, worked in zero time and for free, the overall approach would still be staggeringly slow, ineffective and not satisfying to the customer. This is why such an approach to agility is fake.

Genuine agile delivery

An agile organization is most notably different in one aspect: The customer is at the heart of each activity. Not "fake customers" like sales who, although demanding something, are not those who actually will be using the product - but the real customers who are interested in using the product themselves:

Customer Centricity in everything we do

What makes things slow, unreliable and expensive are the handovers, where delay is introduced and information is lost. We need to drop organizational barriers and let everyone talk with the customer as needed. Departmental priorities need to be replaced by product priorities. Everyone needs to collaborate with each other and the customer in achieving one common goal: maximizing the value delivered while minimizing overall effort.

Coding is no longer the focus of being agile - not even IT as a whole. Indeed, the focus shifts away from activity to outcome. What matters to business success isn't that IT can get their job done, but that the customer gets what they need! Everything else will fall into place accordingly.

In this kind of organization, some things don't appear to be efficient. The same discussion may happen multiple times (which is still better than working against unfounded assumptions) and cost is fixed, irrespective of workload.
Agile organizations optimize for effectiveness, i.e., getting things Done in a way that pleases the customer.
This only makes sense from a system's perspective, not from a departmental perspective. Hence, it's important to include everyone in such a process. Any function not included will end up a bottleneck and could block the flow.

Fully agile enterprises

I omitted "Operation / Maintenance / Customer Service" functions in the above model, even though these are equally (and potentially more) important. This breaks down the final barriers beyond "Done", integrating practical experiences with the product into the feedback loop as well.
In the ultimate stage, every action is aligned with customer needs and every piece of learning harnessed for competitive advantage.

Conclusion

Contrary to popular belief, "being agile" isn't something limited to software development. It's a way of running an enterprise that revolutionizes how we think about value streams and value generation.

While the first hurdle in an agile transition is often rewiring the brains of developers to move away from meeting requirements to understanding customers, it by far isn't the biggest. The biggest hurdle is breaking out of a limited IT setting - and opening the doors for the collaboration of all departments for one common goal: business success.