Scrum Team Transformation Retrospective
Updated: Oct 9, 2020
In the past I have had the opportunity to transform functional line organisations into agile Scrum organisations. This is a transformation many organisations are currently going through. As such I thought it would be useful to share a blog of my experiences and lessons learned, so that others may benefit and also learn from the experience. Here are the top 3 lessons I have learned so far.
1. Be brave – go for full on Scrum!
Many organisations bottle out and decide to only implement certain parts of the Scrum framework, e.g., they implement the concept of “Time Boxing” but retain the existing roles and responsibilities, i.e., functional team leaders and project managers. Although this may bring some benefits in terms of managing change and setting short term team goals, it is not Scrum, and you will not enjoy the full benefits unless you go full on Scrum.
Companies tend to shy away from making the tough decisions of implementing the roles of Scrum Master and Product Owner because; it makes the traditional team leader and project manager roles redundant. So if you are responsible for reorganising what do you do with these people? The answer largely depends on the individuals involved and the options within the new organisation, there is no one size fits all solution.
If you choose full on Scrum and implement the roles as defined by Scrum you will reap the additional benefits of self organising teams and clear ownership of product prioritisation and planning. As a previous overall leader of a development team my life got much easier after implementing Scrum across 3 development teams of 7 team members. After transformation to the Scrum organisation I no longer needed to do any scope planning, this was now all done by the Product Owner, and I no longer needed to manage the development team, this was now done by the self organising teams themselves and the Scrum Masters. All I needed to do was support the resolution of impediments in case of escalation and help with any prioritisation decisions.
2. Trust in the Scrum Guide “Bible”
This follows on from the point above. Its quiet simple - implement Scrum as it is described in the Scrum Guide. Do not stray from this path. There are several benefits to this approach:
It minimises discussions during reorganisation and helps decision making. Reorganisation is political; people lose and gain organisational power. The Scrum Guide acts as a rule book for how the future organisation will be and so can easily solve disagreements or differences of opinions.
Everyone in the Scrum team has the same baseline and knows exactly how it should work – everyone is on the same page and working from the same frame of reference.
The Scrum Guide doesn’t cover everything and topics will crop up that are not covered specifically by the Scrum Guide, e.g., best practise when using story points estimation, burn down charts etc. In this case you will need to reference the Scrum forums on the internet in order to judge the best practise that fits best to your situation.
3. Scrum team transformation is like building a team from scratch
If I had the magic recipe for producing the perfect performing team I would be a millionaire. However, Scrum does have an event especially designed for improving team performance called the Scrum Retrospective, which uses the process of inspection and adaption to finely tune team performance. I believe there are many ways you can decide how to form your Scrum team from individual team members. One thing is for sure though, Tuckman’s Theory of team performance which defines the four phases, Forming, Storming, Norming and Performing holds true. Also to help you get through the Storming phase, the RACI matrix comes in very handy for resolving conflicts and creating role boundary clarity. Neither of these theories or tools are covered by the Scrum Framework, but both are essential to get you through the initial phases of creating your Scrum Teams. As time goes by and team members begin to get used to working with each other, team trust increases and this manifests itself in the form of increasing velocity. So, velocity becomes a useful indicator of team performance and where the team stands along the Tuckman curve.
Many people are sceptical of self organising teams, they believe team members cannot work without the traditional command and control management. But I can guarantee you will be surprised how well the teams self organise themselves after a few sprints and become much more motivated due to the autonomy that empowerment gives them.
Overall take away. Scrum is based on many years of research into what drives high performing teams. Scrum is a success story and has been implemented by thousands of organisations around the world. Believe in the Scrum Guide and implement it in its entirety and you will reap the benefits of this empirical experience.
