You might have already read about an exercise I am performing in every Scrum class I hold - I ask participants to list Roles, Artifacts and Events in Scrum. Each of those categories has the most omitted element. Lets's take a look at the most omitted role:
The Development Team.
Instead of the Development Team you can find (in order of frequency of appearance):
-
(nothning)
-
developer
-
scrum team (which is not very wrong - I'll elaborate below)
-
Project Manager
-
Leader
-
Definition of Done (yes, some consider it a role 0_o)
Why participants (even in advanced classes) tend to omit or make mistakes in this role? There are is one main reason for that.
Development Teams are in fact omitted in their companies.
Creating, sustaining and caring for a Development Team takes effort and costs money. It requires a career path that will lead to a uniform team with no roles. It requires understanding what a Developer in Scrum is. It requires Scrum Masters or other servant leaders who will create an environment for them. It requires knowing practical aspects of one's national and organizational culture. It requires trust and courage to give freedom to self-organize. And it requires many other things for the context of your organization.
A simple development team needs all this?
Short answer: yes.
Long answer - let's look at all those prerequisites.
A career path that will lead to a uniform team with no roles.
In the vast majority of companies, teams consist of: developers, testers, business analysts, UX specialists, graphical designers etc. They have juniors, mids, seniors, consultants, architects and ultimate know-it-alls. Team members have different managers. Every division in a team makes it divergent and creates internal barriers that require work to overcome (and sometimes are persistent).
Career paths that enable all members of the Development Team have the same work title, same manager and will be treated the same are rare. But when they exist, creating Development Teams becomes much easier.
I have seen some ideas on how to create career paths that help form Development Teams:
-
Let people choose their position name or have same position names for all members
-
If you are required to have position names, encourage people to nickname them and hide the official ones
-
Make sure a team has one manager and one goal (there are no individual goals)
-
Have levels of skill advancement (eg. from 1 to 13) instead of labels and clear prerequisites for leveling up
-
Make learning skills of your teammates a good thing - it will create bigger respect for one's work.
Understanding what a Developer in Scrum is.
A Developer in Scrum is not a programmer. In fact Scrum says nothing about programming. The word "developer" also means "creator" and this is how it should be understood. The same works for other languages. And that's why a Developer in Scrum is written with a capital "D".
Scrum Masters or other servant leaders who will create an environment for them.
Development Teams are self-organizing and led by a servant leader, who creates environment for them to thirve. A Development Team is universal - it can exist without Scrum, but not without a servant leader.
A servant leader can also operate from within a team - that's why putting a Scrum Team (consisting of the Development Team, a Scrum Master and a Product Owner) instead of the Development Team is not very wrong. The important part is that it has to be a servant leader, not a manager with a special position.
Knowing practical aspects of one's national and organizational culture.
Each country, city and company is different. You have to be aware on how the culture you work with impacts development. I once worked with a company that had its office in a city, that has long and winding history. It created a lot of cultural divisions:
-
People from one side of the river (dividing the city in half) prefered not to work with the ones from the other side
-
People from outskirts of the city didn't like the ones from the city center
-
People with families connected to the city for generations disliked ones that just moved in
-
Supporters of one football club disliked supporters of the second
-
.... and there was a section of the city that liked nobody from outside.
I tried working with teams there, but there were always some problems, divisions and politics. I didn't know about all of those differences and tried using methods that worked in other companies and cities. After a year of failing someone told me about the community divisions. Once I learned about it, it became obvious, that teams should be structured in a different way. So we started working towards building teams, taking those limitations into consideration. It became much easier (although still challenging).
Trust and courage to give freedom to self-organize.
Self-organization can be scary. So scary, many fail to give teams enough room to do so. It requires courage to let go of control and start trusting people. Give them a goal and help achieve it without micromanagement. Interestingly, it requires trust and courage from the team as well - trust, that their management will continue supporting instead of micromanaging, and they have to have courage in being left with decisions - and their consequences.
So what does it take to make a Development Team? Values, environment and will. I hope you can make it happen and create Development Teams in your organization.
Original text can be found here: [link]