In the previous blog post, I gave a list of points when adopting agile in an organization. One of them was:
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):
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.
- 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.
