The Lean metaphor of the rocks in the lake

Adopting methods like Agile, Scrum and Lean brings many well known advantages in software development life-cycle.
But what I’d like to cover here is a more subtle advantage that you start realizing after some months you are applying them.

It’s related to the size. Yes the size.
The size of almost everything you do: artifacts, processes, methods, teams, iterations, releases and so on.

The principle behind it is the Lean principle called “the rocks in the lake“:

The depth of the water may represent the size: when the water is high many rocks are hidden and these rocks represent weaknesses.
If we are able to keep the depth of the water low then we can see the rocks: the weaknesses are visible and we can start approaching and fixing them in the most appropriate way.

Let’s see the water and the hidden rocks one by one trying to identify how to keep the water low…. comments are welcome as usual.

Water	Rocks	How to lower the water
TEAM	Big team hides: Guru effect Sub-teams working separately Poor team-working: boundaries between members and silent members following the others Work redundancy and duplication due to the poor communication within the team	Keep the team small: max 5 members with a good mix of skills
ITERATION	Long Iteration (or no iterations) hide: Issues with integration and release process Bugs proliferation (bad surprises close to the release time) No clear commitments and accountability Refuse to change (you can respond to change only after months)	Keep the iteration short: max 2 weeks with clear goal and a clear definition of DONE for the user stories Continuous integration
RELEASE	Long release hides: Issues with integration and release process No vision for the release: it’s hard to identify clear priorities	Keep the release short: max 4 months with clear goal and appropriate release planning Continuous integration
USER STORY	Big user story hides: lack of integration: software is not integrated for weeks lack of unit and integration testing strategy poor confidence on work done in short period (2-3 days) fear of commitments lack of clear understanding of requirements	Split big user stories in smaller user stories: small here means with lower complexity and therefore with lower size. Then each user story can be split in technical tasks short enough to guarantee confidence for commitments to the team Continuous integration
MEETING	Long meeting hides: Team doesn’t like responsibility People not able to communicate and take decisions	Keep meetings short (max 2 hours) Choose a chairman that keeps the focus on the main topic, avoiding diverging Prepare the agenda and close the meeting with a list of clear action items
BACKLOG	Big backlog (also without priorities) hides: Wishful thinking No clear vision on release	Focus on few user stories that are candidates for the release: the rest can wait Prioritize them
WIP	Items in progress like tasks or user stories for long time hides: lack of unit testing fear of integration issues with design (lack of modular architecture, decoupling,…)	Split tasks in smaller ones The whole team should work on one user story at time (if possible) Continuous integration
INTEGRATION CYCLE	Long cycles of integration hide: lack of unit and integration testing strategy issues with design (lack of modular architecture, decoupling,…)	Somebody says that the code should be left out of the repository no more than 15 minutes… Continuous integration

Nice quick reference for Lean is Lean Primer by Craig Larman and Bas Vodde.

Advertisement