‘Agile Working according to Scrum’ is a topic that is still in high demand in my business, even if the underlying ideas are older than 20 years. I am still committed to that type of working method and the related values. In my view, Scrum is exactly the right thing for teams that want, or rather need, to address complex tasks and ever changing requirements.
I have successfully supported already many such teams in transitioning their way of working to the Scrum framework – with all that this entails: new roles, very clearly structured meetings, dedicated sprint change days, a sprint backlog, and an emergent product backlog. The feedback I gather from Scrum teams is that – thanks to Scrum – they are able to maintain the overview who is currently doing what and who is possibly in need of some help, whereas the managers concerned tend to observe a reinforced sense of responsibility within the team and an increased quality of the work results.
However, I do not want to talk about these teams today, but about those who ask me to facilitate change towards agile working, and where we ultimately realize together that the full Scrum framework is not the best solution at that moment.
There are many reasons for this insight. Here are two of the reasons as examples: it might be the case that the team is under so much pressure at the relevant time that even small changes lead to an undue level of stress for most of those involved. Or, it might be the case that Scrum roles cannot be filled since, for example, none of the team members is interested in taking over the Scrum Master role. If the criteria of voluntariness in conjunction with curiosity are not fulfilled when filling Scrum roles, then in my view the Scrum framework should better not be introduced. That said, I'm especially referring to the Scrum Master role, which I think is incredibly important as it is the Scrum Master’s enthusiasm that might pull the rest of the team towards ‘agile’ working.
Teams that, together with their team leaders, want to make their collaboration more efficient and want to smoothen their communication, can make a first step towards agile working methods (without introducing the entire Scrum framework) by establishing a Task Board similar to a sprint backlog. This Task Board should include all the current tasks of the team members involved. These tasks have to be broken down into smaller work packages; the processing time for such work packages must not be longer than one to three days. This Task Board only makes sense when combined with a 15-minute Daily (a daily meeting to organize the team’s workflows) that follows the agenda set out below: 1. What tasks have I finished? 2. What do I want to do next? 3. Are there any impediments in my way?
If this daily coordination meeting already means too much interference with existing workflows, it is possible to have a meeting for workflow organization take place only twice a week, with such meeting taking no longer than 30 minutes each time.
Transparency and communication will surely improve even as a result of this step alone. Just try it out!
The next step towards ‘agile’ in my view involves regularly holding retrospectives where collaboration is discussed by all team members together. If these meetings are held in reasonable intervals and with due care, the teams are empowered to take over responsibility for how they work together. This is a very important aspect in increasing the quality of the work results – which is, in my opinion, a much more important step than control can ever be!
However, in order to ensure careful implementation of a retrospective, teams need a qualified facilitator. Since people in most organizations have no experience whatsoever in addressing topics that really move them, they must be encouraged to do so by a professional facilitator who ensures that a safe place is established for this purpose. A retrospective that suffers from time pressure and is conducted with half-hearted facilitation shouldn’t be held at all. Because it is only when things are allowed to be addressed honestly and openly by team members that effective measures can be developed from within the team. These measures developed within the context of the retrospective have the potential of moving the team forward in terms of an efficient and solid collaboration.
In a nutshell: Yes, becoming ‘half-agile’ as a first or second step may be an option towards establishing a full Scrum framework. More importantly, it is better to start off with the first two steps described above than to expect too much of the team and/or the manager as regards their willingness to change (which, of course, depends on the current workload). This should not imply that a team that is keen on introducing Scrum, with all its benefits, cannot and should not switch directly to working under the Scrum framework. It’s always your choice!
This text first appeared in my newsletter 'Innovation on Wednesday'. It is published every other Wednesday. For subscription click here