How to Diagnose Why Scrum “Isn’t Working”
A lot of software development teams switch to Agile development in order to solve some immediate problems they are experiencing. A few sprints in, it becomes clear: the problem wasn’t solved. It’s easy to want to throw in the towel and go back to your old software development methodology. Yeah, there were problems before, but it felt like you knew the scope of your team’s problems.
It’s also easy to blame Agile for why your team is struggling in the first place. But, before you cut bait with Agile, let’s try to identify some common problems Agile teams face and how to use that information to create your own solutions to improve your software, increase your timeliness of delivery, and increase the satisfaction of your team or customers.
Your Culture Needs to Be More Agile
There are several organizational aspects that help a team adopt Agile, including enterprise-level support, transparency, and asking for the right information.
- Enterprise-level Support – Culture is driven from the top-down. That can also mean that the culture is to encourage bottom-up:
- Support and interest for developer or team lead innovation
- Interest in new engineering techniques, like DevOps
- Recognition that sometimes focus on organizational maturity models (like CMMI) can stall the goal of delivering software that meets your business goals. It’s easy to focus on documentation as the be-all-end-all, but remember that that’s not what creates business value.
- Transparency – Telling people exactly what you are doing is scary. When you don’t do a lot, it’s hard to show people that you are making progress. If you find your Scrum team is surprised at the end of an iteration with work that you thought was done, but isn’t, you need to improve your team transparency.
- People Aren’t Asking for the Right Information – Just as I’ve already addressed how organizations need to focus on achieving business results over and above achieving a certain level of documentation, the same can be said for measurements and metrics. Your leaders need to be informed of what the right way to effectively measure progress is. While Earned Value Management (EVM) is absolutely possible to do in Agile, generally speaking, EVM can be a challenge to Agile teams. But, what also happens is that Scrum teams will “do Agile” without carefully measuring work planned against work completed (story points vs. completed points on your sprint burndown). (Reread Transparency above.) Without knowledge of the right information to ask for, executives will ask for the wrong information. So, do everyone a favor by being transparent and doing your Agile measurements properly.
You Need to Improve Your Software Engineering
I often hear Agile teams talk about how tough it is to do development AND testing in such a short period, and why don’t we just do testing in a different sprint? Because that introduces risk! Ken Schwaber talks about how work in progress is inventory waste, one of the seven deadly wastes from Post-World War II Japanese manufacturing. Keep your risk low by getting to done-done, not developer-done in one sprint. There are a lot of software engineering practices that help your Scrum team work smarter, not harder. Your team should look into:
- Automated deployments
- Continuous integration or continuous delivery
- Automating testing at all layers:
- Automated unit tests
- Automated integration tests
- Automated acceptance or UI tests
You are Getting Fancy Without Thinking About the Basics
Especially when starting out, it’s natural to want to do Agile in a way that doesn’t cause lots of organizational disruption. So, terms like “Scrum-ish” get tossed around. Fine. Go for it. Just make sure that you focus on what’s important:
- ScrumMaster – Make sure this person wants the job. Make sure they care about making the team successful. Make sure that they spend most of their time working on impediments and unplanned work—not developing—especially if your team is still struggling.
- Product Owner – This person needs to have a product vision, and be able to make effective business decisions about product priority. If the person can’t do this, maybe you have the wrong Product Owner. The Product Owner also needs to be able to effectively manage up and out to stakeholders and executives. Part of the Product Owner’s job is to protect the Scrum team from the fray.
- Ceremonies – Focusing on the daily Scrum, the Retrospective, and the Product Review will increase communication, collaboration, and transparency. Don’t skip Scrum just because developers don’t like meetings. Make it a meeting that people feel is important, and try to dial back all the other meetings you make them go to instead.
So, these are my three guesses as to why Scrum isn’t “working” for you. But, just remember:
Agile and Scrum don’t solve your problems, they only illuminate them.
So, what do you think? You knew that software development would be slow and buggy, but a known-known is better than an unknown-unknown, right? What other challenges has Scrum or Agile illuminated for you?