Mostrando entradas con la etiqueta lean. Mostrar todas las entradas
Mostrando entradas con la etiqueta lean. Mostrar todas las entradas

2008/05/01

Back in the U.S.S.R.


East Germany may no longer exist, but now we have companies featuring central planning by Troikas, mission statements crafted by apparatchiks, quinquennial planning, no right to choose leaders in companies, no democracy in the workplace, a clear distinction between intelligentsia and peasants (top CEOs make 512 times the median salary and enjoy company 'dachas', jets and limos), and 'state' monitoring (time clocks, dress codes, drug-screening, 'employee assistance' plans, e-mail monitoring, smoking and personal conduct rules, as family-life audits). [1]
This is not a quote from a labor union leader, an anti-globalization essay or a witty comedian. It's from a proponent of democracy and transparency in the workplace that happens to be a business owner putting his money where his unconventional mouth is [2]: Ricardo Semler, in The Seven-Day Weekend [3].

I loved this book, even if its writing style is not that great. Its main point is showing how Semco, Semler's company is run. When Semler and Clovis Bojikian started changing the traditional command and control ways,
"We wanted to demonstrate that the workplace could be a place of satisfaction, not of suffering. Work should be a pleasure, not an obligation. But this wasn’t just some humanitarian thesis. We believed that people working with pleasure could be much more productive.”
To Semler, it's not about values: it's about competitive advantage.

Hurry up and read his book, or take a peek into The Semco Way by reading a 1989 article by Semler in the Harvard Business Review or a 2006 article about him in Strategy+Business. I'm sure that it will give you lots of food for thought.

[1] Soviet/Corpororate parallels quote: It's a funny coincidence that I read this during International Workers' Day
[2] Unconventional mouth quote: by Geoffrey Colvin in a Fortune article
[3] Even if Semler is a best selling author, I never heard about him until I recently read a post by Jon Lister. Thanks so much, Jon!

2006/12/28

Mary Poppendieck: Competing On The Basis Of Speed

I watched Mary Poppendieck's talk at Google: Competing On The Basis Of Speed. It is a good talk, but it does not compare well to Mary and Tom's most excellent Lean Software Development: An Agile Toolkit (amazon.com amazon.co.uk safari).



I took some messy notes, way too powerpointish :-(. My advice: go for the book.

Intro

  • Fast companies (e.g. Dell, Toyota, Google)
    • competitive advantage
    • lower costs
    • large barrier to entry for competition
  • Speed's enemy: complexity
  • 3 faces of complexity [1]:
    • waste: anything that depletes resources without adding customer value
      keep it simple
    • inconsistency: anything uneven, unbalanced, irregular
      make it flawless
    • overload: excessive burden
      let it flow
Keep it simple (video 5m45s)
  • Common infrastructure:
    • Architecture
    • Conventions: naming, coding, security, logging, ui, configuration management...
    • Tools
  • Refactoring to keep simplifying
  • Sustainable simplicity: change tolerance (video 7m52s)
    • 60%-80% of code is written after the first release
    • the development process has to anticipate change
    • decide as late as possible, when you have more info
      • make decissions reversible whenever possible
      • make irreversible decissions at the last responsible moment
      • set-based development: explore the whole solution space at once (Toyota worked on 10 motors at once for the Prius). Keep multiple options, and one has to work at the last responsible moment.
      • paradox: these redundant solutions are not waste
Make it flawless (video 18m28s)
  • 2 kinds of inspection
    • to find defects -> waste
    • to prevent defects -> essential
  • Mistake-proof every step: detect defects the moment they ocurr
    • don't track defects on a list: find them and fix them
    • test first, automated test suites
  • Role of testing (video 21m55s)
    • manufacturing:
      • a quality process brings quality into the products (unlike in software development traditional view)
      • finding process in verifcation -> you have a defective process
    • focus on preventing defects. Cannot be at the end of development, adding waste in the form of test-fix churn. It has to be integrated into the development process.
  • 4 kinds of testing
    • unit testing: developer intend. Automate them.
    • acceptance/regression testing: business intend. Automate them.
    • exploratory + usability testing. Manual by definition.
    • property (response, security, scaling....) testing. Take advanteg of tools.
  • Technical debt (video 26m55s)
    • anything that makes code difficult to change
    • the longer you acquire debt the worse it gets
      • cost ofcomplexty is exponential
      • regression deficit: more features, longer testing, until it dominates the release cycle
      • unsync code branches: the longer apart, the longer it will take to merge
  • Build Quality in (video 33m17s)
    • configuration management, one click build, automated testing, continuous integration, frequent depoyment
    • nested synchronization: test as early and often as possible
      • every check in - unit tests
      • evrery day - regression test harness
      • every week - operations test harness
      • every iteration - deployment ready code
Let it flow (video 43m40s)
  • cycle time : customer problem to customer solution.
    • software development cycle time: requests to deployment
  • process capability: wether you have or not a reliable and repetible cycle time for a given set of problems
  • delays: hint of opportunities for cost/waste reduction
  • queuing theory
    • total cycle time = number of things in process / average completion rate
    • shorter cycle time: ability to add new features
    • small tasks and slack decrease the total cycle time
      • utilization paradox (48m23s) - not having slack increases the cycle time. This is one of the ideas behind 3M's 15% of free time rule (Google's 20% precedent). Organizations targeting 100% utilization are meassuring the wrong thing.
  • Keep a honest queue/to-do list: short and in the realm of the things that can be reasonably expected to be done; no useful purpose for long queues
  • Stablish a regular cadence, limit work to capacity, minimize the size of things in the process.
System meassurements
  • cycle time (lean classic) - process capability
  • business case (are you making money) - business return
  • customer satisfaction sustainability
    • net promoter score [2]

[1] From Matthew May's The Elegant Solution: Toyota's Formula for Mastering Innovation (amazon.com amazon.co.uk)
[2] Frederick F. Reichheld's The Ultimate Question (amazon.com amazon.co.uk)