Friday, November 20, 2009

Paper Clip Consulting

Remember this guy. He used to pop-up when you least expected him and offered up information about something you already knew.

I'm sometimes reminded of Clippy when I hear the rhetoric from some in our agile community.

We're at an inflection point right now. The pragmatists and the conservatives are realizing the fallacy of large upfront planning.

As teams from these later adopters are striving to become leaner and more agile they struggle with the inertia that is inherent in large organizations.

  • They know that co-located teams are more successful but they prefer an environment that extends the benefits of working from home.
  • They know that it is much more efficient to work on one task at a time but someone way above their pay grade won't let them have such a single minded focus. This is not a battle they can win right now.
  • They know that value can be delivered faster if testing can be pulled forward yet they don't have budget to buy the tools they need.
For such decisions Clippy always knows the right answers for everybody. But Clippy doesn’t have to walk in their shoes and it won’t be Clippy who gets fired for taking a risk.
Maybe Clippy needs to listen to Norm Kerth (from his book Project Retrospectives)

or as my colleague Julie Chickering says:

"I think we need to acknowledge that there are parts of organizations that will be less agile than others while moving from traditional to agile projects. That the big ole ship cant turn on a dime. To me this is part of being the trusted partner."

As you strive to become leaner, more agile, you don't need Paper Clip Consulting you need a trusted partner. You need someone that will begin with the end in mind yet not seek to get there immediately. A trusted partner will take the time to understand your environment, accept that there are always constraints and help you establish a cadence of continuous improvement.

Tuesday, August 18, 2009

All For One, One For All

I was struck recently by the low energy of a daily stand-up that did not signal the end. Some people headed back to work, others started follow-on discussions, others were not sure if the meeting was over or not. The lack of a clear sign that the stand-up is over can lead to problems:
  • People feeling left out
  • Not having the right people there when decisions are made
  • Time wasted on interesting rather than useful discussions
  • People starting to question the merits of a daily stand-up that consumes a lot of team capacity

One way to avoid a never-ending stand-up is to have a clear signal at the end.

The ScrumMaster is the facilitator for the daily stand-up and they shouldn't assume the authority to close the meeting. I like a signal coming from anyone (not necessarily the ScrumMaster) followed by a response from all.

A friend of mine enjoys climbing. At the end of his daily stand-ups he would signal "On Belay?" and the rest of the team would respond "Belay On".

Sports teams are good at signaling the end of the huddle. One of my favorites is the team portrayed in the classic book by Alexandre Dumas. The Three Musketeers would end their stand-ups with a single cry of "All for one" which then be followed by the refrain "and one for all"

What are your favorite signals?

Wednesday, June 3, 2009

Chi Development: The Process Is The Goal

Last year I entered the Marine Corps Marathon. I'd never ran more than 10K in my whole life but I felt the urge to do a marathon just once. Of course I didn't want to just finish I had to get close to my friend Dave's time who did 3:17 in the Loch Ness Marathon. So I started an ambitious training program and as time progressed and I was not getting any faster I started training more. 4 weeks before the race I had to pull out with a stress fracture and slightly torn achilles tendon.

I failed to heed my own counsel. As an agile coach I tell my students that the number one cause for failure is scaling too fast and you need to start with baby steps.

This year I'm entered again but I'm going to take it easier with the training and not care how fast I go in the race.

Looking for a better way to train I was intrigued by Danny Driver's book Chi Running: A Revolutionary Approach To Effortless, Injury Free Running.

I was fascinated reading about the Chi Running Method and Mind-Set.

The optimal conditions for running and the fundamentals of the method:
  • Great posture
  • Relaxed limbs
  • Loose joints
  • Engaged core muscles
  • A focused mind
  • Good breathtaking technique
The benefits:
  • Great posture
  • Relaxed limbs
  • Loose joints
  • Engaged core muscles
  • A focused mind
  • Good breathtaking technique
  • More energy!
His point. The process is the goal.

Similarly with agile/lean teams the fundamentals:
  • Deliver highest value first
  • Release early and often
  • Shared vision
  • Empowered collaborative decision making
  • Engaged customer proxy
  • Sustainable pace
The benefits:
  • Deliver highest value first
  • Release early and often
  • Shared vision
  • Empowered collaborative decision making
  • Engaged customer proxy
  • Sustainable pace
  • More energy!

Tuesday, June 2, 2009

I Don't Like MoSCoW



It's OK Sergey and Boris I'm not referring to the capital city of your homeland with it's rich history, wonderful literates and great hockey players.

Instead I'm referring to the technique that the DSDM consortium recommends for prioritizing backlog items.


  • Must Haves
  • Should Haves
  • Could Haves
  • Won’t Have (this time around).
There are a couple of problems with this technique and in my classes my students spot them right away.
  1. The customer always thinks everything is important and therefore the distribution of the backlog items is hopelessly skewed towards the Must Haves.
  2. If we are planning an iteration and we have only room left to take on one more backlog item and we have two Must Haves which one gets planned into the iteration. Of course we should ask the customer but what if they're not there.
Many customers think that promoting backlog items to Must Haves is exercising better control over delivery but it is not. A customer who cannot differentiate between the importance of backlog items is ceding control to the delivery team. Work has to be sequenced and if the customer will not choose then the team will.

A better technique is to rank backlog items such that no two items have the same priority. In this instance it is very clear the preferred order of delivery.


Tuesday, May 26, 2009

Pick Up Your Clothes

With a four year old and a six year old familiar sayings around our house are "pick up your toys", "pick up your clothes", "brush your teeth", "get dressed". Of course we could get our short-term objectives met much faster if we did these tasks but we don't. We understand the importance of our children developing their own awareness of basic hygiene, cleanliness and developing their own skills that will one day help them become independent.

Giora Morein tells us that ScrumMasters's should track hours remaining on a sprint
Time-tracking is a nuisance and a distraction for these motivated folks. To the ScrumMaster and the team, however, it is extremely important.
While I don't question Giora's good intentions and there is no doubt this approach is expeditious I believe it is worth striving to have the team updating their own hours remaining.

There are many many benefits to being a member of a self-organizing, self-managing team but with those benefits also comes responsibility and accountability. Here are some dangers I see in team's not updating their hours remaining:

  • They become less accountable for the number they provide
  • They don't understand the mechanisms of the self-managing, self-organizing team
  • They become dependent on the Scrum Master
  • The Scrum Master becomes frustrated and disillusioned
  • The Scrum Masters morphs from a leadership role to a management role
  • The team starts to revert to form

Thursday, April 30, 2009

Microcosym in a Teacup

If you haven't already heard Matt Aimonetti’s talk “CouchDB + Ruby: Perform Like a Pr0n Star.” at the Golden Gate Ruby Conference caused quite the stir.

There are so many different angles to explore. Here's some that come to mind:
  1. Although I was not offended this crossed my standards of good taste
  2. Although hopefully not his best example Matt obviously has a talent for creating presentations
  3. Like Giles Bowkett says if you're going to apologize then make sure you really mean it. If you don't, then defend your position
  4. If someone from a different sexual or ethical group says they're offended then you have to take their word for it. You have and will never have a basis to refute their argument. Washington Redskins take note.
  5. Strange that Sarah Allen didn't leave. I admire Ken Schwaber's work but recall not staying for his presentations at Agile 2007. His (lesser) crime: he was boring.
  6. In a country where the Sopranos is such a popular show why is it not OK to have a few PG-13 pictures in a presentation
  7. In a male dominated industry is it discrimination to treat others differently or is it discrimination to not
  8. This presentation probably would have been a hit in the UK. I'm hoping John is alluding to my British upbringing when he remarked that "of course you weren't offended"
  9. Why are the US and the UK (two countries I love) so different
  10. But of course this was not the UK so Matt really broke rule #1: Know Your Audience

Thursday, March 20, 2008

Fortune Cookies and Process Improvement

Yesterday I was at the Rational Comes To You Seminar that we hosted in Chicago. I presented a favorite topic of mine Agile Risk Management. The keynote speaker was Per Kroll. Per talked about the Agile Practice Library that the Eclipse Process Framework team are developing, an initiative that we are actively involved in. Dan Gilio and Frank Du Pont gave a presentation on Agility and Compliance and laid to to rest perceptions that agility and compliance are not polar opposites. After all, think about it, how does a waterfall process help with compliance? Great job Dan and Frank.

I was listening to NPR on the last leg of my journey home from Chicago. Michele Norris was interviewing Jennifer 8 Lee about her upcoming book The Fortune Cookie Chronicles. Jennifer was born in America of Chinese parents and was perplexed why the food in the little white takeout boxes was so different from her mother's traditional Chinese dishes. Then when Jennifer was 13 she discovered fortune cookies weren't Chinese. "It was a disconcerting discovery, like I was adopted and there was no Santa Claus at the same time. In a way, I had bought into the myth of what is really 'Chinese,'" she says.

This led to an obsession that eventually led to her upcoming book. Jennifer's research yielded that an overwhelming majority of fortune-cookie "fortunes" originate from one of two sources: Wonton Food in New York City or Steven Yang, who works out of a warehouse in California where fortune writers craft bits of wisdom that meet an American audience's expectations. Amusingly these fortunes don't translate well in Asia where negative feedback is welcomed because it is seen as essential for improvement.

What an interesting day. It started out with Per talking about agile practices and expounding on lean methods and it ends up back at lean with a real-world Kaizen example. For those Fortune Cookie afficionados out there this blog would not be complete without me adding that shortly after listening to this story I ended up sound asleep "in bed".

Thursday, November 1, 2007

The Search for Scorpion

On May 27, 1968 USS Scorpion was reported missing with ninety-nine men on board. Nobody had any idea where Scorpion was or what had happened to her. All they knew was that the 3,500 ton nuclear attack submarine was due back in Norfolk, VA and had failed to arrive.

Dr. John Craven, the Chief Scientist of the U.S. Navy's Special Projects Division had been instrumental in locating a missing Hydrogen Bomb off the coast of Spain on January 17, 1966 and he was to play a key role in locating Scorpion.

Craven and his team of mathematical consultants launched a search that would take so many twists and leave him so at odds with the rest of the navy that he himself would begin to wonder whether he had indeed gone mad.

Craven and his team together with Wilton Hardy of the Naval Research laboratory and his team of acoustic experts examined the acoustic data. Hardy found it first. Right on Scorpion's track was an explosion strong enough to tear through a steel hull and 91 seconds later there was a series of much louder blasts as the submarine began imploding as it sank to the bottom.

The site of the first explosion – codenamed Point Oscar marked where the search would begin. The water at Point Oscar was 2 miles deep. The Scorpion would have stopped imploding about 7,000 feet before she hit bottom, cutting of the acoustic trail. Depending on how fast she had been traveling, and in what direction, and depending on the force of the implosion and the position of her stern planes as she fell, she could have been thrown miles further. All that meant that the submarine could be anywhere within a 20-mile-wide circle, leaving a vast unknown universe to search.

Craven began digging for more evidence. He set about trying to map each implosion in the hope that he could figure out how far scorpion had traveled before the final sounds of her loss subsided. Craven's map showed that Scorpion had not been traveling west toward Norfolk during her final moments. Instead Craven's calculation surprisingly showed that the submarine had been moving east back toward the Mediterranean. Craven asked several captains and admirals "what would make a submarine go in the wrong direction". Each time he got the same answer. A submarine turns around 180 degrees when a torpedo activates when it is still on board. The boat turns because that triggers fail-safe devices on the torpedo shutting it down.

The only problem was that nobody of any rank from the chief of naval operations on down thought Craven could be right. Craven persisted, he began to mathematically construct a map of the ocean bottom, using Bayes' Theorem of subjective probability to draw on the knowledge that even experts are not consciously aware they have. After Craven explained to the Navy brass that he was going to use a system of Las Vegas-style bets to factor the value of hunch into his data, some of the operational commanders were convinced that he had gone completely over the edge.

Undeterred Craven asked a group of submarine and salvage experts to bet on the probability of each of the different scenarios being considered to explain scorpions loss. Once the bets were completed Craven sat down to draw a probability map. The calculations concluded that the scorpion was east of Point Oscar, 400 miles from the Azores on the edge of the Sargasso Sea.

Years later mathematicians would write a book based on their work with Craven entitled Theory of Optimal Search, the U.S. Coast Guard would adopt the method for search and rescue and the navy would use Craven's interpretation of Bayes' Theorem to locate sunken ordnance in the Suez Canal.

Yet in the Scorpion search naval officers just shook their heads and continued to look to the west of Point Oscar. Months passed by with no trace of Scorpion. By October with the weather worsening Craven finally persuaded the navy to look east of Point Oscar. On October 29, five months after she had been reported missing Scorpion was found within 220 yds of where Craven, his mathematicians and a group of experts betting for a bottle of Scotch had said she would be.

The above is an abridged version of a chapter in the book Blind Mans's Bluff: The Untold Story of American Submarine Espionage. The book is a great read but one might wonder how it relates to our business.

There are many good lessons to be learned from the book but what is particularly interesting is the technique Craven used to draw on the knowledge that even experts are not consciously aware they have. Not only that but it is impressive the quality of the estimates. We deal with uncertainty in our line of business. Most notably in risk management.

When we implemented our agile risk management technique we used a modified Delphi technique to increase our confidence in a series of subjective measures. However, the word subjective always bothered me. At the time intuitively I knew that behind the scenes of every expert judgment was a series of decisions based on real experiences through the years and just because those data points were not discussed or written down did not mean they did not exist. They perhaps just flashed through someone's mind quicker than a value remains in a register on a chip but they were there. I really did not have any science to back up this theory but then I read Blind Mans Bluff and there it was, a real-life example that worked and was backed up by science. I think if we had known about Craven's work and Bayes' Theorem at the time we might have been able to make a much stronger case for the validity of our approach. An approach that at the time yielded some alarmingly high numbers yet reflecting on them now, our team of experts were also spot-on.

Tuesday, August 28, 2007

Kaizen

Only after American carmakers had exhausted every other explanation for Toyota's success - an undervalued yen, a docile workforce, Japanese culture, superior automation - were they finally able to admit that Toyota's real advantage was its ability to harness the intellect of 'ordinary' employees.", "Management Innovation" by Gary Hamel, Harvard Business Review, February, 2006

Taiichi Ohno (February 29, 1912 - May 28, 1990) is considered to be the father of the Toyota Production System, also known as Lean Manufacturing.

When I attended Mary Poppendieck's presentation on The Role of Leadership in Software Development at Agile 2007 she talked a lot about Ohno and had a marvelous quote from his book Workplace Management.

There is something called standard work, but standards should be changed constantly. If you think of the standard as the best you can do, it's all over. The standard work is only a baseline for doing further kaizen [change for the better]. Standards are set arbitrarily by humans, so how can they not change? You should not create these away from the job. See what is happening on the gemba [workplace] and write it down.

When creating Standard Work, it will be difficult to establish a standard if you are trying to achieve 'the best way.' This is a big mistake. Document exactly what you are doing now. If you make it better than it is now, it is kaizen. If not, and you establish the best possible way, the motivation for kaizen will be gone.

One way of motivating people to do kaizen is to create a poor standard. But don't make it too bad. Without some standard, you can't say 'We made it better' because there is nothing to compare it to, so you must create a standard for comparison.

We need to use the words 'you made' as in 'follow the decisions you made.' When we say 'they were made' people feel like it was forced upon them. When a decision is made, we need to ask who made the decision. Since you also have the authority to decide, if you decide, you must at least follow your decision, and then this will not be forced upon you at all.

But in the beginning, you must perform the Standard Work, and as you do, you should find things you don't like, and you will think of one kaizen idea after another. Then you should implement these ideas right away, and make this the new standard.

Years ago, I made them hang the standard work documents on the shop floor. After a year I said to a team leader, 'The color of the paper has changed, which means you have been doing it the same way, so you have been a salary thief for the last year.' I said 'What do you come to work to do each day? If you are observing every day you ought to be finding things you don't like, and rewriting the standard immediately. Even if the document hanging there is from last month, this is wrong.'

At Toyota in the beginning we had the team leaders write down the dates on the standard work sheets when they hung them. This gave me a good reason to scold the team leaders, saying 'Have you been goofing off all month?' If it takes one or two months to create these documents, this is nonsense.

I found this very profound. I saw ghosts of many failed and failing projects pass before my very eyes. First with Rational and then Number Six I've been lucky enough to work with some great people with a passion for change. They find it hard when customers do not embrace improvement so readily. I don't think they set expectations that cannot be met but, they are perhaps naive to assume they will be met immediately.

Maybe it's time to consign to the scrap heap that silly phrase "set the bar high". After all, a high jumper may have lofty ambitions but, they do not set the bar high, a high jumper sets the bar low and then gradually increases the height as they become more comfortable.

Maybe we can draw some inspiration from Taiichi Ohno:
  • Set realistic goals for improvement, goals that can be achieved in the short term
  • Continuously challenge and improve processes
  • Define processes at the workplace not in the laboratory
  • Remember that people are much more likely to follow through on a commitment they made than one that was forced upon them

Tuesday, August 7, 2007

A Process Definition Is Not a Process

It hit the desk with a thud. "What's that?" "Oh, that's the Risk Management Plan." "Great, let's see the Risk List?" "Oh, we didn't bring that, it's on Tony's laptop somewhere."

This was a real conversation. We were meeting with some of the staff in the PMO and they had brought their Risk Management Plan for review. It was an impressive document with 65 pages of everything you ever needed to know about risk management. This was the culmination of weeks and weeks of effort and many meetings. The sad thing is that in the time they had spent documenting the process they could have collected, analyzed and responded to all the program's risks and been in a much better position to ensure program success.

You don't need to spend weeks and weeks defining a risk management process, it has already been documented to the finest level of detail and there's not a lot of options to ponder. Likewise, you don't need to spend hundreds of thousands of dollars to be told that you need a change control board (sadly another true story).

As real process engineers will tell you, a process definition is not a process. Instead of spending months and months documenting processes it is far more effective to reference existing documentation. Keep the process simple and transparent so that it can be easily implemented and iterate often in the early stages to right size the process to fit the team. Remember a process definition is not read but referenced, so make sure it is small, online and referenceable.