Inspired by the recent conversation in YouTube between Allen Holub and Dave Farley, I started to contemplate about all the different events that occur during the development process in companies that claim that “they’re agile”. Even the claim of “working in an agile way” can be brought to question.

Do you work for such a company? Maybe you’ll find yourself in this post.

Let me be clear, that I am in no way some agile expert or a coach or anything. I’m simply a developer who’s interested in agile and wants to discover better ways of working, having seen different work process’ in different companies.

Agile

Some of us have been introduced to agile at some point by a manager who says:

We do Scrum here. We’re agile.

That’s it.

Nobody in the organization asks or tells you to read the actual agile manifesto, located here. Why? Because most of those managers or supervisors don’t know what agile really means. They probably haven’t even read the manifesto themselves. They’d rather just give you the Scrum guide and order you to follow it. (I’ve actually never been advised to read the manifesto by anyone in organizations that I’ve worked with or for.)

By definition agile is very simple. It is what is sounds like. Agility in development. You embrace and adapt to change. You talk to people instead of relying on a project management system. You collaborate with your customers to deliver software early, instead of agreeing to a contract defining what to deliver with a fixed cost in a fixed timeline.

Most of use have come to know agile by using Scrum. But Scrum in itself is not agile. Not, if you follow its guide to the letter.

Scrum is not agile

As Allen Holub has mentioned many times, nowhere in the manifesto does it say you have to have sprints, refinement or planning sessions, or reviews. That’s just the way we’ve been taught to work due to the high adoption rate of Scrum in different organizations. The only thing the manifesto says is to hold some type of a reflection session at regular intervals. In Scrum, a retrospective is held on a fixed date after a fixed time (sprint length).

The Scrum guide in itself, however, is directly opposed to the agile manifesto. It is actually quite rigid. Here’s a couple of quotes from the guide:

Changing the core design or ideas of Scrum, leaving out elements, or not following the rules of Scrum, covers up problems and limits the benefits of Scrum, potentially even rendering it useless.

Essentially, follow Scrum to the letter or you’re not doing Scrum or even creating hidden problems for yourself. That’s not very agile.

Sprint Planning initiates the Sprint by laying out the work to be performed for the Sprint.

Create a plan for the work to be completed during a fixed time period and stick to that plan. What happens to that plan if there’s a change here? This sounds a lot like you’re doing mini waterfall development.

During the Sprint: No changes are made that would endanger the Sprint Goal;

So, your team has agreed upon a sprint goal (to deliver something of value) for the next few weeks, and no changes can be made to the sprint to endanger that goal. You must complete that goal by any means necessary during a set timeframe, even though you’re supposed to stay agile and adjust if you learn something new. And something new comes up during that fixed period, believe me.

So Scrum is not agile. It’s not a software development method. It’s simply about project management. And don't all managers love management?

What is agile, is taking ideas from Scrum and creating your own development process so you can work in an agile way and continuing to work on it. You can call it your process that takes ideas from Scrum, but it’s not Scrum.

“Responding to change over following a plan”

We’re supposed to be continuously improving, so that we can deliver value faster. Still, there are too many things that slow you down. Most of these are things that your company has set up because the people there do not understand agile. They want fixed dates, they want to know estimates, the cost.. That’s just how they operate. Unfortunately, that’s not agile. They are not thinking in an agile way. They are thinking in an industrial way.

Scrum is essentially a mini waterfall delivery process. It’s creating a plan for a fixed timeframe. I’m not even gonna talk about SAFe which has an even bigger waterfall. However, with Scrum or SAFe your company gets the certainty that in a specific timeframe (2-4 weeks) developers will complete certain items, they know the estimates, the delivery dates and can calculate the cost, even though it's for a smaller timeframe.

This also brings accountability into the mix. While most of the companies I’ve seen don’t go blaming people directly for missing a sprint goal (or a product increment goal), I’ve often heard criticism when a team has committed to a goal bigger than they can deliver. That’s the blame game, but in a smaller scale. In their mind, someone has to be held accountable when something doesn’t get delivered.

Things never go as you plan. We can’t complete some things because we learn new things, but we can’t adjust. We hit a roadblock. We have a dependency somewhere that slows us down and we miss the deadline. We stumbled upon a bug that we have to fix before we can deliver. We had to refactor some poorly implemented structure to support our work and we didn’t have time to look at the code before the planning session.

The reason for a planning session is to estimate the fixed amount of work you can do on a fixed timeframe.

No matter how many times I’ve tried to be prepared for the planning session to cover everything, something has always come up. I’ve never thought of every possible scenario during a planning session. And I myself have gone against the value of the manifesto back in the day.

Roadblocks and speed bumps

Your development process might not be the only thing slowing you down. In a normal company setting, there are typically numerous different obstacles in our way. They may stop our development or simply slow it down.

Over the years I’ve encountered multiple different events and organizational challenges that have ended up slowing down my work. You may recognize some of them.

• You have to think about the dependencies with other teams before you can work on the item and perhaps need their input before starting the work.
• You have to attend retrospectives and other ceremonies "just because" even though no one has contributed to them in years.
• You spend days worth of time doing PI planning for the next three months because some genius had the brilliant idea of using SAFe to bring 'agility at scale to their enterprise'. You forget that plan completely the next week when you start working on the items for your next sprint.
• You discover that dependency when developing which can cause you to stop your work because you have to go ask another team their input.
• You have a separate IT department that provides you with resources you need. Such as access, credentials, cloud resources..
• You have a separate OPS team which have their own backlog of items they work on and you have to ask them to allocate to you the resources you need, be it a member of their team or just time from their schedule.
• You have an architect/senior developer who has to tell you how to do the work because they tell you what to do and how to do it, so that it gets done right.
• You use feature branching where your work goes to a development / quality assurance environment to be tested before it gets to production ‘some time later’. Those tests are run manually for each work item.
• Before your work gets merged to a development branch, it has to be reviewed by another developer, perhaps from another team, who has no knowledge of the problem that you have been solving
• Your manager hands in your work load for the next sprint, because he's the one talking to customers and knows how to prioritize the work.
• You’ve actually never met a customer, or a user, while working there and your manager/product owner acts as a middle man, when you want to have a conversation with this entity. This causes delays because messages get relayed. It can also cause you to waste the time of a sprint doing the wrong things only to be discovered during the review that happens 2-4 weeks later because there was a mistake when relaying the wishes of the customer/user.
• You have to use Jira, so that your company has everything in one place and can monitor you work and move the discussion to a tool instead of people talking to each other.

These are but a few of the things I’ve seen slowing me down during development. But how do you solve them?

Have your teams create their own development process

A majority of the speed bumps mentioned above can be solved with one thing: team autonomy.

Teams should be the ones creating their own development process. Not companies. Not some senior developers that want to impose it to all the teams because it worked someplace else. The team itself should discover the best way to work.

As it says in the agile manifesto:

Build projects around motivated individuals. Give them the environment and support their needs, and trust them to get the job done.

Teams should have autonomy in this. Autonomy to discover the best way to work. Autonomy to build the solution the way they like it. They should also interact with each other to continuously evolve the way they work.

You should build cross-functional teams that contain the expertise needed to do this. Often this means everyone should know what software or infrastructure architecture is. They should know how to embed security into their development process. They should talk to stakeholders directly and deliver valuable software early. They should be able to deploy the resources they need to the environment of their choosing without having to ask someone for permission or access.

However, most companies are fixated in believing people can’t do the work unsupervised and without being monitored. Sure, there are people like that, but teams themselves should have a set of standards they uphold and make sure it doesn’t happen.

I refer you to read The Five Dysfunctions of a Team, by Patrick Lencioni, which is a team building strategy. One of the dysfunctions is low standards and avoiding accountability.

Teams should hold themselves to a specific level of quality and work, making sure every member works to complete the goals the team has set for itself. Before you can have a set of standards you need to build a foundation of trust and make sure everyone is committed.

Throw Scrum away

Be bold! Create your own development process. Here’s a few ideas from the top of my head:

• Stop using fixed sprints with fixed work loads and instead opt to a more continuous Kanban style flow, where you have a list of work items that you keep prioritizing constantly.
• Work on the items that are most important until that list of items is gone, together as a team.
• Maybe look at that backlog for 5-10 minutes each morning with the team to think about the priority but leave it at that. If something new comes up that causes you to change priority, you can easily do it.
• Never have a backlog that’s longer than three months worth of stories. Everything beyond that is outdated knowledge.
• Set up refinement sessions when ever some of those items seem like they’re too big and need chopping down.
• Don’t do retrospectives after each sprint. Set up an Andon Cord. A mechanism for team members to alert each other when ever they feel like there’s a problem that needs to be addressed immediately. Don’t mull on that problem for two weeks. This way you can learn and change course immediately.
• Share your successes during daily stand ups. Don't just be a robot and list the things you did yesterday, what are you doing today and do you have any blockers.
• Improve on a daily basis. Not just at the end of a sprint.

And just have fun! No one wants to work in a way that makes them miserable.