Updated: Updated: Transformation
This is Part 3 of my mini-series on Agile delivery. Feel free to start with Part 1.
Several years ago I posted on LinkedIn about the misconceptions that enterprises have about software development. It was the beginning of me digging into organizations making assumptions based on their past experience or success, but which no longer hold true. Because breaking such assumptions is critical to bring organizational change, The Software Architect Elevator includes a whole chapter on the topic called Reverse-engineering Organizations.
Because such assumptions aren’t written down in a guideline or motivational poster, they usually come to light during conversations. Since we are talking about Agile in this series, let’s pick one of the frequent such statements related to agile delivery
“IT Must Become Agile”
Always looking to get their IT department into better shape (which usually translates into delivering faster at lower cost), business leaders aren’t shy to suggest potential improvements to their technology teams. While that’s a good sign - at least business cares about their IT, it can also lead to awkward moments.
One such moment occurs when the business concludes that their “IT should become agile”. Now, let’s give the business the benefit of the doubt and assume they actually meant IT should become more agile, not just deliver faster under yet another fancy transformation label. Still, they have sadly misunderstood one of the main mechanisms that make Agile delivery work.
Agile Maximizes Value
The Agile Manifesto states that agile practitioners value working software over comprehensive documentation. They also value responding to change over following a plan. As stated numerous times, this doesn’t mean the latter things aren’t needed (“nah, we don’t need to write docs, we’re all agile, yo!”). However, agile development is geared towards maximizing the business value that is delivered. Working software can deliver business value, a project plan cannot.
So, Agile delivery is in the business of maximizing the value delivered with the available time and resources (this includes investing in architecture, clean code, and tooling to maintain value delivery velocity!) Knowing that software delivery is maximizing the return on investment for the business is a great thing. No wonder business wants IT to be agile.
Value Comes From The Business
Now, how does one prioritize feature delivery by value? There are two answers. The process-oriented answer is that the product owner maintains the backlog and thus sets the priorities. The systemic answer (in the complex systems sense) is that only the business side can prioritize by value. That’s one reason a product owner should be part of the business, not a glorified business analyst (which despite the name is generally part of the IT team).
Oops, now we have a problem. How can IT become agile, which is based on maximizing value, without the business who’s the one to articulate such value? Agile software development requires a close connection between business and IT. In fact, a lack of trust between business and IT is often the very reason software delivery isn’t going as well as it should.
Lack of trust between business and IT is often the very reason software delivery isn’t going as well as it should.
Agile requires mutual trust between business and IT: IT needs to trust the business to prioritize features by business value and the business trusts IT to deliver a high quality implementation of it.
The Agile Mechanism Spans Business and IT
This means that “agile” is a journey that business and IT must embark on together. Therefore, someone demanding that IT should become more agile is a warning sign that the concept has been misunderstood. Worse yet, the misunderstanding likely leads to unrealistic expectations, which will doom the whole initiative. That’s why I classify “our IT must become agile” as an instant conversation stopper.
You Can’t Solve Systemic Problems with Local Solutions
As an architect, I am a big fan of systems thinking - The Software Architect Elevator dedicates a whole chapter to this topic. It’s hard to be interested in systems thinking without having come across Russ Ackoff’s equally insightful and entertaining talks and papers. The notion of being able to improve one part of the system, the IT, to improve the overall system behavior, running a successful business, is a classic case of not considering the system as a whole. It’s really worth watching the whole video, but Russ’ clear statement at 05:27 drives this point home:
“If we have a system of improvement that’s directed at improving the parts taken separately, you can be absolutely sure that performance of the whole will not be improved.” –Russell Ackoff
So, trying to make your IT agile isn’t going to make the system any better. Just like architects, business leaders need to zoom out and see the context in which they are operating.
Next up: Part 4: Lack of Discipline is Agile Failure Mode #1
Make More Impact as an Architect
My book The Software Architect Elevator helps architects and IT professionals play at the intersection of technology, organization, and transformation by sharing the real-life journey of a chief architect. Buy it on Amazon US, Amazon UK, Amazon Europe
