Episode 101: The Lean Mindset with Mary and Tom Poppendieck

The Agile Revolution Podcast

craig-poppendieckCraig catches up with two luminaries in the Agile and Lean space, Mary and Tom Poppendieck at YOW! Conference to talk about agile, lean, rapid feedback, culture and leadership. The discussion points include:

  • Making the link between lean and software development and discovering that waterfall makes no sense
  • The origins of the first book: Lean Software Development: An Agile Toolkit
  • Agile is not lean in software development, Agile is lean in a delivery organisation
  • How long does it take you to put a single line of code into Production?
  • The manifestation of lean really kicked off in 2010 with both the rise of DevOps and the Lean Startup
  • Delivery organisations versus engineering organisations and the journey of Agile
  • Agile has not well addressed delivering the right stuff, solving the right problem and the architecture of rapid deployment
  • Only two goals at ING: Deliver every two weeks and don’t crash production, resulted…

View original post 128 more words

Lean Software Development Workshop with Mary & Tom Poppendieck

YOW! 2010I 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
Here is a picture of an exercise we did to map the cycle time of a particular company (it highlighted some of the issues they are having around approvals).
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!