I get many questions in my trainings, and one of the most common is when to use Scrum – usually preceded by utterances of “Scrum will never work in my team…” The wording of the question below comes from the Scrum Alliance Certified Team Coach (CTC) application. So this topic is relevant, and there is no one answer.
When might you advise a client to apply XP, Lean or a non-Agile approach to workflow instead of Scrum?
Let me answer this question by describing an actual situation. Read on for my thoughts.
I once coached a program of teams at a large corporate that had to automate a manual and laborious business process onto an off-the-shelf product. This program had been working in a waterfall manner for a year and had managed to automate a small subset of the business process.
A new CIO was employed and decided that this program needed to use Scrum because it would help with faster delivery. When I arrived this is what I found:
- Teams had been set up, consisting mostly of contractors from different contract houses;
- Most people had received an Agile Bootcamp training focusing on Scrum;
- Project Managers were in-house and expected to be Scrum Masters as well;
- Teams were supposedly dedicated, but the program manager repeatedly moved contractors in and out of the teams;
- The deadline had already been decided by the CIO.
It became apparent that the teams were not set up for success and that the program would revert to using a waterfall process. I thought that by helping the teams focus on some of the principles of Lean without giving their way of working a label, that it would start them thinking about bottlenecks to their workflow and identify wasteful activities.
The Rationale Behind This Approach
Major organisational impediments which due to the nature of the organisation (size, structure, and politics) were outside of the teams’ control to resolve resulted in an interrupted value-stream, but for which they were being held accountable. Here are some of them:
- Data sourcing – each business process was multi-layered with multiple data sources which the teams did not own nor have access to. Obtaining data required a long process with multiple approvals;
- Environments – development, test and production environments were being built at the same time that the team needed them to do their work.
- Teams were not stable – people moved in and out without notice to them and the Project Managers;
- No Scrum Masters – Project Managers were expected to also be Scrum Masters – this created a conflict of interest and anti-patterns began to emerge;
- Teams did not own their full value stream and yet were held accountable for delivery;
- Each business process to be automated was 1 large story because they were not easy to break down into user value items;
- Teams consisted of more than 10 people and had 3 Product Owners.
I recommended that teams adopt Lean principles and visualise their work, in its imperfect form, and start improving where they could because:
- The Product Owners were present and involved – there was a real effort on their part to help teams break their work down into manageable chunks taking into account the organisational impediments;
- By visualising the workflow as it was they would start to see where all their bottlenecks were and having the teams and Product Owners focus on customer value they would begin to identify wasteful activities;
- For me, it was also important to help teams see that their current process was not value-creating, and by regularly looking for improvements they would start to look for different ways of getting around that which was seemingly outside of their control.
There are other ways of addressing this type of problem, such as using a complexity frame and the Stacey Complexity Model. As with all things that relate to coaching, the context of the organisation and the maturity of the team are important. In order to help them become unstuck I guided them along this path and brought in the learnings of complexity later. I felt that this was, for these teams, a useful place to start.