Let me answer this question by describing an actual situation.
I once coached a programme of teams at a large corporate that had to automate a manual and laborious business process onto an off-the-shelf product. This programme 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 programme needed to implement Scrum because it would help with faster delivery. When I arrived the teams had been set up, consisting mostly of contractors from different contract houses. Project Managers were in-house and expected to be Scrum Masters as well. Teams were supposedly dedicated, but the programme 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 set up for failure and that Scrum would be blamed. I thought that by focusing on Lean principles without worrying about doing Scrum right initially, it would start them thinking about improvements to their value stream and eventually lead onto adopting either Scrum or Kanban later on.
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.
Programme-level impediments:
- 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 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 answering this question, 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 decided to start them off on this path, and bring in the learnings of complexity later. I felt that that this was, for these teams, a useful place to start.
What would you do? Please leave me a comment below.
Ciao.