Lean Principle #7 – Optimise The Whole
The last of the 7 Key Principles of Lean Software Development is ‘Optimise The Whole‘.
In their popular book, ‘Implementing Lean Software Development‘, Mary and Tom Poppendieck explain that the software industry is legendary for its tendency to suboptimise. They give two examples:
Vicious circle number 1
A customer wants some new features ‘yesterday’.
Developers hear: get it done fast, at all costs!
Result: sloppy changes are made to the code.
Complexity of the code base increases.
Number of defects in the code increases.
Vicious circle number 2
Testing is overloaded with work.
Result: testing occurs a long time after the code is originally written, or testing is reduced.
Developers don’t get immediate feedback, or some things are not properly tested.
There are more defects in the code.
Testers have more work.
Feedback to developers and quality improvements are delayed further.
These vicious circles can ultimately result in an exponential increase in the time it takes to add new features. They can also result in a notably lower quality product, which affects the end users and ultimately may also affect their efficiency or the competitiveness of the product.
A lean organisation seeks to optimise the whole value stream, not just individual functions or teams. It is extremely common for big delays in projects and processes – as well as communication issues and misunderstandings leading to other problems – to be caused by handoffs between teams, departments or organisations. The fact is that crossing organisational boundaries – even internal ones – is expensive.
One of the principles of agile methods that has resulted from this experience is the idea that the best way to organise teams is so they are complete, multi-disciplined, co-located product teams that have all the roles and skills they need to deliver a request from start to finish, without reference to other teams.
Naturally this can be hard to achieve – particularly if you don’t have the authority to re-structure your organisation! That’s one of the reasons why sometimes it’s important that agile adoption is driven from the top. Nevertheless, the fact remains that many of the issues we face in traditional IT departments are caused by structuring teams around roles or skills, rather than products or projects.
When a team is organised by product, with everything it needs to deliver, there are some distinct advantages. Apart from optimising the team’s workflow and avoiding some of the issues mentioned above, I have also observed across many teams that when organised like this teams have better ownership of the products they are responsible for, leading to better commitment, quality and innovation. They also tend to have a stronger sense of team spirit and greater cooperation between team members, as the team is one team with shared goals.
Putting all of this together with the better optmised workflow, the benefits or organising in this way can be extremely significant – not only in terms of the team’s performance, but also in terms of the quality of the product, which ultimately can make your organisation more competitive. And better products can have a direct impact on the bottom line, either by improving internal efficiency, or by earning more revenue from products.
7 Key Principles of Lean Software Development: