Changing Roles to Implement Scrum

Now you are thinking about implementing Scrum. Next question, what is my role going to be? What are other people in my organization going to do? You have a few options.

In my organization, before Scrum, we had roughly the following organizational structure in I.T. This is a somewhat simple, but more or less typical in many corporate I.T. Departments.

Plan 1 – Complete Reorganization

This would be the best permanent method. This may be quite a bit more difficult, especially in the early implementation phase of Scrum. People are comfortable in their roles and with their responsibilities… and they are resistant to change.

Plan 2 – Role Assignment

The least effort plan is to have everyone keep their job, but Scrum roles are assigned that fit their position or their particular skillsets. This is usually quicker, and meets with less resistance. Now, what those assignments are is largely up to the current makeup of your organization. Based on the diagram above, we were already in a prime position to assign roles.

Change impacts everyone, and even people who are good with changes can feel threatened. Don’t make the process more difficult for them, or you. This will help you bring about a much more successful implementation.

Role Assignments I used

Based on the organization chart above the following role assignments were implemented in our organization.

Scrum Master – As the champion for Scrum, an experienced project manager, and the only one who received as much training, I became the Scrum Master. I still maintain my role as the Development Manager. Even prior to Scrum, I was a staff manager – reviews, raises, hiring, firing, etc. This accounted for maybe 5 – 10% of my work. It is still necessary this work is done. (There are some Scrum tools for this as well, but that is a future article). The CTO role technology strategy and system architecture consumed about 20% of my time. The largest percentage of my time was spent as a project manager.

The biggest benefit of Scrum, for me, was it reduced the time and effort I spent on project and people management. This is largely due to the self-managed teams and the addition of the Product Owners.

Product Owners – This was easy for me, since our Business Systems Analysts (BSAs) were almost Product Owners already. They met regularly with their assigned business users. They coordinated between the business and IT. They relayed priorities, and wrote the requirements documents. In order to get them to be Product Owners, we really just had to shift their thinking a little, apply some [new terminology], and train them on Scrum tools.

Business Owners – Easier, well sort of. These are the people that the BSAs met with on a regular basis. In implementation, for most part it was just an internal change in terminology. What was the “Sort of” for? Well the harder part is changing the mindset. Some BO’s are easier than others. This is a discussion for another post (or ten).

Scrum Team Members – For some people, this assignment was really not much of a change at all. There were some things that changed slightly, but this is primarily due to the pre-Scrum team makeup. Since teams are self-managed, we eliminated “Team Leads”. We integrated QA analysts into the team (not as tightly as I would like, but this is a iterative improvement).

What about the rest?

Now, you are probably looking at my chart and saying, “If Scrum is so great how about your Infrastructure group? What kind of hypocrite are you? This has a lot to do with our organization, a little with politics, and some to do with the fact that we don’t have Scrum being used in every team. As far as the Infrastructure group, there primary roles involve things like server administration and architecture, support, implementation, and operations, etc. With the exception of architecture and implementation roles, the infrastructure staff isn’t usually involved in the project to justify dedicating them to the team. Some Scrummers call this type of a role a “Specialist.” We call them into the project when we have stories that pertain to them. Most of their projects are not development-like projects where they are building and testing software from a backlog, they tend to be more choreographed and scheduled projects that really do benefit from traditional waterfall-Gantt chart approaches.

This of course, is just an example of how I did it at one company. Each company has its unique nuances and challenges to overcome. And while I don’t recommend it, I have seen companies implement Scrum in some very non-kosher “scrum-but” ways. Some have done this because they don’t know what they are doing, but others have done this because it reduces the political or psychological problems with the company or teams. If you have to do this, always consider this a transition period to a more dogmatic Scrum process. This is where you will really achieve the biggest improvements.

Comment back with ways that companies you know of have dealt with the issue with role assignments in Scrum.

• Network Marketing - Fixing Problems From The Ground Up A good majority of people don't really understand network marketing it is like they love the comp plan but they...
• 20 Reasons Why I Love the Recession I'm one of those weird people that believe when things go horribly wrong, the opportunity to make your situation better...
• Best Home Improvement Projects It might just be time for you to treat yourself to some really nice home improvement projects. Some of the...