Self-organizing teams - bullshit or not?
Most probably you have already read several articles about self-organizing teams. And most probably you though this is not possible to be achieved in your company. If you answered yes to both question - this article was written especially for you.
I was really a lucky person because my manager gave me a chance to build a self-organizing teams several years ago. The beginning was quite hard - I was new to the big team (about 50 people) and team had some not very good experience with Scrum in the past. Moreover we had new release to be done with big content and as usual challenging schedule.
Trust
I am starting this list with trust despite the fact this is probably the most difficult. You need to trust the team even if you don't know
the teams members very well. Maybe you know them but they undermined your trust in the past. Trust is very important that is helping the team to grow.
Responsibility
Feeling responsibility is driving to high velocity and good quality. One of the first thing I found out when joining the team was lack of responsibility across the team member. There was one Software Architect who make all decisions (even very small with no risks). That causes deadlocks, some tasks were waiting till final decision approved by Architect. Identifying area for responsibilities and spreading them between team members increased overall team velocity and surprisingly also team member motivation.
Integrated quality
Starting from waterfall through iterative development model usually test team was separated from development. One of the reason for that was to keep fresh eyes and independent audit of developed feature. Often this separation caused confusion, misunderstandings and anger. Developers goal was to integrate code as soon as possible and fix all the defects, when testers goal was to report as many defect as possible. I don't need to emphasize that these two goals are opposite :)
At the begging of team transformation we merged testers and developers in one scrum team. Now they have common goal: integrate code in good quality.
Cross-functional teams
Usually in waterfall project we have functional team: back-end team, front-end team, test team, etc.
This kind of structure brings many dependencies between them. When particular feature need to be developed all teams are involved.
Alternative model is when every team have all competencies inside. Then team dependencies becomes task dependencies and that makes life&development easier :)
Setting up boundaries
One of the probably most surprising factors that can help you to settle self-organized team is setting up clear and well known boundaries. Having them is helping the team to feel safety. If you would like to start create a short wiki page or other shared document with simple rules everyone knows (but newcomers probably not) and ask the whole team in extending. You will see how fast it will grow.
I was really a lucky person because my manager gave me a chance to build a self-organizing teams several years ago. The beginning was quite hard - I was new to the big team (about 50 people) and team had some not very good experience with Scrum in the past. Moreover we had new release to be done with big content and as usual challenging schedule.
Trust
I am starting this list with trust despite the fact this is probably the most difficult. You need to trust the team even if you don't know
the teams members very well. Maybe you know them but they undermined your trust in the past. Trust is very important that is helping the team to grow.
Responsibility
Feeling responsibility is driving to high velocity and good quality. One of the first thing I found out when joining the team was lack of responsibility across the team member. There was one Software Architect who make all decisions (even very small with no risks). That causes deadlocks, some tasks were waiting till final decision approved by Architect. Identifying area for responsibilities and spreading them between team members increased overall team velocity and surprisingly also team member motivation.
Integrated quality
Starting from waterfall through iterative development model usually test team was separated from development. One of the reason for that was to keep fresh eyes and independent audit of developed feature. Often this separation caused confusion, misunderstandings and anger. Developers goal was to integrate code as soon as possible and fix all the defects, when testers goal was to report as many defect as possible. I don't need to emphasize that these two goals are opposite :)
At the begging of team transformation we merged testers and developers in one scrum team. Now they have common goal: integrate code in good quality.
Cross-functional teams
Usually in waterfall project we have functional team: back-end team, front-end team, test team, etc.
This kind of structure brings many dependencies between them. When particular feature need to be developed all teams are involved.
Alternative model is when every team have all competencies inside. Then team dependencies becomes task dependencies and that makes life&development easier :)
Setting up boundaries
One of the probably most surprising factors that can help you to settle self-organized team is setting up clear and well known boundaries. Having them is helping the team to feel safety. If you would like to start create a short wiki page or other shared document with simple rules everyone knows (but newcomers probably not) and ask the whole team in extending. You will see how fast it will grow.
Comments
Post a Comment