focus on the customer

Thanks to Poppendieck's book Implementing Lean Software Development, from Concept to Cash, I read about google philosophy:

Focus on the user and all else will follow.

Lean demands that we identify what our customer needs, then we deliver just that. She talks about how the Quicken team entered a mature market of complex accounting software, simplified it, and delivered value to their customers. She mentions Google, Dell, Zara--all companies that have risen to success because they have the right focus.

set-based engineering

Since research/design is often very risky, the Toyota Product Development system integrates several processes to manage the risk. They use strict time-boxing, with multiple parallel research tracks trying to succeed, and at the end of the time box they can choose from all successful options. Their lead engineers are responsible for not only technical success, but business success, and their engineers stay on the same team for a long time, and are expected to excel in their craft. The teams, and individuals, are given objectives but are not micromanaged.

Why isn't it waste to design things we won't use? It's because waste has to be regarded in context of the whole system--and failing to deliver an acceptable design is a much bigger waste than optimizing the whole.

Agile 2009 Gordon Pask Awardees

This year's Gordon Pask Award winners were Gus Power, Simon Baker, and David Hussman. Ultimately we'll read more about it at http://www.agilealliance.org/show/1656

genchi-genbutsu

According to Mary & Tom Poppendieck's Implementing Lean Software Development, genchi-genbutsu means "go, see and confirm". I think it's a very powerful image for software development--when we have first-hand experience of what our customer values, we're more likely to understand its essence and to successfully make a minimalist implementation. It also sets up the relationship for us to ask customers directly about design tradeoffs. So, go, see what your customers are really doing, and find a way to make that go more smoothly--but ask them first about your ideas, to make sure you've understood the process.

Poppendieck's version of Shigeo Shingo's seven wastes

The lean community has categorized the following as the seven wastes of software development:

1. Partially Done Work (it delays feedback, thus increasing the risk we didn't catch mistakes; our investment cannot turn a profit if it's undone; we risk falling out-of-synch with other people that continue to work on the previous version)
   
2. Extra Features (this is overproduction and the worst form of waste because it's at the top of the food chain, i.e., it inevitably included all the other forms of waste somewhere in the process of creating the feature)
   
3. Relearning (if we already paid for one developer to discover something, why pay another developer to do the same thing? still, it's very difficult to have a usable system of documentation that explains why we chose what, when)
   
4. Handoffs (tacit knowledge--that which can't easily be explained verbally or on paper--forces the recipient of a handoff to re-do part of what we've done)
   
5. Task Switching (task switching increases the time-to-completion of the most important task on our plate, or causes waste in terms of unfinished work or relearning)
   
6. Delays (when developers have to wait for a customer's opinion, they may guess or pause. Either way, it's waste.)
   
7. Defects (in my opinion, defects may be on par or worse than Extra Features as waste... we've gone through all the work of making a feature, and then have to revisit it, re-test, and re-deploy.)
   

favorite ideas from Poppendieck's Implementing Lean Software Development

When I read paper books, I underline and dog-ear the pages. Then I come back a bit later and blog about what I read--it's a way to reinforce what I got out of the book. Here's a summary of the ideas that most struck me this summer as I read Implementing Lean Software Development, from Concept to Cash by Mary and Tom Poppendieck. Quote-marks indicate direct citations.

• Toyota's productivity is "consistently four times that of its competitors, and quality is twelve times better", says Jeff Sutherland in the forward.

A little history

• The book begins with a 2-page history of the industrial revolution. Starting with the late 18th century French invention to use standard, interchangeable parts for firearms, the US ran with the idea to create mass manufacturing and economies of scale that had never been precedented. Then in the early 20th century Taylor applied the idea to people--making the work of automobile assembly line workers so easy they could be trained in 10 minutes, and therefore be easily replaced. This was in strong divergence with what happened in the loom industry in Japan, where the automated looms required a lot of expertise to maintain and tune--here, individual skill was highly valued and teams were preserved, even as companies were torn down and restarted.
• Just after WWII, the Toyoda family (future creators of Toyota) felt the need to catch up with American mass manufacturing, but they did not have access to the wealth of resources required to benefit from economies of scale. Instead, they aimed for "just-in-time flow", which gave them the advantage of driving down the cost of variety in their products. The Poppendiecks say that this is "the only industrial model we have that effectively manages complexity".

The Manufacturing World

• Jidoka -- autonomation -- "Toyoda automated looms... detected when anything went wrong and shut down automatically". This sets the stage for a "stop the line" mentality, mindfulness, safety and quality.
• When there are mistakes, it's not the worker's fault--it's the process which has room for error. Fix the process so we can't make mistakes.
  
• Plant managers were all expected to spend some time on the line.
• It is the creativity and practical knowledge of the line workers themselves that drives continuous process improvement
• Lean is infectious--Toyota and Dell have extensive supplier networks, and freely exchange information and training to support the supply chain. They define contracts in a way that align the interests of both companies.
• Peter Drucker states that "a company that maintains a single management system throughout the entire value stream will see a 25 to 30 percent cost advantage over competitors"
• BAA built terminal 5 at Heathrow airport with a novel kind of contract, including target cost and a risk/incentive pool. Whenever a subcontract finished, contractors got paid the target cost plus anything that was left over in the incentive pool. This aligned the interests of both parties, and work went more smoothly.
  

How does this apply to product/software development?

• the Toyota Product Development System is designed for "generating and preserving knowledge for future use"
• in product development, it is not waste to explore multiple options/technologies--they call this "set-based concurrent engineering"--these options allow us to evaluate trade-offs appropriately when the time comes to make a decision
• "repeatable and reliable speed is impossible without superb quality"
• the Kano model states that to impress customers, we need to satisfy basic needs, as well solve problems they weren't even aware of
• "behind every great product there is a person with great empathy for the customer, insight into what is possible, and the ability to see what is essential and what is incidental"--Martin Cagan of the Silicon Valley Product Group
• chief engineers at Toyota play a product owner role--they are responsible for the business success of their vehicle family, and they do first-hand research (genchi-genbutsu "go, see and confirm") of their potential customers as well as pay attention to marketing research and dealers
• inspection to prevent defects is necessary; checking to catch defects is waste
• just-in-time decision making is critical to effective risk management. The longer we wait to commit to a particular path, the more we know about our options--but if we wait too long, some options vanish. Establish, up-front, when key decisions need to be made, and then adhere strictly to those timeboxes. See set-based design.
• "above all, team members must be mutually committed to achieving a common purpose"
  

Software development

• "unused features are the worst kind of waste in software development". Justify every feature!
  
• "great software grows out of a mind-meld between a person who really understands the business and a person who really understands the technology"
• simplify--both the product and its implementation
• part of the design must incorporate the concerns of operations staff--people that will support and maintain the application
• seek a "product" funding model, rather than a "project". Products are funded incrementally, evaluated on their return on investment, and are released incrementally. Like landscaping or gardening, custom projects are never done. When a "product" is championed by business leaders, it is more likely to have business value.
• Don't automate a complex process. Simplify the process, then code it.
• When a lot of work needs to happen quickly, we need "self-dispatching" work--that is, remaining work items need to be evident to everyone on the team, and people need to see the overall status of the group
  

Intra-team politics

• a discussion often changes once a "decider" has been selected. Make it clear who that decider will be, and then watch the arguments unfold.
• it's important that proposed changes in a system are done scientifically--so we can evaluate the old against the new (PDCA)
  

Value stream mapping
A value stream represents the work we do starting with a customer order and ending with delivery of that value. The map needs to be detailed enough to uncover problems, but should also abstract sufficiently so we can see the big picture

• long delays indicate queues--we want to get rid of queues because they represent an unfulfilled need, a warehouse of undelivered value that wastes money to sustain, and they inhibit feedback from the customer
  
• process loop-backs indicate churn--if you're re-prioritizing, re-checking, re-designing, re-doing, it's waste!
  

Reducing cycle time

• balance the workload
• minimize the items in process
• minimize the size of work items
• release regularly
• limit work to capacity
• use pull scheduling

Lean capitalizes on everyone's brainpower

• Lean can only be realized when there is true respect for people in the workplace. At Boeing in 1988, the 777 project started with the premise of "working together"--and this fundamental respect for people ended up creating a work environment that shares many attributes with Toyota's lean process.
  
• Deming wrote about how to use people's full potential in the workplace: "appreciation for a system (synergy of parts), knowledge about variation (problems come from the system itself), theory of knowledge (Plan Do Check Act), psychology (skill, pride, expertise, confidence, cooperation)".
  
• Also see Deming's 14 points to increase quality.
• Deming said that a company's purpose is to create products that please the customer so much that they'll keep buying more products--that is, to make a sustainable system, focused on long-term relationships
• In a lean organization, problems aren't recurrent--they aren't systematic--because as soon as a problem is detected as systematic, the system is changed
• "standards are viewed as the current best way to do a job, so they are always followed"--anyone who finds a better way is expected to change the standard documentation
• 
  

industrial tourism

A mentor of mine once said that insanity comes from isolation--that without close connections to people outside ourselves, we miss out on reality checks, and start doing things that are crazy, just because in our particular situation it seems to make sense. I think this insanity arises at both a personal and group level. I think the companies that encourage employees to reach out and network with other professionals end up finding more ideas and integrating more successful ways of working.

One means of networking I hadn't heard of before I came to France was first introduced to me by my colleague, Olivier--"tourisme industriel", or industrial tourism, a year ago, as a way to accelerate learning and improve the team's experience. Just this past week we had two "tourists" come in to observe our dev team--and while they didn't have a lot of experience with Agility, it was refreshing to have a new pair of eyes on our process--their questions came much more freely than an intern's or a new team member's, I believe, since they weren't expected to integrate these practices--they were simply here to find out if it made sense for them. I'd be really interested in trying this back in the States on a long-term basis, but the companies I'm familiar with would likely be too concerned about intellectual property to try it. Because of the questions from the tourists, we took a few minutes yesterday to do a special retrospective on whether we should change anything in our process. The tourists noticed that our connection with the XP client was excellent, that our adhesion to the Pomodoro breaks was lacking, and that the idea of deploying to prod was valuable.... Well, no changes came out of this retrospective--we're going to just keep going with our half-hearted Pomodoros, because we think it makes sense in our particular situation ;)