A sample text widget

Etiam pulvinar consectetur dolor sed malesuada. Ut convallis euismod dolor nec pretium. Nunc ut tristique massa.

Nam sodales mi vitae dolor ullamcorper et vulputate enim accumsan. Morbi orci magna, tincidunt vitae molestie nec, molestie at mi. Nulla nulla lorem, suscipit in posuere in, interdum non magna.

Multiple Scrum teams in one organization, defining common processes ?

As a result of the impulse to get quality certifications, a number of organizations look to define common processes that they can implement across the software teams that they have in the organization. The idea is that this will ensure that after people have reviewed the various processes in use in the organization, there is a review done to figure out the ones that are most effective and appropriate to the ethos of the organization, and to implement the same in the different software development teams in the organization. There will be people identified to take teams through the various quality processes, to ensure that teams are now following these processes, and then to figure out over a period of time how good the teams are on compliance with these processes. In the regular scheme of things, compliance with these processes is something that all teams hope to achieve, with the project / program manager on the block to ensure that this happens.
Now, let us bring the Scrum team into the question. Scrum teams are supposed to be small nimble teams, not hung up on processes, and empowered enough to figure out which of the processes in use are correct for them, which need to be modified, and where new ones need to be in place. This need can cause huge problems in organizations. Here you have an organization which has set its ground on ensuring that teams follow strictly defined processes, where process changes need to be discussed with centralized groups before they can be approved, and here you have Scrum teams where the team members have been trained that they are the ones to get things done, where even their former manager or Program Manager now does not wield direct authority on them, and they can discuss and figure out how to get things done.
There can be a conflict, and it is the job of the team managers and other stakeholders to ensure that these kind of hiccups are resolved. In larger organizations where there are a number of teams and such centralized processes are in place, getting a Scrum team in place can take time and effort. One does not talk about giving training to the entire organization, but there is a need to ensure that senior managers (and the ones who can cause hiccups in terms of process changes and approvals) have been taken through a concept of what the Scrum development methodology is, some success stories (and some problems where it has not worked so well along with reasons), what they need to understand, and how important the concept of making sure that the scrum team members are empowered and need to feel that they are empowered. If this does not happen and there are some processes forced on the team that do not seem reasonable by the scrum team (and also by the scrum master), then things can be get problematic. Many team members have been wired into thinking about the traditional model where they are directed to do stuff by their leads or by managers, and changing things is not easy. After this, if they feel that the concept of empowerment is not real, and when push comes to the shove, there is no real empowerment, then the belief in the Scrum development model does not really work.

Leave a Reply

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>