I was cleaning up some old files, and came across my notes from a workshop I attended with Mary and Tom Poppendieck entitled Lean Software Development – Leaders Workshop at the YOW! 2010 Australia Developer Conference in Brisbane. Obviously the slides and commentary have a wealth of information, but here are some of the key takeaways I had.

• stop doing stuff that does not deliver value, not laying people off
• spend time doing the right stuff, not the wrong stuff
• think systems, not software – Southwest think employees, customers and then shareholders
• optimise the whole system (software is just a layer) – Amazon is structured around it services (2 pizza teams of 8-10 people)
• a separate testing team is silly – just handoff / afterthought, need to build quality into your product
• need to understand value before you deliver value – understand what your customers value, not what they want and build the right thing before building the thing right
• setting up a new product is a set of learning loops
• watch for what is making people uncomfortable
• understand your customers not by bringing an idea but by taking the team to understand the problem
• there is always demand in a service company – fix issues as fast as possible, but that is not the game
• consumability – how much effort does the customer need to go through to get value?
• customers decide value… and therefore decide waste
• measure productivity on value delivered, not features
• work in progress is waste – customers are not interested in your long list of things to do
• good Agile teams have a low number of defects
• map end-to-end flow to find the biggest opportunity in your end-to-end process
• 40-90% of the cost is maintenance not delivery, the cost of quality is way higher than the cost of building quality in, don’t put defects on a list (track them, fix them immediately), root cause every escaped defect, determine why every one happened
• problem with readable specifications is that the text is not refactorable – any text page will have hundreds of ambiguities
• every organisation that calls itself professional should be doing TDD
• legacy code is code without unit tests, use Martin Fowler’s strangler pattern or the Mikado method to refactor
• expertise takes 10 years / 10,000 hours of deliberate practice, need a teacher to challenge, feedback and dedication (The Road to Excellence)
• marketing leader – for a successful product you should be able to name this person
• technical leader – keep two top engineers free to roam around and give guidance
• Empire State Building – on time and under budget, had to manage the flow of materials not tasks, had two alternating mills to keep up schedule and remove failure point
• people who have dome something before should know how to deliver within the constraints
• when managing an organisation you need to manage the capacity, you need to have a stable flow
• kanban – reduce work in progress to expose problems (don’t crash your boat on the first day, keep your limits high then lower your limits and remove your problems one at a time
• kanban board – every column is handover to the next column, the next column (downstream process) gets to define done
• 5 why’s – the cause of the cause of the cause of the cause…, The Team Handbook has good process improvement practices, as do the Six Sigma tools
• delivering value – read Competitive Engineering by Tom Glib and Value Driven Development
• product-centric development – 54% of Fortune 500 companies are heading in this direction

From Miscellaneous

Finally, a huge thank you to Nick Muldoon from Atlassian who helped me out with a space on this course. Also to one of my colleagues who reminded me that we should ask forgiveness not permission when I was dealing with some competing priorities!