Many of you might experiencing a similar situation as I: Working in a large corporation within a team on different projects.
You heard all the buzz words: scrum, agile, innovation … mhh yes that’s what it’s called but is it used and lived?? Ähh NO!
In this post I would like to share my experiences and a pilot I stared in a development team:
The current state of the Scrum union
For years I have been working in scrum teams with different peoples with whom we work together on different topics. After a while I started ignoring the structure because the methods like scrum was never lived as it described on the paper.
I tried to change the thinking of the people regarding the structure and the reality but I realized that I couldn’t change anything because of company processes and hierarchy. This is why I started a pilot to try out if there is another possibility to improve the teamwork.
In a development Scrum team you have these roles defined: a PO, a Scrum-master, developers and other roles. I worked in that setup multiple years. For me the focus has always been on the ability of a person. People are often positioned in roles that do not match their skills. That was my trigger to start a pilot where the aim was to create an autonomous team with the motto: skills before roles!
The team structure looked like this:
- Every team member is responsible for the output of the team.
- Every team member should be able to explain others what the team is working on and what is the vision.
- Every team member should be able to manage his or herself and not waiting that someone tells him or her what he or she has to do next.
(the same Elon Musk requires from his SpaceX employees, like a T-Shaped role: https://medium.com/@warren2lynch/scrum-team-i-shaped-vs-t-shaped-people-569de6fa494e, but with responsibilities.)
This team setup was amazing!! It worked for all team members and we where in one month more productive then in the last 3 months.
The mindest of the team members changed. They feeled more responsible for the stuff they are doing and where able to push it forward. They started looking outside the box.
The issue here was that other teams didn’t accept that setup. They didn’t understand why we don’t have a PO they can talk to for alignments and priorization. Our answer to this was: “You can talk with any team member you want“.
No Scrum Master!?
They didn’t understand why we don’t have a Scrum Master. Our answer to this was „The team is managing hisself and solving impediments in the team together“
Taking responsibility & ownership
Every team member was in the position to take over PO, Scrum Master or other roles when it was necessary.
If you are working in a large corporation with strict hierarchies and processes you can not change anything as single person or as a team. I really hope that the mindset in the companies are changing. It is really important to keep employees motivated!
Find the right task for each person! If my team needs coffee and cake to be more productive I would do this, doesn’t matter what my official role is. To end with another buzzword: „Be a start-up“. But not only be as a start-up. Really act like one! Do not only give ownership & responsibility to artificial roles (PO & SM), give them to the whole team and treat them as responsible and grown up adults.
Skills Before Roles! 🙂
mar 20. November 2020
thanks Fil, well written, i like your thoughts and agree, also experienced that roles can easily become excuses rather than tasks and outcome, i prefer to find roles naturally through unofficial negotiation among the team based on skills and interest
scioatael 3. Dezember 2020
I like the idea of your setup and I am sure it was effective to organise yourself as a team. What might be challenging in this setup though is how other teams interact with yours, especially if they are accustomed to certain roles and cannot congnitively handle your team as a self-organising being (No PO?!, No SM?! :))
One way which may help is to make others aware of your „Team’s API“. Similar to like API is exposing a business value of resources behind it, but not a implementation details behind it.
Your team can „expose“ an interface to others and this should not matter how you realise this interface internally.
Creating a good „team API“ may help understand others your teams mission (i.e. business value you create) and how to interact with you (communications, definition of done, etc.).
more on this: https://medium.com/agile-outside-the-box/team-apis-af2dbc1805e7
Fil 4. Dezember 2020 — Autor der Seiten
thanks for the feedback. I really like the idea of Team API. The issue was that we never get direct feedback from these people..so we never had the chance to improve the setup. The conclusion was that this team got a PO and Scrum Master and I left the team 🙂