HSD offers pragmatic guidance that covers the entire software development enterprise. Visualized as a number of maps based on the H-Model combining:
- Strategy development
- Lean Portfolio and Project Management
- Agile Architecture guidance for Enterprises, Solutions and Systems
- Organizational Structuring and Leadership
- Teaming and Social Practices
- Flexible, Continuous Integration Streams
- The Hybrid Dynamic Model
HSD is not static, we are constantly adding new content - follow us on twitter @HolisticSW to keep track of our updates.
Read the Introduction or just dive in below to find out more.
Holistic Software Development is based on the H-Model that resonates with the old v-model but ties levels of abstraction related to planning, requirements, architecture or code to levels of a Definition of Done level through successive layers of integration validated through testing and acceptance activities. Unlike the V-model, the H-model is explicitly iterative, and focusses not on vertical decomposition and recomposition but on the cross-bar of the H-model: released products refined by iteration.
You can click on parts of this diagram for more information!
The areas inside the H are (from the top) Portfolio and Programme Management and (from below) Product Delivery (containing agile/iterative teams, continuous flow teams contributing builds and releases).
The cross-bar of the H model, Builds and Releases implemented by Integration Streams, is the critical join up of Strategy, through Portfolio, Programme (and Project) management if they exist to Delivery teams. This area is where organizations traditionally have a lot of difficulty and is where we de-conflict agile delivery and management approaches. All of this wider view of delivery is aligned to business strategy and focused on the delivery of business value, not as an after-thought but permeating the entire model.
The left of the H-Model describes concerns such as people practices, organizational patterns, team forming practices as well as the decomposition of Requirements and Architecture. The right of the H-Model covers iterative and continuous integration and re-composition through Operational Environments, Definitions of Done, Quality concerns, Adoption and Business Change and ultimately the delivery of Business Value.
The H-Model combines the conceptual mapping of the V-model with iteration and re-emphasises the horizontal links, instead of the separation of the sides of the V.
The Small Picture
The Small Picture shows how a small team or small team of teams can work in a relatively simple organisation. Covering the bottom half of the H-Model the Small Picture is likely to feel reasonably familiar to small teams.
Although the Strategy and Portfolio elements are not shown in this simple case there is no reason why Product development can't directly deliver strategic goals, with or without a portfolio management layer. If there is more than one product in development, then there is a Portfolio but it may be managed implicitly until there are more than a handful of projects. Bear in mind that Organization Structure significantly affects culture, ways of working and decision making even in seemingly simple cases.
The Small picture shows how simple agile/continuous teams operate within the H-Model. It is possible to directly map Scrum, Kanban and other processes onto the small picture. If you don't have many systems of systems that need to integrate with each other in a large complex organisation then the small picture, with some elements of Strategy are probably enough for you. If you do need to scale agile and lean practices throughout a larger or more complex organisation then the Big Picture has more elements of the H-Model and may be more useful.
The Big Picture
For larger or more complex organisation we use the Big Picture. The Big Picture contains all of the parts of the H-Model, showing strategy and portfolio layers that are missing from the Small Picture. The big picture shows how many teams can deliver in parallel towards a large portfolio serving strategic goals. The Big Picture describes how concepts join up and flow throughout the enture software value stream. Every item on the big picture is clickable, linking to a detailed article.
HSD is indicative, not prescriptive - many big pictures can be formed with elements swapped out and skipped as required. The purpose of the big picture is not to insist that each element must be used, instead it is to describe how elements join up and what the whole system looks like.
Although the Big Picture shows a “Programme” construct delivering a Product Family and co-ordinating contributing Product delivery “Projects” we use very broad definitions and do not intend to imply traditionalist project and programme management is always required. HSD requires iterative or continuous delivery, therefore iterative Project and Programme management have a place, but waterfall processes do not.
Often we encounter organizations where different groups of people are working professionally but due to a lack of understanding of their "big picture" their work is simply not joined up with other areas of the organization or other teams. There's no value in teams sprinting really well but delivering the wrong product. There's no value in planning that doesn't reflect reality and join up strategy to delivery.
Understanding how work joins up to deliver Business Value is the first step towards actually generating Business Value making an organization happier, faster, leaner, more agile and producing products of greater value.
The Hybrid Dynamic Model
Holistic Software Development embraces variation and recognizes that "one size doesn't fit all" when it comes to process or organization design. For organizations larger than a few small teams we recommend adoption of the Hybrid Dynamic Model which is designed with variation, and strategic evolution, in mind. This model encourages different ways of working, team structures, cultures, planning and architectural approaches within an organization. Rather than being an "either/or" decision the hybrid dynamic model is a "both/and" proposition for organizational design.
We present HSD as a Small Picture, Big Picture (with a number of variants) and a number of views. Because HSD embraces variance, and because organizations need to be different shapes and sizes there are a number of paths through the HSD material.
In large organizations the small picture, big picture and other variations may all be in operation side be side with each other - this is the hybrid dynamic model.
Adoption of Holistic Software Development, or some of the practices or structures inside it, can be managed in a number of ways depending on the requirements of a specific organization, its current practices and constraints. We recommend adopting the principles and manifesto, rather than a step by step formal adoption, and using elements of HSD to adopt itself, both to ensure return on investment and provide an example to the organization.
We recommend adoption from three points of view, which can be adopted in isolation but work best when adopted together:
- Top-down Strategic Adoption
- Middle-out Portfolio and Programme Adoption
- Bottom-up Team Adoption
Further refined by:
- Systemic analysis
- Establishing Continuous Improvement
Optionally, when a business is suffering problems:
- Assessment and Intervention
Adopting Holistic Software Development involves working with teams, managers and leaders on Day 1 of adoption. There's no need to spend months assessing an organization before linking parts of it together. Our deeply experienced consultants and partners provide mentoring and coaching - they can rapidly adapt to existing structures and behaviors. All of our adoption practices are aligned to our Psychology-based Business Change techniques.
You don't need us to adopt HSD but we, and our partners, will accelerate your adoption.