When it comes to retrospectives, I've come to emphasise more on setting goals and working out how to achieve them rather than just discussing and responding to past events.
Fabio describes our recent attempt to do this.
Via Glen Alleman,
According to Typealyzer, the writing style on this blog reflects the ISTJ Meyers-Briggs personality type, the Duty Fulfiller.
Was looking at Subtext, and stumbled upon an interesting blog entry by Jonathan Edwards on why he didn't contribute to Beautiful Code:
Telling an inspiring story about a beautiful design feels disingenuous. Yes, we all strive for beautiful code. But that is not what a talented young programmer needs to hear. I wish someone had instead warned me that programming is a desperate losing battle against the unconquerable complexity of code, and the treachery of requirements.
Bob Sutton shares a comment made by Matthew May in response to Bob's post on The Auto Industry Bailout:
Thank you for a thoughtful and insightful post. Everything you describe mirrors my experience with a part of GM in the early 90s. I was doing some consulting with a division of GM and told them the best ideas, in fact no ideas, were getting heard. The managers to a person told me that wasn't their culture. During an offside I had the opportunity to design part of the program. It was an age-old prioritization game called Survival on the Moon: you've crash landed on the moon, 200 clicks from the mother ship, with 25 items you have to rank in the order of their importance in surviving the trek to the ship. You do it individually, then as a group, in order to make the point that "we" is smarter "me". (There is a right order, provided by NASA.) I constructed the table rounds cross-hierarchically, so one table might have a vp and a lowly staffer. Then I played a dirty trick: I gave the lowest ranking person at each table the answers ahead of time, saying that when it came time for the group ranking, their job was to everything in their power to convince the table they had the right ranking, short of revealing that I had given them the answer. Not a single table (about 15 tables of 10) got the right answer. Then I had the ringers stand up. Got to catch all the managers red-faced.
I spent 8 years inside Toyota as a fully retained adviser to the University of Toyota. It is the antithesis of everything you describe.
Process is how things are done. This is not enough.
A system is more than just how things are done. It includes how people relate to each other and how they are developed. It includes the technology and tools we use. It includes everything within our (bounded) environment because all must be considered when changing for the better.
When designing a solution, it is critical to understand what value it will bring.
I can respond with a very simple but sub-optimal solution if I know the return won't be that significant OR I can respond with a more sophisticated and more expensive solution if the return is significant enough to justify it.
But should I not always have multiple options anyway?
Well yes, but if I knew what the value was, I might flesh out 3 simple solutions rather than 1 simple, 1 average, 1 complex.
In other words, if you filter information about benefits to people who are designing your solutions, be prepared to get sub-optimal results.
On Tuesday we visited Sango, an exhaust system manufacturer and tier 1 supplier to Toyota. Sango had their 80th anniversary last June.
This visit lasted the whole day and most people in the group thought this was the best part of the whole tour.
Plant Tour
New Japanese phrase learned: Pika Pika => spic and span
1825 days without a work stopping accident.
Stand-up meeting every day at 9:30 before production starts where they go over the previous days defects and improvement ideas. They hold this near a problem board area with defective parts and equipment and analysis of why they occurred. I saw a similar area at Toyota Altona where they also has photo binders of past defects.
Key point for me: "Understand what's in front of you"
There were A3 sheets up with an analysis of different movements in terms of ergonomic quality. The range is 0 to -4 where -4 movements were the worst. Each category had visual examples of what the bad movement is. For example, having to do a full rotation. A goal is then set to remove all the -4 movements from standard work, and then -3 movements, etc. Saw the same thing at Toyota Altona.
[Would it be useful if we could set categories to different types of Checkstyle failures? Would this be useful to systematically but incrementally ratchet up the design quality of legacy code bases?]
Key point for me: Use before and after pictures
Training dojos exist for new employees, as refreshers, and for team leaders.
The purpose of a Standardised Work document:
Dan Ariely on the value of big bonuses:
We found that as long as the task involved only mechanical skill, bonuses worked as would be expected: the higher the pay, the better the performance. But when we included a task that required even rudimentary cognitive skill, the outcome was the same as in the India study: the offer of a higher bonus led to poorer performance.Via John Hunter.
Marcel McLeod, managing director of Total Fab, was a fellow member on the Lean Journey Study Mission to Japan. Here's an article about him in the Townsville Bulletin (click on image for a larger version):
Kevin Meyer described his experiences with Gemba Research's Japan Kaikaku Experience so I figure I should do the same for Enna's Lean Journey Study Mission to Japan. I'm a software person, not a manufacturing person so forgive any strangeness in what I observed and paid attention to.
----
On the Monday we visited two companies, the first being Aichi Sangyo, a welding technology company that has been operating for 71 years.
Some interesting points during the presentation by the Managing Director:
"Maybe a pure form of 'Agile' isn't appropriate for that team, in their context."
The problem has never been about whether teams are "pure" enough; the problem has always been an issue of complacency and laziness.
Actually, I don't know if laziness is the right word, but it's the attitude that we'll just do the things that are easy for our context and hope that the rest will just work itself out. It won't. And if you're paying attention, the world has become significantly less forgiving about that.
I've encountered a common perception, even amongst people in the Agile or Lean community, that positional authority is required in order to change anything. At the last Lean Summit Australia, John Shook corrected that perception. Now that he's started blogging, there's an entry I can reference the next time I'm told that "we can't succeed because we don't have enough authority":
Individuals in a lean management system take initiative to gain authorization to implement their ideas, manufacturing the authority they need when they need it: on-demand, just-in-time, “pull-based authority.” You will find no more appropriate occasion to exercise initiative, no better place to start than … right here and right now.
James Shore on why Agile is not just a 2 day certification course:
Or maybe we need to stop selling Agile. Maybe we need to say, "Agile is hard, and you can't master it by sitting through a two-day course." Maybe we need to be firm and say, "Sorry, if you don't use agile engineering practices, if you don't have high-bandwidth communication, and if you don't include a strong customer voice, you're not going to succeed. Try something else instead." Scrum is popular because it's easy--and that's part of the problem.
Kind of odd writing "No pain is a big pain" while I currently have a headache but Martin Fowler blogs an important point about Agile and Early Pain:
A few years ago I was talking with a client who told me something he didn't like about the agile approach we were using: "it's doesn't feel right to have these difficulties this early in the project". Contrary to his reaction, in my mind this early pain is one of the great benefits of an agile or indeed any iterative development process.In Toyota circles there's a phrase: "No problem is a big problem". The point is that in any system there are always problems so that if people are saying that there are no problems, then we have a bigger problem that people don't know how to see, or worse, that people are hiding problems.
Kevin Meyer at Evolving Excellence blogs about stand-up vs sit-down desks:
The companies cited several reasons for standing at desks, including the same health and ergonomic improvements mentioned above. But they also mentioned one other critical attribute of people that stand: it takes less energy for them to go walking, to the gemba for example. These people would immediately go and see what was going on, address problems faster, and be more efficient.
It's important to know when a defect occurs. That's what inspection (aka testing) is for. Inspection is non-value added activity but it is necessary to prevent leaking defects to your customer, whether that's the next process step or the end consumer.
Don't forget though that knowing when a defect occurs doesn't help you prevent defects. For that you need to know how and why.
Agile practitioners will typically respond to a defect with "What kind of test can we write to catch these types of defects?". This is good. But it's better if we first ask the question "How can the system be designed such that these type of defects can't occur?"
Effective detection is good; effective prevention is better.
If you use # of story points to set a target line, you must be wary about forgetting that the goal is not # of points done. If you can work out how to achieve the business goal by doing less points, that is better.
The is not about scoring the most points; this is about winning the game.
