Photo by Pixabay from Pexels

“We tried Scrum, but it didn’t work for us”. No, you didn’t. “We did everything by the book”. No, you didn’t.

Personally, I know that at enterprise level, Scrum is not an optimal framework, as the nowadays enterprise environment is global (vs co-located), with outsourced services, complex domains and development and operations (run and maintain) reside on separate budgets (CAPEX vs OPEX). So, I’m rather a supporter of DAD (disciplined agile delivery) with an interest in SAFe, because Scrum covers only the development part and not the transition to Operations. BUT Scrum is definitely a good framework for development, a quite simple one, as long as you stick to it. If you abandon its basic principles, then that’s not Scrum. It may be a form of agile, but don’t complain that Scrum doesn’t work.

Here are some of the things I’ve seen recently:

Taking in new stories during the sprint – that’s fundamentally wrong and against scrum principles. Business reasons may arise and that’s the common excuse, but if we’re talking 2-week sprints, with the planning in day 1 in the morning and the feature freeze roughly in the 7^th working day, that’s poor Refinement. The sprint backlog is owned by the dev team and it may change if Dev team finds things as they advance with the development (ex: incompatible technology, refactoring needed, dependencies, etc). Simply taking in new stories, overrides commitment and any planning done, not to mention the opportunity to ask questions and clarify open points.

Accepting stories that are not yet ready – if you are using JIRA, user stories have a lifecycle of their own and can be declared ‘Ready for development’. That means the story has been reviewed, analysed by an architect and developers, all questions have been clarified and once brought into the sprint, people can start working on it. Otherwise the time that should’ve been spent developing and testing the story is used to clarify it.

Not paying attention to the daily call – the daily / stand-up call is a critical meeting and a short one. Just 15 minutes. If you can’t focus for 15 minutes, you have an issue. The point of the daily call is to be aware of what everyone else is doing, hear if there are any blockers (things that might affect you as well) and inform if you’re out of work. We’re not there to discuss details or solve things in the call, unless it’s a straightforward answer.

Ignoring the feature freeze – Ok, the feature freeze is not something you will find in the scrum guide. But it has a good purpose: to stop all development, make a deployment and allow for enough feature testing and regression testing, to be able to fix most of the defects before the demo (review).

Taking in stories over the team’s capacity – usually the scrum master observes the team’s velocity, is aware of everyone’s availability and allocation and computes the capacity. Exceeding from the start this capacity has no justification. “We’re just gonna start it” does not make sense. Stories should be small enough to fit within a sprint and all work is done just in time. If you get to work overtime to finish them, that’s not the team’s true capacity! Overworking people is more than disruptive and (at least in democratic countries) cost inefficient (vs bringing in a new dev team member to be able to deliver features / epics on time). You can find here a good capacity planning template.

Leaving out of the planning tasks that are mandatory – At the end of a sprint, typically a formally documented deployment is done. Regression testing must be done (not estimated when people vote for a specific story). If a patch has been applied to the environments or some new version of Java will be used, you need specific testing. Updating generic documentation. All these take time and affect the team’s capacity.

A Scrum Master will warn against all this and explain why it’s wrong, but if he’s ignored, then that’s not Scrum and maybe the company / department / project is not mature enough to be Agile.