Do you work in a Scrum team and think scrum sucks? Well, chances are you’re right - your scrum sucks. There are Scrum team members complaining about scrum more than ever, and scrum advocates telling them: Scrum is great. Your problem is that you’re not implementing scrum properly. Scrum states blah, blah, blah.

I disagree.

There is no point in implementing Scrum strictly, but if Scrum team members are complaining then chances are there is something that needs fixing. In fact, the best way to go is to be very flexible about your version of Scrum and bend it to ensure your version of Scrum supports your goals.

Scrum itself is not a goal. It’s a framework to help us be agile. Heck, agile is not a goal either. It’s a methodology to help us deliver more value in the right direction, faster. Quite simply, to implement scrum in a useful way, we need to remember what our goals are and we need to continuously check that our scrum (and processes in general) support our goals.

Let me give you an example.

A close friend of mine, let’s call him John, is a web developer at an exciting 2 year old startup. They recently implemented Scrum. And he has plenty of wonderful things to say about it; loves the Product Owner’s vision and contribution, enjoys the collaborative environment, etc. But, he’s getting burnt out. Sprint after Sprint with no downtime is exhausting! “Is this good for the business?” He asks.

No, it’s not.

It might be the Scrum way to measure and improve velocity, and to start the next Sprint right away. But it doesn’t have to be their way. Startups are a marathon, and burning out does no one any good. So who cares about what the rules are. Figure out what works for your team. Suggestions would be:

  1. Find a sustainable pace. Slowing down is sometimes the right thing to do. It keeps you rejuvenated, creative, and happy!
  2. End sprints on Friday morning with the retrospective and review meetings, and don’t start the next sprint planning until the next Monday. Keep Friday afternoon relaxed to catch up on other work and clear your minds.
  3. Introduce the ‘20 percent time”. One day a week where everyone can work on projects that aren’t necessarily in their job descriptions. They can develop something new, or fix something that’s broken.

Point is don’t fixate on whether or not you’re Scrum. Be honest about problems and open to solutions. Evolve your processes constantly.

Often when we disagree with one another we look for rules to… well, rule. We fix our conflicts by looking for company policies to follow. Scrum, unfortunately, has been used as a set of rules to clear conflicts in how things should be run. It’s counter productive. It’s much better to be flexible and develop your own version of Scrum that works for you.

Scrum itself can be agile. It can evolve incrementally just like you evolve your products. Get feedback from your team, learn and iterate. Your entire Scrum framework is up for improvement. What meetings to have, what roles to add or remove, etc. It’s all about what works for you.

Agile software development was born to uncover better ways of developing software products. Products that are delivered faster and better solve the customer’s needs. The agile manifesto states:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

By applying Scrum we don’t become agile. On the contrary, we value agility and we use Scrum to help us focus on the items on the right.

Does your Scrum make you agile? Share with us in the comments below.