In this article, part of my series explaining better ROI from software development, I’ll be looking at some of the pitfalls of Scrum. If you are not familiar with Scrum, please refer to my primer here
A brief note on intended audience; this article is not intended as a training guide for Scrum. There are a lot of resources out there – much better than I could every produce that teach Scrum well. This is much more an introduction from a Return On Investment perspective aimed at business leaders.
I’ve already said in my previous articles that Scrum isn’t perfect.
In this article I discuss some of the short falls of Scrum. Where possible I will look at some of the mitigation that can be put into place.
The Scrum Guide specifically doesn’t cover scaling to multiple teams. The guide is intended to be as focused on the Scrum process as much as possible – as such it avoids subjects outside of it.
It can be very common however for organisation with multiple teams to stumble a little when trying to handle the interactions between multiple scrum teams.
Rarely are these insurmountable problems which cannot be solved without common sense thinking.
Most problems are resolved by ensuring as little dependencies as possible between teams. Those dependencies will generally be where most of the productivity and efficiency pains are felt. One team maybe need interaction & coordination with another team – and have to wait until they are ready. Removing as many of those dependencies as possible helps.
There are Scrum+ methodologies which build on the Scrum Guide to specifically address scaling; SAFe, Less and Nexus (the latter of these is written by the same authors as the Scrum Guide). If you feel you are reaching the point where scaling is a problem, then take a look at them.
It is fair to say that this will likely be environment dependant – so look at you individual environment and what is causing you problems. Generally I would expect most problems to be resolved locally rather than needing one of this additional frameworks.
Must organisations are unlikely to ever really need them.
While I talked about the Product Owner as being a benefit in the last article, it is easy to see a situation in which they are insulating the Scrum Team from the rest of the business.
One thing that Agile pushes towards is a fully agile environment. Everyone in the organisation being bought into the principles – from board down.
Scrum really stops its methodologies at the Product Owner. The Scrum Master is expected to evangelise and promote Scrum into the wider organisation – but there are no specifics within the Guide.
Without that wider understanding, there could be considerable friction between different states of mind.
The wider business is likely to be used to Gantt charts, details dates, tasks and responsibilities. They want a plan that they can look at and hold.
Unfortunately, as experience shows us, these plans are generally nothing more than a crutch to make everyone comfortable that everything is going to be ok.
That same experience shows us that those plans are generally inaccurate. The longer and larger the project, the less reliable any plans will be – and the more expensive to produce.
But these truths can be difficult to educate an organisation with. If they are used to a way of working, that change can be a slow and painful event.
It isn’t uncommon for one of the chief arguments against Scrum (or Agile) is that someone wants a date by which it is done. Getting that mind set changed can be expensive (although ultimately worth it).
Modern culture sees meetings as a bad thing. We are wasting time in meetings rather than getting the job done.
And having spent a considerable period of my career in meetings with limited value, I can have sympathy with that notion.
The key thing here is focusing on why the meeting occurs and getting the value from it.
If you look at each of the Scrum meeting, they have a specific reason to exist – and if you don’t understand what it is, then ask. Each will give you benefit … if done correctly.
If done incorrectly, then you are back into normal wasteful meetings in which people are disengaged and very little (if any) value is generated.
Each meeting should be focused on it goal … get in, get done, get out. Avoid time wasting. Those people in that room have things to do – be courteous to them to not waste their time.
In the same respect, don’t rush them so much that you don’t get the value.
This can be a difficult line to walk. Especially given that people do come with a negativity towards meetings.
Overtime, with good leadership and coaching, then this mind-set will change.
Ok, one of the more painful ones for me.
In organisations that have been used to “just-in-time” (or who-shouts-loudest-wins) development, then being asked to wait till the start of the next sprint can be difficult to implement.
This is where support for the executive team is paramount.
Remember; each Sprint should be working on the highest value item(s) for the organisation. If however that “highest value item(s)” change during a sprint, then there is always the option to cancel the current sprint and start a new one. But this should be considered a traumatic event – one which is highly impacting on productivity (and thus ROI).
I find that it is rare that genuine situations happen that frequently and cannot wait – especially if you use a 2 week sprint (best of productive vs investment in my personal opinion).
When I say rare, I would consider an environment that needed to do this twice a year needs to think about how it priorities its work.
There are methods of “take the edge off” – such as working to shorter and shorter sprints – but this is likely papering over the cracks. The reason these changes are occurring are generally something else that it occurring outside of the team.
I’ve said before that Scrum will shine a light on problems. Maybe this is a problem elsewhere that needs to be addressed.
If you are moving from a traditional waterfall manner of planning to Agile/ Scrum implementation, you will invariable hit situations where two parts of the organisation are working in different manners.
At any point where your organisation is working across those process boundaries then expect friction … a lot of it. Unless you manage the dependencies well, then it will be a constant source of problems. If left unchecked, then it can be a real blocker to any expected productivity improvement.
Interesting Garner has put forward the idea of Bimodal IT for exactly this situation (see http://www.gartner.com/it-glossary/bimodal/). To me however, you will still have those friction as activities and dependencies cross process boundaries. At the very best, I would consider Bimodal as a means-to-an-end … definitely not the destination.
Again, this is something that will need to be managed through. The more that you can remove dependencies – the less this becomes a problem.
While Scrum (and Agile) help your organisation handle change – the biggest change will likely be its adoption.
This can be very scary to people. They may have decades of personal investment in their career & processes – and you want to screw with that!
The people in the team will need to adopt new ways of working, new skills and possibly even different job titles. This can and will make people nervous – this maybe affecting their future employment prospect and thus food on the table. Some people won’t like being more team focused – they enjoy being a lone wolf or even a hero – a team isn’t going to give them the same feel. Some people are simply scared of change.
And it won’t be just the people directly on the team. Anyone that interacts with the team need to understand the change and work with it. This is from board down.
In this, adoption of Scrum or Agile is no different than managing any other change through a business – it just needs to be considered and managed appropriately. Questions needs to be asked and answers provided. Roll-out and communication strategy really helps to reduce that friction.
Focus will need to be put on to addressing concerns right through the organisation to make this as smooth as possible.
This concludes this article and the sub-series on ROI of Scrum.
In this article, I’ve attempted to highlight some of the pitfalls and problems in adopting Scrum. There are plenty more and I will likely pick up some more in future articles.
It is important to remember however that problems are likely to be different between organisations or even different teams in the same organisation. There will never be a one-size-fits-all solution. As the Scrum Guide says itself ...
"Scrum is: Lightweight, Simple to understand, Difficult to master" http://www.scrumguides.org/
The key (and why I recommend Scrum) is that it provides a framework to handle those inevitable problems. In doing so it moves you from a delivery focused organisation to a learning/ problem solving organisation. Maybe more on that in future articles.