Scrum is Not For You

I always pushed the Scrum button to make our project live – thinking it is the ultimate answer to a better and faster delivery. Working with teams, interacting with many IT professionals, and being a Project Manager myself – this is the same pattern I have seen mostly all around; we go in auto pilot mode to choose Scrum as our delivery framework. To think of it why – it’s obvious – out of all Agile frameworks, Scrum is one of the most detailed (with its own Scrum guide to help one understand how to apply it) which makes it easier to use.

However, in the last three years or so, I have broken my Scrum spell after seeing the patterns in teams and projects that I would be covering in this blog to emphasise why Scrum is not for you too.

1. Sticking to Waterfall Mindset – it’s true old habits do not die fast- most of the IT folks started their career in the times of when Waterfall was single-handedly carrying the software delivery weight across companies. When the digitalisation era came, Agile came. While we were trying new ways of working with Agile, we never became truly agile. There is a common trend I have seen across – Scrum teams turn their sprints into mini-waterfalls, as one of my Product Managers rightly pointed out.
   
   To give an example – when a sprint starts, the developers begin working on their tasks/stories – be it design or development – and the testing team works on their test cases. The stories come into testing towards the very last of a sprint. In principle, what the team is doing – they are taking all their requirements into the design and development phase and they move on to the next stage of testing and deployment. Ideally, in Scrum – the delivery should start happening on Day 1 of the sprint. The below burndown charts will bring more clarity.
   

   Consistent Team Delivery vs Team Delivering at Sprint End

2. Time Boxing Sprint, But Not Decision Making – Product Managers and Business Owners should take the heat for this one.Scrum follows a time-boxed approach – everything from sprint to events are time-boxed. Your sprint scope should be finalised in sprint planning itself – of course, there can be a room to wiggle few small adjustments to requirements, but what ends up happening –
   • Product Managers/Business Owners priorities stories for the sprint which are either not fully refined or researched which many a times stretch that piece of work for several more sprints
   • Scope changes in the middle of the sprint due to a new critical request by investors/business owners. When these arrive sporadically, teams struggle to plan effectively
     

     Unclear requirements result in unclear timeline

     Because of these factors, which if it is happening more often than it should, a Scrum team would never be able to achieve time-boxing and will be struggling to complete a sprint timely and maintain its velocity.

3. Having Heavy Approval Processes – In an environment where teams are constantly struggling with IT Desk/Support Functions/Business Owners approvals for any access, licenses., tool usage or for any process like business acceptance testing – such environments make it difficult for the teams to have proper backlog planning and stable sprints. Teams face high risk of unpredictability and delay in delivery due to these factors.
4. Committing Only to Tasks, Not to Product & Vision – The implementation of Scrum seems easy – thanks to the detailed Scrum Guide – however it requires strong individuals and teams to get the maximum benefits of Scrum. In order to achieve a sprint and product goal in a time-boxed sprints and releases, individuals cannot work in isolation. I have seen individuals do the following things –
   • They will wait for their Scrum Master or Project Manager to assign them the work instead of having of picking items from the backlog
   • Focus on their own delivery instead of sprint goal delivery – not having idea of what others are working in the team
   • Sticking to the requirements as is instead of understanding the benefit it brings to the customer and designing a better solution




5. Having Large Scale & Complex Projects – Coordinating with multiple teams, managing team dependencies and maintaining a product roadmap for all teams – there are complexities that one faces with large-scale projects which cannot be solved by Scrum. In my experience of working with large scale projects, I have seen both success and failure of projects and most of the times the failure is due to communication & collaboration between the teams. To have an effective communication channel in large teams, one must think of a large-scale framework beyond Scrum.

Metcalfe’s law states that the value of a network is proportional to the square of the number of its connected users.

Having talked about all these patterns I have seen in my experience is not indicative of Scrum is a failed framework, it simply points out why Scrum may be the wrong tool for your project delivery. It’s like using the fork to apply butter to your bread.

Understanding these limitations will help you make a decision whether you need to either explore other frameworks like Kanban, SAFe, or the traditional Waterfall model OR will help you fix the limitation which is hindering the team to reap the benefits of Scrum. The goal is not to use Scrum because of its popularity, but because of its necessity in your project.