A parallel in Disciplined Agile’s approach to complexity and designing quality software

 

Large software systems are usually complex due to a combination of poor design/architecture and tech debt. The factors to attend to to reduce this complexity is well known (cohesion, coupling, encapsulation, testability …) along with methods to achieve these (design patterns/principles).

We would never take a “probe-sense-respond” approach with software. Instead we attend to design qualities and use automated testing to validate our changes.

There is an equivalent approach when it comes to improving our value stream - Dr. Goldratt's Inherent Simplicity. It too requires attending to certain factors which I suggest, for product development are:

1-The value density of the items being worked on
2-Batch size of work
3-How workload relates to capacity
4-The value creation structure of the organization
5-Effectiveness/efficiency of the value streams
6-Visibility of work and workflow 
7-Quality of the product
8-Culture of the organization

We must, of course, validate our changes (reduction in cost-of-delay and/or cycle times are good measures). But if they don’t result in an improvement, they will result in learning. It should never be fail fast, but rather learn fast.

You can see more at Dealing with Complexity by Creating a Bias For Simplicity h