Sunday, May 29, 2011

Scrum Breakfast June: A new management paradigm?

"In the 21st century, there will be two kinds of company. -- Only two? -- Only two: Those who delight their customers and those who do not. The former will flourish and prosper. The rest will stagnate and eventually die."
With these thoughts, Steve Denning launched a discussion about the purpose of the modern enterprise at the Washington Gathering, 'Revolutionizing the World of Work.' His arguments: Large enterprises are dysfunctional. Government is dysfunctional. Health care is dysfunctional. The causes can be found in traditional command and control based management. Scrum, Agile and Lean Values and Principles (together with a few others) have formed that basis of thriving new enterprises.

I attended the Gathering as a practice partner. In that role, I contributed an exercise which demonstrated dramatically how Agile principles improved organizational performance and value creation. More importantly, I learned a lot about how some organizations successfully adapted, why many fail in the attempt, and what you can do to change your company for the better.

What would your company be like if Agile values permeated the organization all the way to the top? How would your work relationships change if delighting the customer became your company's primary goal? Would you like your company to be one of those that thrive in the 21st century?

This Scrum Breakfast is for everyone who wants to make their workplace a better place! I'll present some of my key learnings from the Washington Gathering and hope to start a discussion on transforming a daunting task into an achievable vision.

When: Wednesday June 1, 2011, 8.00 to 11.00
Where: SwissICT, Vulkanstrasse 120, 8048 Zürich
This discuss will be held in German.
More Info and Registration: SwissICT

Other Upcoming Talks:
  • The Zurich Chapter of the PMI is hosting an evening on Scrum and Agile. I'll be speaking on Scrum and Agile: A Different Approach to Project Management. Monday, June 27
    Info and Registration
  • I'll be co-hosting an Open Space on Agile Contracting with Heitor Roriz Filho, a visiting CST from Brazil. Friday, June 24.
    Info and Registration


Saturday, May 28, 2011

The Key to Good Estimates

Everybody knows the I in INVEST: each User Story or Product Backlog Item must be independent of the others.  This means that errors can cancel each other out. Too high on feature 1, too low on feature 2. Over the course of thirty or more features, things average out.

I have realized that another kind of independence is critical for accurate estimates. Just as important as the functional independence is the organizational independence of the team performing the work.

In a phased approach ("waterfall"), projects always share people. For example, last month, the architects were working on the design of project P1. Now they have handed that work off to the developers and start work on project P2. So if the architects have a delay in their part of P1, that will not just impact P1, it will also impact P2. If management re-prioritizes, taking people off of say P3 to support P1, then P3 is also delayed.

So a delay in one project impacts many other projects in the same organization. The company has a tightly coupled architecture. It is emotionally satisfying, because it gives the impression of high utilization at the expense of predictability and performance in executing projects. Estimation errors and delays cascade. Errors seldom if ever cancel each other out.

In Scrum, all the skills needed to bring the project from start to finish are present in each team. The team's composition is stable with few unpredictable changes. So errors can cancel each other out and seldom cascade, because the dependencies between projects and teams are held to a minimum.

So if you want good estimates, decouple your projects from one another by establishing teams that work autonomously and together for the entire duration of the project. (In other words, you should be doing Scrum or something very similar to it ;-)

Thursday, May 19, 2011

Making your Company a Better Place

Welcome to the future! Fellow revolutionaries! We are here to change the world. This is an invitation to meet here again on May 12, 2021. By that time, we will have transformed the Fortune 500. We will have transformed the government. We will have transformed the health sector. We will have transformed the education sector....

You might be wondering: how could we, the thirty people in this room, possibly change the world. We have few resources. We don’t have much money. We have little explicit power. We don’t have political clout in any conventional sense. So how could we possibly change the world?

The reason why we are going to be able to change the world is that we have a better idea. At the end of these two days, we will all own a set of ideas that will change the world.
With this compelling vision, Steve Denning, Seth Kahn and 5 Practice Partners (including yours truly) introduced the 25 participants into the world of Radical Management. Why did the 25 people come to take on such a daunting challenge? One participant, a senior manager at a large organization, explained it this way:
These ideas resonated with me. I work in a large organization and it’s obvious that command and control is a disaster and we need to aspire to these ways of working. In my company we just went through a change initiative that was about saving $10 million, but it was billed as bringing us closer to the customer. It was a complete lie. We are getting this wrong and the stakes are really high. We need this kind of thing so badly.
How are the new principles different from the old ones? Steve put up the following table:

Delighting the customers is more important than making money for shareholders?! How can than be?

Look at companies like Apple, Salesforce.com, or Amazon. Why are these companies so profitable and so well regarded on Wall Street? Because they delight their customers. They innovate. They create new value and learn to thrive in the 21st century. And they are great places to work. Look at companies like General Electric or Walmart. Their stocks have gone nowhere. Their command and control culture has not enabled them to innovate.

According to the Deloitte Shift Index, only 20% of workers are passionate about their jobs. Since 1960, the life expectancy of a Fortune 500 company has declined from 75 years to 10 years today! Innovation and involvement is crucial and traditional management is not doing the job!

At the Scrum Breakfast this month, we'll explore this new work paradigm. If you want to change your company for the better, then check out this video and join us at the Scrum Breakfast in June!


Thursday, May 5, 2011

How we do a retrospective

I consider the retrospective to be the most underrated meeting in the Scrum Flow. Since it is not about the concrete results of the project, there is a certain temptation to ignore it. It is easy to fall in to the trap that "there is always something more important to do."

Still, each Sprint should produce two results: 1) A product or service which is an increment of functionality closer to delivery and 2) a better, happier, more productive team. The retrospective is the primary opportunity for achieving the second result.

There are many ways to do a retrospective. Variety is the spice of life, and few areas are in need of more spice than a retrospective. So feel free to vary your approach, the questions, the focus, the location, the moderation, etc to keep the energy level up. The retrospective format described below takes about 2 to 3 hours, depending on the size of the team and your timeboxing. I like to use this format when getting started. It is also suitable for reflecting on a longer time-frame, e.g. a quarterly release or for reflecting over organizational boundaries.

A retrospective should identify and prioritize actionable suggestions to improve performance. As moderator of a retrospective, my goal is to get everyone to contribute to the discussion. I seek to channel discussion and debate to the proper moment, but also to prevent un-constructive discussions. I usually go through the following steps:
  1. Establish safety
  2. Identify the facts
  3. Identify the team's strengths
  4. Collect ideas for improvement
  5. Consolidate and prioritize the ideas.
Establish safety

Why establish safety? Very simple, so that people can talk freely about what happened and what could be better, without fear of consequence. If people are afraid of the consequences, they will be unwilling to talk about substance.

Sometimes it can be helpful to talk about the retrospective prime directive. I have also asked each team member to introduce him or herself and answer some questions about the story of their lives. And sometimes it is even useful to have a secret vote on how secure people feel about talking about their situation.

For the remainder of the retrospective, the following pattern is an easy way to get everyone to think about the question at hand, communicate their most essential points, and listen to what the other people have to say.
  • individual reflection - each person, thinking for themselves, writes down their points on sticky notes (one idea per sticky note!), then posts them to a common area on the wall. I usually time-box this to 2 or 3 minutes and encourage everyone to write down at least 5 points.
  • presentation - each person presents to the group what they wrote down. (I strictly time box this part to 2 minutes per person). Clarifying questions are allowed. Debate is not. No-one has to defend themselves while presenting their facts or ideas.
  • group discussion/debriefing - after everyone has presented, then I let the group discuss what they have heard. This is also my opportunity to ask illuminating questions about the topic.
So each of the following points goes through the same scheme of reflect - present - discuss.

Identify the facts

Here I ask the team 'what happened?' This is about facts and events, not opinions or judgements. The idea is to build a common understanding of what happened and what was important during the period. If this is a sprint retrospective, then then time frame is simply the sprint. Sometimes a team will want to reflect over a longer time period, say 3 months.

I like to draw a time line on a flip chart in landscape format, then I draw a :-) and a :-( on the y-axis. Just as the people are about to put their stickies on the wall, I ask them to position the sticky horizontally in time and vertically by how it moved them (happy or sad). The resulting distribution paints a surprisingly clear picture of the team's emotional state. (BTW - I discourage the team from thinking about high and low points while they are writing - that's already focusing in, which is contrary to the objective of this step, i.e. is to open up and let the information flow).

On debriefing, I first ask if the team has forgotten anything important. Then I continue with a very open question to start the discussion ('OK guys, what do think?' or 'How do you feel about what you see?') Often different participants will have brought up complementary or even contradictory perspectives on the same event which are worth illuminating in more detail. (My favorite example: Sales: 'I asked development for estimates but, as usual, they didn't have time. So I had to estimate the project myself.' Development: 'We got yet another project from Sales which had been estimated without our knowledge or participation.').

Identify the team's strengths

I do not ask the team what it does badly. I think this gets people focused on the negative which is not helpful to improvement. I much prefer the positive formulation: 'what do we do well'?  I like to ask this question for two reasons. 1) It gives the team a chance to pat itself on the shoulder -- and it may need the opportunity if the results of the previous step were too 'bottom heavy'. 2) I can see how well the team is functioning as a team.

Sometimes, after the team has presented its tickets, I ask the people 'what should be on the list, but is not'. I don't ask them to produce tickets, but just think about the issues.

If the team is performing at a high level, I would expect to hear them talk about craftsmanship, conflict and attention to results:
  1. Craftsmanship. A software team should be good a building software and master many of the modern engineering practices. So I would like to hear about their continuous integration server, their test processes, their pairing, their source code control, etc. If they are doing good engineering, they should be able to talk about it.
  2. Conflict. A well functioning team should be able to argue passionately about the subject matter, make decisions, commit and move forward. I like to hear evidence that the team is able to work effectively as a team. For instance: 'It is the power of the argument, not the positional power which determines the winning argument.'
  3. Attention to Results - The team should be producing something which  a customer wants. So I would expect to hear about releases, communication with the customer or feedback from the user. In particular, the quality of requirements being presented to the team for implementation.
Obviously, if anything is missing, I will ask the team about the current situation: "I would have expected a top team to be proud of the their approach to testing. I don't see anything about testing. How do you handle testing....?'

Collect ideas for improvement

The last question for the team is, 'What could we do better?' The objective is identify concrete improvement potential which the team could start working on tomorrow. Ideally the team has been well primed based on the previous discussion to come up with good ideas.

Consolidate and prioritize the ideas.

This approach produces many ideas. Too many, to implement all of them. Many will be duplicates or multiple suggestions to address a more fundamental problem. So after all the ideas have been presented, you need to create some order from the chaos. The team has to decide what it will really do.

As moderator, I go through the tickets one by one and ask two questions:
  1. Who can fix this issue, the team (people in the room)? Or is help from someone else necessary (e.g. management, another department)?
  2. Does this tickets belong together with some other ticket, or is it a new issue? For instance, there might be three different suggestions related to testing, and these might get grouped together on the common theme.
I usually group the tickets in two columns, one for own jurisdiction (the team can address the issue itself) or one for foreign or shared jurisdiction.
If there is some doubt as to who has jurisdiction over a particular problem, it is helpful to trim the scope of the ticket so that them team can take responsibility. Otherwise, negotiation is required with a third party, say management or another department. This will at least take time and may even call into question whether the idea can be implemented. A team can move much faster on issues for which it has jurisdiction. (Non-Scrum teams are often totally dependent on their management to get any improvements done at all! - No wonder Scrum teams are faster!!)

Once the tickets are grouped and consolidated, the team can prioritize the improvements, e.g. using dot-voting. Depending on the number of tickets in each column, the team might vote on each column separately or both columns together.

At this point the team has a prioritized list of improvements it can make to improve its performance and/or make it a happier team. Usually I suggest that the team stop at this point. The next day, just after the daily Scrum, the team should decide how many of the items it wishes to take on for this sprint and how to tackle those items.

It is better to commit to and succeed at implementing just one improvement rather than to commit to too many ideas and not get any of them accomplished.

I suggest taking a picture of the results and posting them to project wiki. I do not suggest keeping track of suggestions you decided not to implement. This list would become heavy baggage to carry around. If the issues are important, they will resurface in a future retrospective. It can however be quite satisfying to keep track of the improvements that you have actually implemented, both for you and your management.

Tuesday, May 3, 2011

Scrum Breakfast June: Agile Management

Radical Management, or a New Work Paradigm?

Today, some companies are wildly successful at creating value and excitement for their customers. You can see it in the stock prices of companies like Apple, Google, or Salesforce.com. Other companies are doing more to destroy value than to create it. These companies die slowly or become the subjects of government bailouts.

What is the difference between these two classes of company? A pattern is emerging. Successful companies are embracing practices and principles of Agile and Scrum and failing companies are sticking to traditional command and control. The successful companies are energized, pleasant places to work.

How can your company embrace agile values at the management level? How can you create an environment conducive to creativity and continuous improvement? How can you transform your company in to a more competitive organization (and have more fun while working)?

As readers of this blog know, next week I'll be at the Washington Gathering on revolutionizing the world of work. I expect to bring back many good ideas on building bridges between agility and management. 

This exchange seeks to build the bridge between agility and management and offer models for an agile organization. My goal is for each of us to leave the room with ideas for how to make our companies better, more creative environments.

Where: SwissICT
When: 1.June 2011, 8 to 11am
Registration via SwissICT