I often hear teams saying they want to be Agile. I always remind them the end goal is’t to be Agile but to be effective. Lean Agile practices have the potential to make you more effective but making a list of ‘Agile practices’ and implementing them in your teams without asking why can be a quick route to failure and lack of adoption. For example workplace visualisation is very powerful, but what problem are you trying to solve by sticking cards on a wall?

When thinking about what problem(s) you are trying to solve I’ve distilled them down to a list of wastes that seem to be common in most orgs. I’ve pivoted this list of wastes with Lean Agile practices and ticked the practices that may help to reduce each waste. Click here or the image above to download a PDF of the matrix.

As an example of how I use the matrix, if a software team suffers from a high level of defects then look down the Defects column for the practices (ticks) that could help reduce defects i.e. Cross Functional Delivery Teams, Pair Programming, Test Driven Development, Automated Testing, Continuous Integration, Refactoring, and Showcasing.

Here’s a brief definition of each of the column headings (wastes). To find out more about the practices listed in each row, google it!

• Lack of purpose – heads down coding story after story. What goal are we aiming for? Are we building the right solution?
• Staff contention – when staff are shared across multiple projects or pieces of work resulting in context switching.
• Code base contention – when too many developers are working on the same codebase. There are two aspects to this commonly referred to as – merge hell, and release hell.
• Tech environment issues – under-provisioned environments, multiple teams sharing environments – common example here is different teams sharing a common QA environment. One team has to wait for the other teams release to clear QA before they can test.
• Hand offs – either internally (operations teams, test teams, commercial teams for signoff) or externally (3rd party vendors, data providers, etc)
• Lack of Prioritisation – ‘everything is a priority’ or ‘We’ve given you a list of everything we want delivering’ or ‘we’ve got 8 P1’s, 20 P2’s, 122 P3’s’ or ‘your priority is what I tell you is your priority’ or ‘everyone can work on at least 3 things at once’
• Defects – should be self-explanatory?
• Waiting – Often a result of other forms of waste such as hand-offs, lack of prioritisation, large batch size, tech environment issues, and inventory.
• Large batch size – attempting to define too much up front. Work isn’t finished until it is running in production and getting feedback from users. Large batch sizes simply delay that feedback and increase overall risk. Smaller batch size increases flow, improves visibility, providing better control.
• Inventory – Partially done work anywhere in the lifecycle.
• Gold plating – why develop a really simple feature when a developer could instead develop an all singing, all dancing highly complex feature that considers all possible future requirements.

As a final note, what practices would you include on the left? What problems do you think they help to resolve?