Scrum, the hard parts

If your team is trying Agile for the first time, then there is a big chance you guys are using Scrum. Scrum is an easy proposition at first glance, push out product increments at a consistent pace with stakeholders feedback, who would say no to that? Obviously, there is a lot more than what you see at the surface, effectively doing it is hard, implementing Scrum in a company that has been doing waterfall for ages can be highly disruptive, it tends to create naturally side effects that can be hard to overcome, that is especially true for web software.

Continuous deployment?

The way a sprint is handled works against continuous deployment processes. As you are leading teams into a sprint the attitude tends to be toward achieving the end goal of finishing all the stories, it is a much simpler goal than deploying as stories get done.

Code freezes

When there is only 2 or 3 days left to a sprint things can get hairy, the team is often pushing to the finish line, QA is testing the last details. Some sloppiness can crack in and the way companies tend to deal with those issues is to fall back to old ways. One of those is the code freeze. Where there is a code freeze, there is new code waiting on some branch to be merged. This delay can have major impacts, merging can become more difficult, versions can diverge making the whole workflow harder for everyone.

Manual QA story testing

Testing stories individually is not always simple, even with a good test plan stories can affect each others and before you put them all together there is no certainty. This often creates a double testing effect, when the QA guys get stung because they did not test enough stories inter-dependencies they will often start to test twice a broader range of functionalities. This also can create a QA bottleneck and suspend deployment, and now we are back in the code freeze.

Steps to continuous deployments

• Move your sprint sign off to each story instead of per sprint. This will also affect the sprint review meeting, and it should now be a lot shorter.
• Move your story deployment an item in the definition of done.
• Automate deployment & testing to a point where you can be confident to release without manual QA every step of the way.
• Make story deployment a simple click that the product owner can do.

Simple, right? The important thing is always to start with small improvements and move your way down the list. You will have to take full advantage of your PO and SM, it’s important not to let finished stories in a suspended state when. Stories need to be pushed down to “ready for prod” as fast as possible.

Daily issues & task

The primary goal of a sprint is to produce business value; this becomes harder when a team needs to deal with daily issues that always prompt the priority of the sprint.

This all goes down to priorities. It’s the job of the PO & SM to make sure the team can have a laser focus on the items of the sprint. When you insert hotfixes into the mix, you break that focus. Sometimes those hotfixes are required, but it is important to have a clear grid of severity so that managers understand why their bugs will not be done in this sprint.

Using a severity grid should reduce the number of requests accepted in a sprint. You should also revisit your definition of done, are the stories executed and tested correctly?

Architecture

Scrum has nothing to say about how to handle software architecture, and since it focuses so much on producing business value, this cocktail makes architecture often take a second role within a scrum team.

One way to fix that is to implement a pre-sprint grooming where you gather senior/architect devs to refine the stories on a technical level. This is also the time to talk about missing architecture bits, if architects aren’t part of the scrum team this can be a dependency work item on that particular story.

Another idea is to have architects part of a resource pool that can be added to a scrum team to help achieve individual stories that require skills missing in the scrum team. If the scrum team executes the architecture, it is important the story points reflects it. Architecture should not be something taken lightly and must be examined by the senior people in the team.

Architects: Chickens or Pigs in an Agile Development Process?

Innovation

Scrum is excellent at prioritizing items that the business think is important, but is not exactly good at letting innovation flow from the scrum team itself. It’s one thing to improve stories together with the PO; it’s another to get the PO to take an 180 after prioritizing everything with the stakeholders.

However, that’s the kind of innovation that can make the business take bigger leaps. One way to fix it without disrupting sprints is to implement quarterly hackathons. Let the devs & product designers reign free together for 2 or 3 days producing product ideas for the business. Then take those ideas back to stakeholders and you will see the prioritization of your backlog items shifting.

Running Your First Internal Hackathon
Open Data Hackathon How to Guide

Closing

When scrum starts to fail, one would be tempted to switch from scrum to another methodology. In reality, scrum often exposes issues within your processes & teams that are necessary to fix to achieve better productivity, switching to another process may only move your problems.

Identify those bottlenecks, work hard at fixing them.