Organizational changes to support one team

| 6 Comments
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.

6 Comments

Thank you for articulating so well something so fundamental to our work as organisational improvement change agents. This stuff is hard, but essential. Now we need more hints about how to achieve these goals. :)

Is it a possible solution, if the teams are smaller, to make PMs act like POs for that team?

I believe, that the ROI responsibility for the project is exactly on the PMs in our case, since they are the ones to negotiate with marketing when new functionality should be added. They are also responsible to negotiate with functional team leaders about schedules, and also with QA leaders about testing resources/schedule.

Thanks I think the last point made it clear for me also why you think someone being a PM is not suitable for the PO position :)

About this Entry

This page contains a single entry by Bas Vodde published on March 26, 2011 6:13 PM.

Tips when adopting agile was the previous entry in this blog.

Satir/Weinberg Change Curve or "That model is wrong?" is the next entry in this blog.

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