Being agile when developing software

Here we have some of the dictionary definitions of the word “agile”:

  • able to move your body easily and quickly or to think quickly.
  • able to move quickly and easily.
  • able to think quickly and intelligently.

It all comes down to something that moves quickly and easily. But does Scrum really move quickly and easily?

After working with Scrum in several projects, I have had the oportunity of seeing different implementations of the methodology. Some of them were more pure, others were more flexible. But after all of those examples, on every new project I work on, that claims to use Scrum, I ask myself the question: “is this really Scrum?

I am sure we all have been in the following scenarios at some point:

  • Tickets with no estimation
  • Sprints that end with a lot of things on the TODO column
  • Not enough details on tickets
  • Velocity of the team is unknown
  • Retrospective sessions with no action items
  • Sprints with unreadable or weird burndown charts
  • … and so on.

Or heard one or more of these phrases:

  • “This new story is priority, lets add it to the sprint!”
  • “… let’s skip the retro for this sprint”
  • “Scrum has to work for us, not us for Scrum”
  • “Its hard for us to follow Scrum because we are a startup”
  • … and a lot more.

Although the idea of this article is not to explain Scrum from scratch, I will try to make a point of why I think that Scrum is not agile, in the common meaning of the word.

Let’s start with the basics: what is Scrum?

From scrum.org, we have the following definition:

Scrum is a framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.

This framework, applied to software development, allows the team to face a changing context, delivering value frequently and adapting to change in a smooth way. This methodology was born with the Agile Manifesto in mind, so it falls under the Agile methodologies category. Let’s see a sumary of it.

Scrum Roles

The methodology re-arranges the team in 3 simple roles:

  • Product Owner: knows the priorities and needs of the product we are building.
  • Scrum Master: leads the implementation of Scrum and removes impediments.
  • Development Team: developers, testers, designers, etc.

There is no figure of “Project Manager” role, or any other hierarchy. The team works together and manages itself as it sees fit. There is no hard limit on the size of the team, but the recomendation is 10 as the most. If we have more people, then it would be better to build two or more teams.

Scrum Ceremonies

Scrum, as every other methodology, has a given set of ceremonies that need to happen, in order for the whole process to work effectively. Below there is a list of the main ceremonies and a summary of the main goals of each one:

  • Standup: daily sync meeting. This is the place where any impediment is made known to everyone else, so this can be fixed quickly.
  • Sprint planning: create the commitment for the next sprint, which is formed by the tickets that will be worked on. They are decided with the priorities in mind and also with the team’s velocity.
  • Backlog Grooming: the team gets together and discuss each ticket, adding details, asking relevant questions, and then estimating them. The estimation then allows the team to calculate the velocity.
  • Sprint Retrospective: a meeting to discuss what was done well in the last sprint, and what needs to be improved.
  • Sprint Review: a demonstration of the work done on the last sprint to the stakeholders to see if what is being built is what we need to be building. Priorities may change, and this meeting allows the team to switch gears into different features.

These ceremonies, as you can see, have specifics goals. Failing to perform them, will impact on the rest of the process. For example, poor grooming implies inability to plan correctly, because tickets will have fewer details, therefore are not entirely estimatable.

Scrum and the software development cycle

Scrum divides the development in fixed length cycles called “Sprints”. Within each sprint, all of the known stages of software development take place:

  • Requirement analysis: while executing a given sprint, the team performs grooming sessions to work on backlog items (which will be implemented in future sprints).
  • Design, Implementation and Testing: each ticket goes through this stage while being worked on in the sprint.
  • Deployment and Maintenance: at a glance, every sprint ends with a shippable product increment, which will eventually be deployed and maintained. The frequency of these deployments depend on each project and organization.

So if scrum does the same as all other methodologies, what is the difference? The main difference is that Scrum does not allow goal altering changes happen during a sprint. Each sprint has a fixed set of goals that specify the north of this iteration. So we cannot change the tickets that were commited on the Planning session. The following are some of the consequences:

  • Sustainable pace: the team has a certainty of what will be worked on during the sprint, with no noise (changes) coming in the middle of it. Morale raises, since the team knows that is working on the most important items.
  • Velocity is known: finishing the items on a given sprint without changes to it allows the team to know its velocity, therefore improving the planning, not just for the sprints, but for releases or bigger cycles.
  • A hard limit is being set to the whole organization: through Scrum, the team is saying to stakeholders: “Ok, according to the priorities that you provided through the Product Owner, we commit to finish the implementation of this set of items. You will have another oportunity to change priorities after the sprint is over, but NOT before.

Scrum’s risk payment

So at this point, if I didn’t loose you along the way, you are probably thinking “Ok, but what happens if the stakeholders discover, in the middle of the sprint, that the priorities are no longer valid?”.

That is a pretty valid question, and the answer, in my opinion, is:

  • In order to provide sustainable development pace, a clean process, and frequent shippable product increments, Scrum is willing to take the risk of working on something that ends up being unnecessary, for the duration of a sprint.

When we compare this to traditional methodologies, the risk of loosing work is small. If we go back in time, Waterfall methodologies may ended up wasting months of work. Scrum has checkpoints (Sprint Review) after every sprint that allow inputs from the context to modify the destiny of the application.

So… Is it agile or not?

Of course it is, but not in the common meaning of the word!

The important thing to realize is that the methodology itself is very restrictive:

  • Fixed ceremonies, where the methodology states what to do in each one of them, the frequency and moments they have to happen in, and also who are the participants.
  • Roles, with the corresponding responsibilities.
  • Artifacts that consist of tools to support the methodology (such us the backlog or the definition of done).
  • The shield that Scrum provides to the Sprint to forbid goal altering changes.

Seems like a very restrictive framework, right? So, why did I say before that Scrum is not agile? Well, sadly, in my opinion, people want to have all the benefits from the methodology, without paying the price or doing the work.

Having a chance of changing priorities every two weeks sounds promising, as well as having shippable product increments very frequently. But in order to have those, we need to follow the process. Every aspect of it is important for the whole thing to work correctly. Every ceremony, team role, artifact, has a very specific goal that helps us to get those benefits.

In other words, Scrum is not agile in the common meaning of the word, since you cannot change directions in any given point in time. Instead, it is a restrictive methodology that follows the Agile Manifesto.

Follow up readings

I leave you here some readings that I recommend:

  • Agile Manifesto. Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert Martin, Ken Schwaber, Jeff Sutherland, Dave Thomas. 2001.
  • Software Development: Agile vs Traditional. Marian Stoica, Bogdan Ghilic-Micu, Marinela Mircea. 2013 (Paper).
  • Guide for Writing Requirements. International Council on Systems Engineering (INCOSE). 2017
  • Essential Scrum: A practical Guide to the Most Popular Agile Process. Kenneth Rubin. Addison-Wesley, 2013.
  • Test-Driven Development by example. Kent Beck. Addison-Wesley, 2003.
  • The agile samurai: How Agile Masters Deliver Great Software. Jonathan Rasmusson. The Pragmatic Bookshelf, 2010.