we need stories from more lean companies

From what I understand of the mass recalls from Toyota, the company lost its culture of quality first. Apparently some managers chose to prioritize growing the company, which caused a conflict of interest any time a problem was discovered--and managers didn't invest the resources to dig to the root cause of the problem. I think this story doesn't kill the credibility of the Toyota Production System, but I do think that it shows that even a 50-year-old culture can be compromised if a company tries to grow too fast. I think that Toyota still proves that average people can have a collective intelligence greater than their own individual strengths, but that this is very fragile.
So much of the lean literature and discussion is about Toyota that this has been rough news... we need to hear more stories about Dell, Zara, Amazon, and other lean companies. Where do you get this kind of news?

the revival of an oral tradition

Around 400 BCE, Socrates stated he didn't trust the written word for the following reasons:

• When the audience was confused, no one could respond to questions
• When we no longer train our memory to recall facts, we become more forgetful
• The written word cannot tailor the message to the audience, nor does it afford the art of performance

We in the Agile Community can appreciate this perspective; in fact we have embraced face-to-face communication in many ways, from encouraging teams to Sit Together, to promoting peer learning through user groups, conferences, and the Gordon Pask Award (or official Pask Award site), as well as the Agile Manifesto's explicit valuing of "working software over comprehensive documentation", and the popularity of story cards/backlogs that are so brief that they offer no more than a "promise for a conversation".

Yet why is the oral tradition so important? I think it is the most direct way to capitalize on the Wisdom of Crowds, to tap the collective intelligence of the people on our teams who are doing the work. When system requirements are written down, organizations tend to be more hierarchical, individuals more specialized, and more ceremony is involved in software processes. On the contrary, when we rely on oral communication, the organization tends to be more flat, relational, and responsibility is shared. This means that people who have to live with a design/process decision also have the ability to fix any mistakes... and so mistakes are fixed more readily.

There is more. Oral tradition fosters an environment where we begin to use words in a particular way--leading to inside jokes, even dialects--and gelled teams. Often the words used by team members helps them communicate faster and more precisely, at the same time as giving them a sense of belonging and identity. If corporate documentation attempts to standardize on certain word choices, this can damage the fabric of a team. On the other hand, if we allow our teams to specialize their language, grow close and communicate face-to-face, they'll make smarter decisions together, and work together to achieve goals better than if we rely on armchair architects.

Agile Besançon -- beautiful code

Last night at Agile Besançon we talked about beautiful code (based on the book Beau Code). We started with about a 25-minute implementation of a binary search algorithm, followed by compare/contrast of code, and an analysis from the book of common mistakes. Apparently this is much harder to implement than one would first expect, and only 10% of programmers can get it right in 2 hours. We all found vulnerabilities in our code (overflows, invalid assumptions about boundary or repeating cases), and it was a great opportunity to reflect on the assumptions we make as we code.

estimate-free still needs estimation

Some agile teams have moved to a kanban-style process in which there is no explicit planning game or estimation cycle--but I think it is an oversimplification to say there are no estimates in the process. How could a team have dozens of story cards approximately the same size if no one ever tried to predict the size in advance?

I posted the following to the XP list today, in response to the Task Underestimation and Overestimation thread:

To [estimate], or not to [estimate]; that is the question,
Whether 'tis nobler in the mind to suffer the slings and arrows of outrageous [deadlines],
or to [code bravely] against a sea of troubles, and by [overtime, to deliver]...

When I think about it, the experiments I've done to remove estimation from our stories were more about reducing the waste, than entirely removing estimates. Consider this--there must be *some* implicit estimation if we're going to slice our stories until they're all about the same size.

My current team has rejected estimation-free cards. We tend to like the size value on the card to remind us of the scope, to keep an urgency about the work, etc.

Still, we've also been unable to add estimates to all cards, using our current planning game; maybe 1/3 of the cards in an iteration show up without estimates at all, and it's too much BDUF to split the stories more. Instead, we treat an un-estimated story as a timeboxed research or a spike--the only expected result of these kinds of cards is a stack of new story cards with estimates. Sometimes the product owners pick how much time to invest in this research, in which case we'll tag the story cost as SPIKE:2, for example, to mean 2 points' worth of spike activity.