Friday, November 27, 2009

Making Change Happen in Your Organization

Last Monday, I spoke at the CHOOSE Choose Forum on Human-centric Software Development on how to introduce change into an organization. The talk is based on my experience introducing Scrum to large organizations and building the Lean-Agile-Scrum community in Switzerland. Here's the talk, hosted on Slideshare (where you can download the annotated PDF):
Introducing Change to Your Organization
BTW - It looks better in full screen mode

Thursday, November 26, 2009

Interrupts Considered Harmful

A True Story:
Setting: a development team which is responsible for a production application. This application processes millions of dollars per day in financial transactions, so it has to run.

As the company had just put our a major release, a developer had to work late shift, just in case something happened. The release had been in production for a few weeks, so the worst problems were over.

A few nights ago, it was Joe's turn for night duty. Joe (not his real name) is a good developer who can be counted on to move one, sometimes two tickets from waiting, through in progress, to done every day.

There were no production problems that night, so Joe could work on his development tasks. How many tickets did Joe finish that night?

Joe was between 2 1/2 and 5 times as productive working at night. Why? Because no one interrupted him.

At the Choose Forum on Human-centric Software Development, Prof. Andrew Ko reported his experience studying software developers at Microsoft: On the average a developer works 10 minutes before having to do a task switch. "Actually completing a task was seldom the reason for a task switch," he noted laconically. The most common reasons were interruptions, ranging from phone calls, IM messages, E-Mails, visits from co-workers, etc.

I think daily interruptions are a kind of micro-multitasking. Every task switch (especially when developing) causes you to lose context. When you come back to the task, you have to figure out where you were, and you've probably forgotten some vital information on the way, which you have to recreate.

Could there really be a factor of 3 potential to improve productivity be removing interruptions? What impact do interrupts have on your work? What do you do to keep interruptions under control?

Saturday, November 21, 2009

Italian Agile Day: Fixed Price Projects

Yesterday it was my privilege and honor to give the keynote speech at the 6th Italian Agile Day. 400 Agilists gathered at the Savoia in Bologna to share their experiences. And there were even curious skeptics from company management, who wanted to find out about about Agile and whether it could help their problems. Lots of energy.

I also found some surprising obstacles. I was very surprised about the class warfare tones I heard in the discussions. Much of Italy's best talent goes looking for work in London or Munich where their work is more appreciated: the pay is substantially higher than in Italy. One of the cornerstones of Agile is the idea of building trust, e.g. between the developers who build the product and the managers who request it. I wonder how well this culture will do in an atmosphere of contention over pay, benefits and respect.

My favorite quote from the Coaching Workshop: "My name is Luca and I am a Waterfall-aholic". "Hello Luka" everyone replied. Reminded me of the sharks in Finding Nemo.

My talk was about doing fix priced projects with Agile. I believe that Agile is the only way to go for a fixed price project. (I believe there are better approaches than fixed price projects, but that is another story.). It's very simple. Under Agile, a project is 50% complete when 50% of the features have been completed. With non iterative processes that don't regularly produce a product in a stable state, you just don't know how complete it is.

Completing fixed price projects is a lot about risk management, so in the presentation, I talk about how to identify and minimize the risk in the bidding, planning & execution stages of a fixed-price, fixed-scope software development project.

Thursday, November 12, 2009

Risks and Side Effects of Scrum

Yesterday evening, Alain Guilieri, Ralph Jocham & I had the privilege of speaking at the SwissICT Event 'Risks and Side Effects of Lean, Agile & Scrum.'

I talked about the challenges of changing an organization. Ralph focused on what can go wrong, in particular the important difference between an Certified ScrumMaster a Certified Scrum Practitioner (the latter in a meaningful certification) and the importance of top engineering practices. And Alain provided the Voice of the Customer: A department head in a Financial Institution who introduced Scrum two years ago and reported on his challenges, solutions and successes.

Some 60 people attended and many asked for the presentations. You can download them all here, Presentations from 'Risiken und Nebenwirkungen von Lean Agile und Scrum'.

Friday, November 6, 2009

Scrum Breakfast in Zürich: Breaking Through Corporate Gridlock

Everyone who works in a large organization knows that such organizations can become inflexible and unresponsive. Rules and regulations dominate, office politics are more important than common sense in making decisions, and sacred cows are not to be touched.

How do we break through this problem? In December, the Scrum Breakfast will address this challenge with the most interactive Scrum Breakfast ever. Structured as an Open Space, led by internationally known coach Deborah Hartmann Preuss, and driven by the questions and expertise of you, the participants, this event promises be a unique effective investigation into the challenge of making change happen where you work.

We particularly want to invite to Mid-Level Managers, Scrum Masters and anyone else who is trying to make their organizations more flexible and responsive.

When: December 2, 2009
Where: SwissICT, Vulkanstrasse 120 8048 Zürich
Registration: SwissICT

Time: Doors open at 8am for coffee and registration, we start at 8.35. As an open space event, the law of two feet applies, so you can stay as long as you feel appropriate. We'll finish by 11.00

Wednesday, November 4, 2009

I want it all! I want it now!

If only Santa Clause would deliver software. Life would be so much easier. Unfortunately he doesn't, and delivering working software which meets business needs is still a difficult challenge. According to a just published survey by OOSE, nearly 60% of all "classic" projects and even 1/3 of all agile projects do not succeed. How do you make sure, your project is not one of them?

Today I am giving a talk and the SAQ Software Tester Forum, From Wish List to Running System: How to Get What You Want. You can't get everything you want, but you can get what you really need. Here are the slides to my talk.

Monday, November 2, 2009

Experience with Lean Software Development

Scrum Breakfast in November

The Challenge: Raise your release tempo from 2 to 4 releases per year, with out changing the quantity of functionality. The applications remain complex. Modifications and renovations must still be possible. This was the challenge faced by Swisscom Wholesale AG. The Solution: Introduce Lean Software Development.

What consequences did this decision have on the existing organization and their productivity? Which agile approaches were selected? Roland Grieder, former Department Manager for Software Development at Swisscom Wholesale will answer these and other questions.

The talk is in German.

There is still space available: Info, Registration
When: 04. November 2009
Where: SwissICT, Vulkanstrasse 120 in Zürich-Altstetten

P.S. I will be giving a talk on 'Getting What You Want: From Mandate to Acceptance' on the same day at the SAQ Agile Testing Day. Fredi Schmidli will moderate Wednesday's Scrum Breakfast.

Sunday, November 1, 2009

Managers, Impediments, Responsibility. Oh my!

Here's the situation: a department with 5 development teams, several of which are starting to do Scrum. The Scrum Masters have a problem. They couldn't fix impediments. Not being part of management, they weren't taken seriously by the rest of the organization. Escalating every second impediment to management wasn't working either. When impediments don't get fixed, Scrum doesn't work and everybody gets demotivated. Here's a shot at solving the problem...

One: Identify an Escalation Team (ET) who will be responsible for handling issues when the ScrumMasters get stuck. This consists of the Department Manager and his immediate reports. One of the ScrumMasters is also ScrumMaster for this group.

Two, following Karl Scotland's description of Kanban, embark on a four step process:
  1. Map the value stream
  2. Visualize the process with a Kanban board
  3. Limit WIP to achieve focus and flow
  4. Establish Cadence
The value stream for impediments is pretty simple:
  • Step 1 ScrumMaster attempts to solve problem. S/he may succeed -> go directly to done
  • Step 2 ET attempts to solve problem (and may fail)
  • Done, with a successful or unsuccessful resolution
Three: Find a strategically located spot for the Kanban board, ideally someplace where every, especially management will see it. This creates visibility for the problems (and for those trying to solve them).

Four: Working with the board. Every significant impediment gets put on the central Impediments board. Every day that a ticket is on the board, tick mark goes on the card. When the ticket is done, it gets green dot if the team is happy with the result, and a red dot if not (i.e. management said, "sorry we cannot fix this problem.") The goal is to resolve impediments as quickly as possible and to have as high a percentage of green dots (= team happy) as possible.

My team hasn't looked at limiting WIP or establishing Cadence yet. It's tempting to put up a scoreboard, counting how many impediments got to done (with a red or green stamp) within one day, 2 days, 3 days, etc. A natural extension would be to set up a paralell board for improvements coming out of the retrospectives. This would give the ET a natural two week rhythm.

This approach creates a feedback loop between Management and operational staff. It gives immediate visibility to the problems and reminds people who might not want to cooperate with a lowly, powerless ScrumMaster that management is watching. It might even offer a metric for evaluating how effectively management is supporting its teams.

How do you get management integrated into the Scrum process? How do you make management responsible for making the process work?