Via Bill Bryson in A Short History of Nearly Everything, a joke by Richard Feynman about reasoning from known facts back to possible causes:
You know, the most amazing thing happened to me tonight. I saw a car with the license plate ARW 357. Can you imagine? Of all the millions of license plates in the state, what was the chance that I would see that particular one tonight? Amazing!
A brief Fast Company interview with K. Anders Ericsson on expertise:
Successful people spontaneously do things differently from those individuals who stagnate. They have different practice histories. Elite performers engage in what we call "deliberate practice"--an effortful activity designed to improve individual target performance. There has to be some way they're innovating in the way they do things.
Bob Sutton has an article up on Harvard Business Online called The War for Talent is Back with 5 lessons:
A lot has been written about the war for talent, and--if you actually take an evidence–based perspective--much of it is nonsense.
Via Dale Carnegie in How to Win Friends & Influence People,
I have no right to say anything that diminishes a man in his own eyes. What matters is not what I think of him, but what he thinks of himself. Hurting a man in his dignity is a crime.
-- Antoine de Saint-Exupery
Via FastCompany Fast Talk, Shari Ballard of Best Buy on innovation:
If you're going to turn on an innovation engine, a lot depends on whether managers listen for the brilliance in their employees' ideas that they can then help test, or whether they listen for what's wrong and why it won't work.
All the individual apologies might make people feel better but it sure seems to be emphasising precisely the wrong thinking process.
I don't like the phrase "best practice" because many people who use it aren't thinking. But there's a reason why we have libraries, frameworks, and patterns. Reinventing the wheel repeatedly requires a lot of usually unnecessary effort. We just want to be aware of what changes in terrain will require us to design another wheel.
A system that relies on individuals without any explicit process is relying on heroics and is unreliable.
A system that relies on a static process created and evolved without input from the team actually doing the work invites waste and is also unreliable.
Instead, the people doing the work should be taught the tools to think about, design, and evolve their own explicit process.
Patrick Masi mentioned an alternative to Planning Poker on the agileprojectmanagement mailing list:
Instead of playing planning poker on individual stories one at a time, you take the entire stack of stories and sort them from easiest to hardest on a table. After getting the stories in size order, you simply group them by points...here are the 1s, here are the 3s, here are the 5s, and so on.I like how this changes the emphasis and would be interested in trying it.
We've found this to be much faster and possibly more accurate than planning poker. The planning aspect of relative comparison - the key ingredient in release planning - is emphasized by this method.
From Mary Poppendieck on the leandevelopment mailing list (republished with permission):
Taiichi Ohno said: “Something is wrong if workers do not look around each day, find things that are tedious or boring, and then rewrite the procedures. Even last month’s manual should be out of date.”
Yoshio Shima, the current director, Toyoda Machine Works, said; “If you believe that standards are writ in stone, you will fail. You have to believe that standards are there to be changed.”
The idea of standards is to have a baseline against which change can be implemented using the scientific method: Hypothesis, experiment, measure, adopt those procedures which cause measurable improvement. If you do not have a ‘standard’ way of doing things, you do not have anything to change for the better. Toyota is about constant improvement. Improvement must be measured against something – namely today’s way of doing things. However, the game is to change that way constantly.
So teams at Toyota are constantly encouraged to challenge and change the standard. Yes they follow the standard – but anyone who is annoyed by a standard is expected to DO something about it, not just accept it. The standard is the baseline – today’s best known way of doing the job. Tomorrow it is expected to be changed, and those working with the standard are the ones expected to change it.
Standards are not there to be FOLLOWED, they are there to be IMPROVED.! And work teams are not just empowered but encouraged and LED to change the standard – constantly. That, in fact, is what work is all about, and what management is all about. How do we do this better? How do we constantly improve the standard?
That is why Ohno said that any standard that is over a month old is too old – it should have been improved by then. This isn’t going to happen unless the people doing the work own and constantly change their own standards.
Say you do test driven development. What does that MEAN? Today it means something to the team. There is a single sheet of paper on the wall that outlines how TDD works today. At the end of the week the team spends a couple of hours looking at its processes and they decide to do some experiments with a new twist on the TDD standard. The measurements over the week show that the new twist works. The single sheet of paper on the wall outlining the TDD approach used by the team is now changed. Everyone uses the new way. Yes, it’s better – but then – at the next weekly meeting – someone suggests a new twist. They agree to try some experiments around that. The experiments show that one of the suggestions works out very well and one does not improve things. A new sheet is posted on the wall about how TDD works now, with the good approach included. Now everyone uses the new way, and next meeting someone suggests yet another improvement……
That’s what standards are all about in Lean….they are constantly changing agreement of the team about how they will work together to produce the best software possible. They do not come from an outside process group, they come from the team, are owned by the team, followed by the team, and constantly updated by the team.
Steven M Smith has a couple interesting blog entries about rethinking stand-up meetings (Part One, Part Two). This kind of thinking is what I was trying to remind people of with my article. I'd love to hear from people who try out some of Steven's ideas.
When I started my career, I had to wear a tie every day. The next job required a suit. Management told me clothing built teamwork. I think standing up during a meeting is like wearing a tie. My teamwork isn't any better wearing a suit and tie than it is when I wear shorts and a t-shirt And I don't believe my team's effectiveness changes whether they are standing up or sitting down during a meeting.
The first one drives improvement; the second hides flaws.
Doing less releases of software systems to save costs/reduce risk is the same "batch and queue" problem that you see in manufacturing. And the solution is the same. Instead of hiding problems with batching, expose problems and remove them.
While waiting for an ad server to serve an ad on Zuji, I had a thought.
What if Google did travel? Or more specifically, what if someone followed the same mythological Google design philosophy of minimalism and speed. What would that travel site look like?
It would not have any ads on the landing page. Ads would instead be on results pages, would be contextual, and would be either text or thumbnail based. I'm quite sceptical that the average visitor is going to impulse buy trips to random locations anyway.
It would expect that people are engaged in a specific task, is highly focused on supporting that task, and is very wary of distracting from that task. For example, if I'm looking for a short trip within Australia within a particular price range, I shouldn't see anything about trips to Hong Kong for only $1645. This is why there are no ads on the landing page. No context.
Travel isn't like search though. There's probably value in looking at even more personalised suggested travel locations based on historical trips. "People who visited Uluru also visited Darwin", for example. Perhaps incorporated with Trip Advisor-like social travel features.
But first, I just want the page to load faster.
Keith Ray uses the analogy for refactoring but it also fits for unplanned changes in features and product direction.
"Isn't all that messing with steering wheel going to slow your car down? Why don't you just pick a direction for your car, lock your steering wheel in place, and stick to it?"To push the analogy further... if you want to avoid accidents, why not just stop the car altogether?
A quotation that I like from How to Win Friends & Influence People that is apparently originally from Stephen Grellet so I'll use that form:I expect to pass through this world but once. Any good, therefore, that I can do or any kindness I can show to any fellow creature, let me do it now. Let me not defer or neglect it for I shall not pass this way again.
Thanks to Kado Mansanori, It's Not Just Standing Up: Patterns for Daily Stand-up Meetings is now in Japanese.
Check it out.
When is Batch and Queue better than One Piece Flow?
Well perhaps if you're always building exactly the same thing, have no plans to switch what you're building for the foreseeable future, and the cost of inventory is negligible or free. In other words, in any kind of competitive environment, mostly never.
Now sometimes people ask the question, when is Waterfall better than Agile?
Never mind that the originator of the Waterfall model, Winston Royce, was using it as an example of something that is "risky and invites failure". Never mind that in that first 1968 NATO conference on software engineering, everyone pretty much agreed that Waterfall was a bad idea.
Let's ignore all that and just consider when batching and queuing unvalidated decisions is better than pulling a single minimal marketable feature without delays from request to delivery.
My flip answer these days is that Waterfall is never better than Agile but if you have no real competition, it doesn't matter, so don't worry about it. Besides "risky" and "invites failure" isn't guaranteed. You could always get lucky.
Tim O'Reilly calls for a Blogger's Code of Conduct in response to Kathy Sierra's problems with some online assholes (aka "cyber-bullies").
What annoys me is that Tim blogs about "taking responsibility" and he gets commenters who essentially say "I can't take responsibility because then I'll be legally liable".
So instead of the path of "Matz is nice, so we are nice", we have the path of "I'm a cowardly asshole so a lot of asshole cowards participate in my community."
Leaders and site owners have the capability, authority, and therefore responsibility to influence their communities. This is about establishing culture, not about establishing legally binding rules.
And that culture is that the asshole perspective is not required, desired, nor respected.
Ironically, I would normally use more polite language but you have Bob Sutton to thank for that.
