David Anderson in Austin - "Driving a Kaizen Culture Using Regular Operations Reviews"

David Anderson on March 17, 2011 spoke to a joint meeting of Austin SPIN, Lean Software Austin, IEEE CS Austin, and Agile Austin about a missing component of Kaizen culture, the Operations Review - what can your department do, how much of it did you do, and are you any good at it.
(I thought it appropriate since he espouses lean methodologies that he was wearing skinny jeans.)



Now this picture is not creepy because the girl in the cartoon is hugging David.

The Agile-Lean-CS-Spinners:

The main benefit of the standup meetings at a job was the after-meetings that allowed small teams of people, instant quality circles, to discuss and solve problems. This also struck me as a real benefit of this meeting - a chance to catch up with long-lost tech friends in the Austin community.

My random jottings:
Since academic software is seasonal, they share "Classes of Service" with car racing.
At the StandUp meeting only manage exceptions.
Many organizations only have a shallow implementation of Lean.
Real Kaizen is people just doing their jobs.

The meeting was a success - thanks to John Heintz for buying meals for everyone.

Last Night's Lean Software Group Meeting

Not knowing a "Value Stream Mapping" from an old tire (don't think too much about the analogy), I drove down to last night's Lean Software Group meeting at the Overwatch offices to join 27 other people and to try an tease some meaning out of all this Lean hype.
Scott Bellware gave a welcome message.
Andrew Cahoon gave an introduction of VSM and then Gary ? gave a compelling real world example of a Value Stream Mapping.

My notes:
* Value Stream Mapping is more an analysis and planning tool than a prescriptive activity.
* Don't make a perfect model, it's not worth the effort - just get a good enough model to do your work.
* Customers care about Quality, Cost, and Delivery.
* Kaizen is about continuous improvement and Value Stream Mapping is a tool to get to the next level.

The Toyota Way

I just finished listening to "The Toyota Way" while commuting in my Camry as a way to get an introduction to Lean Software Methodology. A few things that struck me in the book (in no particular order):

1. Counter Intuitive. Many of the ideas just don't sound right like stopping production if a problem is spotted on the line, or not using machines to their capacity. Although the ideas sound crazy at times, you can't argue with the success of Toyota.
   
2. Set Based Solutions. Don't just create one solution to a problem, create several solutions and discuss the merits of each with many people. Implement swiftly.
   
3. Continuous Improvement - "Kaizen". The production process should always be improving. People need to be committed to adapting to change and initiating change.
   
4. Commitment to Training. Employees should be trained well. I was amazed at the amount of training that Toyota offers its people.
   
5. Flow. Don't just optimize parts of the process - optimize the total system.
   
6. Fix the Process, "Pokayoke". When something does not perform as expected, don't just fix it, find out why it failed. Pokayoke means to find the root problem and take action so the problem does not occur again.
   
7. Easy to Copy Badly. The Toyota Production System is easy to copy badly with disastrous results. The example given was the magic chord that any employee can pull to stop the entire line when she discovers a defect in the process. Some plants tried to copy this method, but found it not to work well. In the Toyota plants pulling the chord doesn't immediately stop the line, but gives the team leaders some time to resolve the situation before stopping the complete line.
   
8. Focus on "Standard Work". Each step of production has written steps on how to do the work. The employees should be doing the process exactly as written. When defects in the line occur, the line managers focus on how the defect occured. Was the standard work followed? If not, why not? If it was followed, the standard work needs to be changed. Standard Work is the first step to continuous improvement. You cannot effectively improve an ad hoc process.
   
9. Eliminate Waste, "Muda". "anything other than the minimum amount of equipment, materials, parts, and workers (working time) which are absolutely essential to production" is waste. Seven classes of waste: overproduction, delay, transportation, processing, inventory, wasted motion, and defective parts. In software development I see a lot of inventory - written and tested software which has not been released because it's hard to install mission critical software.
   
10. Visual Displays, "Andon". It's important for everyone to see progress, so Toyota emphasizes big signs where everyone can see problems and production.
    
11. Hands-On Approach, Genchi Gengustu "Go see the problem". Management must visit the factory floor and see for themselves the problems.
    

15 Helpful Tips from Scott Bellware's Behavior Driven Class

On March 24th, last Tuesday, I attended Scott Bellware's helpful seminar on "Test-Driven Development and Behavior-Driven Development". A few of my take-aways:

1. One bug takes a unit of time to fix, but with multiple bugs the time goes up exponentially since the bugs can interact. Moral: Code in steps and only introduce one bug at a time.
   
2. Ask if the test you are about to write is a valuable test.
   
3. Code-DB impendence mismatch example: If orders have links to customer in the db, in code the customer has links to the orders.
   
4. Using "static" methods between layers is bad, it's like welding the objects together.
   
5. Inheritance is strong coupling, to be used as a last resort.
   
6. Scott and his team removed an entire layer of testing when they realized it provided less value than it took to maintain.
   
7. Databases are places for dead objects, not logic.
   
8. Someone at the meeting said Microsoft doesn't really do domain applications like we do, so they cannot really offer much advice on how to code.
   
9. "Reuse" is not a good goal.
   
10. You can overwrite tests, simple things are tested in more complicated tests.
    
11. Don't use prepopulated databases with test data. Start with an empty database, and end with an empty database.
    
12. When Scott asked the participants "Who does unit testing?" 80% of the 25 people raised their hands. "Who uses MSTest?", one hand.
    
13. Regression tests are a side effect of Test Driven Development, not the primary goal.
    
14. Doing traditional OO analysis (nouns, verbs,...) creates more objects than needed.
    
15. Don't directly expose an object's collections; use helper functions on the object. (Use Customer.Add(obj) instead of do Customer.list.add(obj))