Scrum issues: being agile isn't easy..

I do a lot of consulting work and because of this I see lots of different development processes at many companies. Some of them are good, but most of them are not. And this problem isn’t caused by lack of trying, but of lack of expertise. Most - if not all - software development departments I visit try to be “agile” by implementing scrum. But unlike what many people think, implementing scrum in an efficient way isn’t that easy. It takes time and effort on ALL levels of a company. If your clients, or IT department aren’t ready to do scrum, then you won’t succeed either. You could of course, implement some of the facets of scrum, but scrum - it is not.

But even when everybody is committed to do scrum, things can still go wrong. Too many times, customers, managers and CTOs still consider agile to be a really great thing, because it made us get rid of all the documentation upfront and we can have our application in blue one day, and change it to red the next day. How cool is that!? But scrum has some downsides: we always wanted to get rid of the “soo many meetings” culture, so obviously, we don’t do all the scrum meetings. After all, developers aren’t productive if they aren’t behind a computer.

This is one of the hardest things to teach people when teaching scrum. It’s much more efficient to have people think about things before we actually develop them. Scrum isn’t synonym for: “code first, design later”, it’s about prioritizing your needs and produce through small iterations a step-by-step system that you can control. It takes more time on both sides: as a team, you need to deliver more, and as a product owner, it means you have to sit down with the development team (why aren’t they getting what I asked them to do?!). But this is the other side of agile and scrum: without these “downsides”,  the benefits of scrum cannot exist.

Over the last 2 years, I’ve seen many things that go wrong in scrum processes, and I like to highlight a few of them:

Sprint retrospectives

One of the first things that will be eliminated when doing scrum are the sprint retrospectives (by this time, unit-testing and documenting are already a thing of the past). Most common reasons: “we know what we did wrong, no need to discuss it”. “We don’t have time to do meetings the whole day” and even “we need to keep a positive mindset, a retrospective will just bring the team down”.

A sprint retrospective meeting is the ONLY feedback loop into your next sprint. It’s a “stop - think - act” moment where the team will try and see what the good things of the current sprint where, which needs to be continued, what the “bad” things where, so they aren’t brought into the new sprint, and most importantly, see how things can be optimized. And having an optimized workflow in your team will increase the teams velocity. When this meeting is skipped, things that will not have been optimal in the current sprint, will not have the change to improve in the next one. The team can slide into a pattern where bad habits aren’t noticed anymore which results into a loss of velocity and - maybe even worse - good and clean code.

Focus on increasing velocity, not high velocity

This sounds strange, but think about this: if you come into first place - two things can only happen: you win again, which is probably the expected result, or you come in 2nd (or even lower), which results into disappointment. There is no situation here that will result in exceeding expectations.

The same will be true for scrum-teams. It is much more effective for teams when they see that they improved over the previous sprint, then when they haven’t gained anything since the last sprint - even if the team is doing well.

This is true for teams with a low velocity, but this is just as much true for high velocity teams. Differences in velocity result in a more positive (or negative) look at how things are being done.

But it’s not always the velocity that is leading. Always aim for more momentum, but there are other things that might be improved: more or better code coverage, lower bug counts and priorities etc etc

The team has the final say on the sprint log, not the product owners.

Obviously, if it was for product owners and stakeholders, the whole backlog would have been added to the current sprint. But during a sprint log, the team will look at the backlog, get the highest priority stories and add them to the current sprint. They estimate how long a story will be (there are several ways to organize this meeting), but in the end, the team will have a list of stories and issues they are comfortable to put dedication on finishing before the end of the sprint. Over and over again, we see product owners “force” their features into the sprint, breaking the holy trinity of development: time - resources - features. As more features must be added without changing time and/or resources. Many times, the team is rendered unarmed: saying no isn’t an option to the customer or boss, so things have to be added, with results ranging from more bugs, less clean code, to even missing scrum deadlines. Customers will yell at teams, while in fact - they are to blame for their failure. As a scrum-master, it’s probably one of the hardest task to say no to product owners in order to protect the team. Like managers, a scrum-master must protect the team at all costs and make sure the team can develop in the most efficient way.

None or incorrect metrics

One of the key points of scrum (but pretty much every system) is that you need metrics in order to know what you are doing, and how you are performing. Without metrics, every meeting, every scrum sprint, every backlog story that gets written is pretty much useless. If you have no idea how much a story point is (be it hours, be it complexity), there is no point in trying to plan anything. The same goes for the teams velocity: even if you can estimate a story is worth 6 points, how much do you know you can handle in the sprint all together? (and what is 6 points, might as well have been 6 cupcakes, or 3 escalators, or maybe 7.5 forrest fires). You have no idea if you improved your sprint if you cannot measure, so you have also no way of knowing what you are doing wrong (or right).

Ultimately, the customer will have the problem. If a team cannot estimate properly, there is no way of knowing if deadlines can be made. A team can only “try” and every guess is as good as the next one. Without measurement, there is no performance.

Not updating burndown charts

It can be a tedious task to update the burndown chart every day. But doing so result in the team and scrum master to see immediately how the team is doing. More often than not, it is not until the last 2 days the team realizes it cannot finish all the issues in the sprint and most of the time this will put the team into “frantic mode”. A stampede of wild buffalo’s would be much more organized, and in fact, such a stampede would probably get more done in the end than the team.  Extra overtime is made in order to get the issues fixed, sloppy code gets merged just to make sure everything is ready for the demo. Imagine if this would happen in every sprint (I’ve seen it happen). No matter how good the team’s spirit is, it will ultimately break when this happens a lot.

Continuously prioritize the backlog

What needs to be done in the next sprint changes from day to day. Let product owners make decisions: you can get feature A, or features B, or  feature C, D and E.  There are 3 options and they have to choose. It will not be possible to have A and B in the same sprint. or A and C, D and E. It’s the product owners who decides what is important, but they need to be aware that with more insight, backlogs change and feature A may not even be relevant anymore. But also things can change for the team:  C, D and E might not be possible anymore in one sprint with more insights. Maybe they are harder to incorporate in a later stadium (for instance: implementing an access control system might be easy from the start of a project, but in a full-sized project, this will be much harder usually).

Not taking time to prepare your meetings

Last minute merging and deployment into the acceptance environment. Sometimes, this even happens DURING the meetings! There is nothing worse than demonstrating the features you’ve build and tested the last two weeks, to find out it doesn’t work when showing it to your customer. “Normally, you would have seen a thank-you page, instead of this exception” doesn’t really cut it for a customer. For them it doesn’t matter if you spend the last 2 years on this feature: it just doesn’t work. They do not get the things you as a team as committed to.

But this doesn’t have to be the teams fault. In many cases, it’s the product owner who is at fault here. Too much features that are being “forced” into the sprint didn’t allow the team to take the time to test, deploy and prepare the demonstration meeting. If on the last day issues are still not picked up, you cannot simply assume that two hours later those issues are designed, thought over, developed, tested, merged and accepted.

As a team, you must take control and take the time to prepare. If it takes a day to get everything up and running, make sure you plan this during your sprint plannings. If you don’t get this time from your product owners, well.. this is about the time to reconsider if scrum is actually a good idea.