One of the key approaches of good software development is building software iteratively and incrementally. Iterating over our process and software gives us a chance to reflect on how we are working, while building increments of functionality allows us to begin to deliver functionality and value (in the form of working software) early. This feedback loop is critical to good software development.
What I see less talked about are the thought process and roles necessary for this kind of approach – especially in large scale systems. We want slices of value which cut through the various layers – Database, Services, UI, etc. That’s the goal of incremental development. But a common pushback comes from the notion that in working this way we throw out the vision, guidance and architecture discussions. I think this couldn’t be further from the truth, but how we implement it is a little different.
In the diagram above, there are three key bubbles – Systems Thinking, Business Vision and Technical Vision. Systems Thinking is responsible for How We Work. In a Scrum implementation, this is going to be your ScrumMaster. From a Lean perspective, we’re all responsible for visualizing how we work to improve it.
The second bubble is the Business Vision. This person is responsible for driving out the What We Need of the solution. In Scrum, this is likely your Product Owner.
The final bubble is the Technical Vision. The goal of this role (or roles) is that they set the vision for the various components that will work together – database, services, systems, etc. But instead of dictating a vision, they work closely with the teams with each slice through the system (also known as a tracer bullet) to see if the overall solution is moving towards the vision, and whether the work – or the vision – needs to change.
These three roles form a critical element of vision and leadership for the teams, enabling a highly fertile container where great software can grow. So next time you are working with your teams, think about who is driving the technical vision, the business vision and the vision of how the team should work – and see if explicitly defining some of these improves your process.
I like the way you separated the vertical and the horizontal slices. Without the technical vision (horizontal), we could develop the same component for two or more distinct business needs (vertical). Unfortunately, this happens quite often among clients for whom I work. No later than last week, I drew a similar diagram to explain the importance of building common components for two business applications.