Thursday, October 20, 2011

Respect

A month long conflict at the construction site of the Zurich main train station ('HB' or Hauptbahnhof), boiled over this week, as workers tunneling under the station went on strike. Urine and excrement expelled by outhouse-style toilets in older trains continue to drip down on to the workers whenever a train with 'outhouse' toilets parks over the construction site. This issue was raised several months ago, but has now boiled over again.

Overall project leader Roland Kobel, chief of the two billion CHF 'diameter line', complained of "coercion" and hinted at legal action. "Every delay is wasting taxpayers money." The labor union is unimpressed, and is demanding contractual guarantees that the problem will be remedied before returning to work.

While Kobel is surely correct in his assessment, labor conflict could endanger his project, cause delays and raise the costs, he has missed the point of the root cause of the problems. The ongoing 'Urine Strike' reminds me a cartoon depiction of corporate life:


Roland Kobel has demotivated, unhappy workers because of the crap literally raining down on them. The workers have gone on the street in protest both because of the conditions and because a previous commitment to fix the problem was not -- in their eyes -- upheld. He is now being held accountable for those commitments.

How can Roland Kobel fix this problem and help ensure the success of his project? He should apply the values and practices of Radical Management to create a constructive, engaged atmosphere.
  • The key word is trust. Step 1 is to regain workers trust by quickly fixing the problem. Not fulfilling your commitments creates distrust, which in turn makes all discussions difficult. Distrust creates demotivated workers who 'work to rules' but no more. Trust goes much further than just fulfilling your commitments. Trust in your environment means freedom of fear of attack or exploitation. After periods of distrust, it is difficult to return to a culture of trust. This will require energy and change from both sides -- but before putting the responsibility for the trust issue on the workers, remember, the job of the leader is to lead.
  • The next word is respect. He needs to engage in respectful, eye-to-eye, adult-to-adult conversations with his workers. If the urine had been raining down on the Project Leader's office, how long would it have taken to get fixed? More importantly, what other improvements the construction process are being ignored because the project management doesn't listen? What cost savings are being lost, for problems that management is not aware of or wont fix. Will any of this have safety implications? Will his workers notice if substandard materials or unsafe practices were being used? Even if they did, when would management learn about it and react?
  • The third word is engagement.  They used to call this 'Management by Walking Around' or more recently 'go to the Gemba.' At Toyota, managers started their careers on the production line so they understood making cars. Roland Kobel should spend some of his time, in the tunnels, not just supervising, but really talking with the people doing the work of his project, and maybe even doing some of it himself! This way, he will understand both the reality of his project and the people making his vision real.
Financial success does not come by focusing on the money. A complex project is successful when the people with the vision and the people doing the work communicate effectively. They do the right things well and react to new things promptly. Trust, respect and engagement: the cornerstones of successful endeavors!

Monday, October 17, 2011

Scrum Breakfast Zurich:

Four years ago, I started the Scrum Breakfast in Zurich. As my tenure as moderator of the Scrum draws to a (temporary) close, I thought it would be interesting to have some presentations about the longer term effects of Scrum, so both the November and December Breakfasts will look at this topic in more depth.

Ernst Basler and Partner is known for their work in Infrastructure and Transportation Systems, Energy + Technology, Environment + Water, Resources and Climate Change. The Swiss Federal Office of Roads (ASTRA) contracted with them to develop the MISTRA Base System - a database of virtually all relevant data around roads and road building in Switzerland.

Last Christmas, EBP and the ASTRA decided to use Scrum to organize this project. The project had already been started. The requirements were extensive, complex and in many cases still under discussion, and the time was short. Scrum should help them master this situation.

Today the project has been running under Scrum for about 10 months. Nicole Stahel, Co-Manager of the Department „Informatik im Verkehrswesen“ will discuss the challenges, their solutions, and the longer term effects of switching to Scrum.

Registration and Info

Event: Scrum Breakfast in Zurich
Title: Scrum - an Experience Report after 10 Months of Experience
When: November 2, 2011, 8 am to 11am
Where: SwissICT, Vulkanstrasse 120, 8037 Zurich
Language: German
Registration and more Info: SwissICT

Reserve the Next Date / Going Away Toast

The Scrum Breakfast in December features Gerhard Andrey, co-Founder of Liip, a company where Scrum has truly entered the DNA at all levels. Liip was also my first external Scrum coaching / training assignment, so I am looking forward to this truly long term perspective.

As my sabbatical in the USA starts in January, this will also be my last Scrum Breakfast in Zurich for a while. I plan to bring some bubbly to open during networking part after the talk.

Mark the Date! December 7, 8am to 11am. (We should have the registration form online in a few days).

Sunday, October 16, 2011

Getting the CEO's attention

At the #sglon London Scrum Gathering Joe Justice and I lead an open space on how to get the CEO's attention. Our goal was to come up with at least three things to try. I could not stay for the afternoon wrap up, so here is a summary of what we discussed:

Ideas for getting top management buy-in (un sorted)
  • C-Level Training "offsite" (offsite is a management word which is well understood and has positive connotations). The goals is to 
    • Take away the fear and 
    • Give them tools for the new world
  • Apply the golden circle: From Why? (Business Goals) to How? to What? (See Video from TEDxPugetSound 'The Power of Why")
  • As an external consultant, demand participation from management two levels up.
  • Apply the AIDA process (Awareness, Interest, Desire, Action) or AIDAA (AIDA followed by Ability). You have to get people willing to listen (Aware) before they will even discuss your issues. TED Videos are good for building Awareness.
  • Give the CEO a book, e.g. Radical Management by Steve Denning or Beyond Budgeting or a presentation (e.g. John Rudd's Business Case for Agile talk at the Seattle Gathering or his article in AgileJournal of the same name)
  • How to get the CEO to open the book? S/he'll do it if s/he is curious! For events, start early, e.g. 7am to 10am, so that s/he has the feeling that s/he can get work done during the rest of the day.
Given that we have the CEO's attention, we next addressed the question, what should we ask the CEO to do? A few answers:
  • Change the incentives of the organization  (e.g. KPI's, bonuses, HR reviews...) to be Agile compatible
  • Be a good example for the new value system
  • Make handling impediments a priority for the organization
  • Encourage communities to take responsibility and solve problems
  • Create a vision for the company (e.g. Company 2.0)
  • Take regular Gemba walks (get close to what is going on and visit real work getting done)
  • Measure and respond to Henrik Kniberg's Happiness Metric
And as a last thought, how can you get in a position to deliver your message. How do you meet in the "elevator" -- so you can deliver your "elevator pitch." Get close to him physically - Breakfast, Lunch, Hotels - any place where you can meet him/her by "accident" -- but no stalking...!

I would like to thank everyone who participated. I got some really great ideas (and I know what the Washington DC version of the Scrum breakfast will be called!) and look forward to trying them out!

Here are the pictures of the flip-charts we produced:


Friday, October 14, 2011

Changes

Shortly after the Lean Agile Scrum Conference, DasScrumTeam announced that I will be leaving the company, effective end of December. Here is an extract of that email (translated):
We, DasScrumTeam AG, established our company in 2009 and started successfully together. Our training and coaching structure meets the needs of our customers and our Certified Scrum Master and Scrum Product Owner training sessions are very popular. With the knowledge that the basic values ​​and practical aspects of Scrum correspond well to the requirements of a modern enterprise, we are very motivated to share our know-how with our customers. We do not forget to also expand our own knowledge.

Peter Stevens is traveling in the near future for several months in the U.S. to be active in the exciting and important areas of Radical Management. So he will leave DasScrumTeam AG at the end of September. Besides his own training and consulting assignments, Peter served as Managing Director and was responsible for marketing and sales as well as for building the business organization. His excellent work made it possible to launch DasScrumTeam. As Peter always fulfilled his duties with full power and this won't be possible during his period in the U.S., he left our company. Peter Stevens will be working in the U.S. with the respected expert in the field of radical management, Steve Denning. We are convinced that Peter will come back to Europe with many exciting experiences and a great deal of new knowledge.

I will be in Switzerland until Mid January. After that, my family and I will travel for 6 months to the USA and we plan to be back in time for the 2011/2012 school year. At that time I will be again focusing on bringing the values, principles and practices of Scrum and Radical Management back to Switzerland.

BTW - for the moment, you can contact me at my old sierra-charlie mail address, or use the contact form.

The Car that Scrum Built

You have heard the objections: "Scrum is great for software, but we're doing hardware." Or, "we're doing embedded. Scrum won't work here." Or, "Would you really build a bridge with Scrum?"

Well maybe not a bridge, but how about a car?

Remember the Ansari X PRIZE? The winner N328KF by Burt Rutan and Paul Allen is now the basis for Virgin Galactic's space tourism venture. In 2008, the Progressive Insurance Automotive X Prize competition put out a 10 Million Dollar prize for the first/best company to to produce a car that:
  1. you could actually drive on the street
  2. would achieve the equivalent of 100 mpg (2.35ltr/100km) and 200g/km well to road CO2 emmissions
  3. has a reasonably convincing plan for going into production by 2014.
Joe Justice, a soft-spoken Agilist, nerd and black belt kung-fu expert, was intrigued and, somewhat inadvertently, launched a Linux or Wikipedia-like project to create an entry in the class 'mainstream' (i.e. it should look like a car you would actually want to drive).

Three months later they had an entry. They didn't win, but they were number 10 (in a field that had declined from 136 entrants to 43 in the face of changing requirements). What was unique about this approach?
  1. Brilliant, knowledgeable people did this for fun in their spare time! Much like open source.
  2. They used Scrum as the management framework
  3. They used Pairing, Test Driven Development, Object Orientation, Refactoring and other XP practices to actually do the design and build the car.

I am not sure I can do justice to his talk in the scope of a blog article. I don't believe Joe's Scrum Gathering talk was filmed, but here is a similar talk he gave to the to the American Council of Engineering Companies Leadership Seminar in Cle Elum, WA. You can feel the next chapter of 'The Machine the Changed the World' being written as we watch:



 



Tuesday, October 11, 2011

FAMOZ: Let's treat project failures like airplane crashes

Whenever an airliner crashes, two questions demand answers:
  • Who is responsible? -- so we can punish them, sue them or put them in jail (or gain advantage for ourselves)
  • How did this happen? -- so we can prevent accidents like this in the future. 
Oddly enough, if the investigation seeks to answer the first question, it becomes very difficult to achieve the goal of the second question. If people are afraid of punishment, they are reluctant to provide information which can and will be used against them. The investigation of airline incidents always focus on the second question and aviation has enjoyed an excellent and improving safety record because of it.

The city of Zurich has "pulled the plug" on "ELUSA" (or FAMOZ, as it was originally known). This system to integrate the operations of four departments of the city's social services office was originally budgeted at 11 million CHF, but after several rounds of additional financing was now expected to cost 29 million. Stopping the project will limit the costs to 26 Million. The politician are speaking of a disaster, citizens are expressing disgust, and the suppliers are saying 'we're being made into scapegoats.'

Is this case exceptional? According to the Tages-Anzeiger, 75% of the functionality is completed and operational, the costs are 235% of the original budget, and the project was restarted at least once. According to criteria of the Standish group's CHAOS report, this large project would be considered challenged: "completed and operational but over-budget, over the time estimate, and offers fewer features and functions than originally specified.

According to the CHAOS report, 61.5% of all large projects are challenged, only 9% are successful and the rest fail. 94% of all challenged or failed projects restart at least once. The average cost overrun is about 180% of the original budget. So this project is in many ways typical and based on the numbers comes into the "top 25%" of project failures.

Why did this project have to end in a disaster? 75% of the functionality is available. According to other work of the Standish Group, 64% of the functionality developed in such projects is seldom or never used. So if the project had implemented the 'right' 36% first, i.e. the functionality that is needed frequently or every day, the project could have been stopped long ago and as a success and at a figure close to the original budget.

Why did this crash have to happen? The first Chaos report was published in 1995. This is not the first or even the biggest 'plane crash' of a Swiss government IT project. If this had been an airplane crash, the safety authorities would be crawling over the scene of the accident; politicians and the flying public would demand that the causes be identified and the

Why can't an IT failure be treated like a plane crash? Why are failures used for political gain rather than as a basis for learning? Why can't we have an IT Project Safety Board, which investigates "accidents" and makes recommendations to prevent similar incidents in the future?





Thursday, October 6, 2011

Remembering Heaven

A Respectful Approach to Introducing Scrum (or some other framework).

At the Lean Agile Scrum Conference in Zurich, David Anderson explained the basic approach of Kanban:
  1. Start with what you do now
  2. Agree to pursue incremental, evolutionary change
  3. Initially, respect current processes, roles, responsibilities & job titles
The implication of course is that Scrum is disrespectful because Scrum comes with new roles. His comments were echoed by many participants. Given that Respect is a core value of Scrum, I was surprised at this insinuation. Why do so many people seem to find the Scrum approach disrespectful?


Here is how I prefer to introduce Scrum.

When I first read Ken Schwaber's 'Agile Project Management with Scrum', there was a paragraph which really got my attention: 'Remember your best project? How was it?'

In my case, I was working for the SIG in Neuhausen. Urban Wymann, my customer / project leader was responsible for introducing some 60 Sun Workstations into the CAD department. His goal was to install and manage those systems with a reasonable amount of effort. I had some ideas on how to do application distribution, so he gave me a week to try out my idea. After a week, I demoed what I had written; he liked it and gave me feedback about where the next step should go. We continued on that basis -- one week cycles of demo, discuss, do, demo -- through the entire summer. By the end of the summer, the 'Stevens Tools', were able to automatically install, update and configure a network of 60 workstations spread over two sites with minimal effort on the part of the system manager. This work started in 1993 and the Stevens Tools became the basis of my career for the next 10 years.

See any similarities to Scrum? I sure did. When I read that sentence in Ken's book, I was hooked. All of sudden I understood exactly what he was talking about and I knew that Scrum was right for me.

How effective would your efforts be if you colleagues, managers and stakeholders could have a 'Eureka!' moment like that?

Today when I go to a customer for the first time to hold an 'Intro to Scrum' workshop, the first thing I do is ask them -- as a group -- to remember their best projects and share those stories with each other. (I'll skip the details of how I do the moderation - it is basically Seth Kahan's Jumpstart Storytelling). The group eventually selects the best stories (top 3 or so) and listens to them in plenum.

After everyone has heard the best examples of a good project, I show them a list of attributes of successful projects and ask them which ones they see in their stories. Although my list is a pretty good one, their list often has some interesting additions. Those (and the things they missed) are the basis for an interesting discussion on how to best move forward.

Based on their stories they tell, I can usually see if Scrum or Kanban is a good match.  I have even run into cases where neither is a good match - in this case, the people need to invent something new, and that's OK.

By going through this exercise, they focus on what's really important to succeeding. Assuming their patterns are a good match with Scrum (and they usually are), then we can go look and see how Scrum helps them achieve the things they need to be succussful. More importantly, the story telling mode gets them into really thinking about the issues instead of reacting defensively.

So how do I explain the principles of Scrum? Easy:
  1. Remember your best project? Strive to make this project like your best project.
  2. Do something which is pretty good, and improve from there. (Inspect and Adapt)
  3. Timebox (so Inspect and Adapt works quickly)
  4. Trust the team
Oh yes, and replacing a culture of fear with a culture of trust is one of the most important things you can do to improve the productivity and creativity in your organization.

And still, I am left with the question, Why do so many people seem to find the Scrum approach disrespectful?