March 2011 Archives

Organizational changes to support one team

In the previous blog post, I gave a list of points when adopting agile in an organization. One of them was:

  • Start with one team but immediately make the organizational changes needed to support that one team.

But what does that mean "the organizational changes needed to support that one team" ?

I usually recommend four organizational considerations when getting one team to work. (they are actually 3, but one is repeated for stress):

  • Dedicated cross-functional teams
  • Define "done"
  • All work flows via the PO
  • Keep out project managers

Let me clarify these:

Dedicated teams

This is probably the biggest change. With a dedicated team, I mean a team where the team members are for 100% on this one team. Also, the team is not temporary... it is not "just a project team". The team members know the change is serious... so serious that this change needs to be reflected in the organization. The members of the team have to report to the same "line" manager--without this it causes the confusion of conflicting loyalties. The team should take a shared responsibility for all the work. Specialization should blur. But when people report to a functional manager then this will be an restraining force which causes people to focus on "their area". To break this and to show that the initial Scrum pilots are serious, the organization has to reflect this in their org chart.

Define Done

The "definition of Done" defines the scope of the organizational change (the one mentioned in point #1). If we include technical writing, systems integration testing in the initial definition of done, then the people with these skills need to be taken out of their silos and put in the dedicated team. However, when the definition of done is smaller, it would lead to less change (but more delay and risk!). So, an organization adopting Scrum needs to define done to decide on the scope of the change.

All work flows via the PO

Teams need to focus to get work done! Focus, one of the original values in Scrum, is difficult when the team is interrupted from many directions. To get the initial team to work well, they need to be clear on what the work is that they need to do and where this comes from. Make this clear in your organization that the team is off-limit and that if anyone wants work from the team then that person needs to talk to the PO.

Keep the project managers out

This is the same as the previous point but it seems useful to repeat it. Project manager is not a Scrum role and the project management responsibilities are divided over the three other Scrum roles. Adding a project manager to a Scrum organization causes enormous confusion in responsibilities and dis-empowered Product Owners and ScrumMasters. To avoid this, make sure the project managers in your organization know that a Scrum project is off-limits. If management wants status of the project, they need to ask the Product Owner.

These four points seem simple but are incredibly hard to implement in an organization. However, they can be implemented on a team-by-team basis and that enables a gradual transformation of the work... and the organization.

Tips when adopting agile

I'm frequently asked whether I got tips for how to start an agile adoption. A lot of people are looking for the ten step magic recipe that will magically transform their organization to an agile organization. I tend to reply with the 'bad' news first: Every organization is different and it probably takes a long time... think years not months. That said. Over the years I've collected small tips which helped organization I worked with. Some come from organizations that tried them out and it worked really well... others come from organizations that tried out the opposite and it was a disaster.

Here they are, tips for adopting agile:

  • Avoid forcing Scrum on people and instead find people who are willing to try.
  • Get enough training so that all people have the same understanding. Differences in understanding is a common failure point.
  • Go See how things *really* happen. Talk to everyone. Look at code and tests.
  • Start with one team but immediately make the organizational changes needed to support that one team.
  • When adopting Scrum, also focus on the technical practices that are needed. Technical and organizational agility have to go hand-in-hand.
  • Do not buy any agile tools. Tools are unlikely to be the main problem.
  • Do not change Scrum or the technical practices without first many months of practices
  • Get in coaches. Organizations that want to do it all by themselves usually make a lot slower progress. This will be a huge change and getting help is a good idea.
  • Make sure the team is co-located and has an "agile-friendly" office environment.

Why just these tips? I don't know. From my experience, these seem to be of major importance.

Me and Craig have given more adoption advice in our "Inspect & Adapt" chapter of the "Practices for Scaling" book. You can find a free copy of this chapter on informIT

ps. Thanks to the other Odd-e people for their input!

About this Archive

This page is an archive of entries from March 2011 listed from newest to oldest.

February 2011 is the previous archive.

May 2011 is the next archive.

Find recent content on the main index or look in the archives to find all content.