How Agile Is Your Process?

Individuals and Interactions over Processes and Tools
Responding to Change over Following a Plan

When teams and organizations look towards better agility, they generally start with one of the known frameworks out there – most often Scrum but also SAFe or many of the other agile methods. But one of the key principles from the Agile Manifesto says:

At regular intervals, the team reflects on how to become more 
effective, then tunes and adjusts its behavior accordingly. 

What this says is that, over time, we should be getting better and better in how we work and deliver. But oftentimes this ends up running counter to the process we have in place, and it is difficult to know what to do in those cases.

Scrum by any other name

Team Grasshopper has been working with Scrum for a while. They’ve been very successful so far in delivering features to their customer. They all sit together in an open room with plenty of whiteboards, so conversation seems to flow freely throughout the day. At the end of Sprint 9, the team has a retrospective. Julia, the team’s ScrumMaster, is facilitating.

“OK team, one thing we wanted to do this retrospective is focus on our process itself. Let’s start with an open conversation and I’ll capture the data.” Julia moves to the whiteboard. Jackson, one of the developers, speaks first. “You know, I appreciate the idea of the daily standup. But it seems like we don’t have much to talk about there. After all, when we have a blocker, we put it on the board immediately, and between our Scrum board and the conversations throughout the day, we all know what we’re working on.”

Roberta jumps in. “That’s a great point, Jackson. Also, I noticed that our customers – especially Jessie – could benefit from more frequent demos so they can talk to the other vendors in advance of Sprint Planning. It seems like we should be checking in with them every week, but I know we can’t do planning any more frequently than every two weeks because of their schedule.”

Team Grasshopper is at a crossroads. If they stop doing daily standups, and move sprint demos to be weekly, but sprint planning still every two weeks, aren’t they violating the rules of Scrum?

Individuals and Interactions

Part of the confusion for teams such as Team Grasshopper, as I mention in Recreating Scrum Using Kanban, is that they don’t own all aspects of their process. Scrum is predicated on several implicit policies which come out of choosing your sprint length. So if you have a two week sprint, you do Sprint Planning every two weeks, Sprint Review every two weeks, and Retrospectives every two weeks – that is implied because of your sprint length.

As another example, in the Disciplined Agile Delivery framework it is implied that you will use iterations and demo at the end of an iteration. Or in SAFe, it is implied that if you are “Scaling Agile” you use a Team, Program, Portfolio approach.

To be clear – these aren’t necessarily bad things. For many teams and organizations, it provides a clear, proven starting point. But it isn’t clear to teams how to modify the process and still get the value – in other words, the “why” that backs the “how” of the processes. This is critical to move beyond selling the term “Agile” and moving towards true agility While many of the methodologies are backed by a set of principles, the idea goes beyond just principles. David Anderson refers to them as “properties” in his Kanban book, but perhaps the most familiar way of understanding these “things” is via Design Patterns.

Towards a Pattern Language

Let’s imagine a team that is having communication problems. They struggle to know what the other members are working on. So one force is that they need to find a way to communicate more frequently. However, another force is that you are dealing with multiple people, so you need a way of making it easy for them to remember when to do it. The third force is that if we are going to have frequent communications, we don’t want them to be overtly long – they should be self-limiting.

With that problem and those set of forces, we can look towards the pattern Daily Standup. The team will come together to coordinate their work, on a daily basis so there is a clear cadence, and stand up to help remind the team that this needs to be high-impact and no longer than it needs to be.

This same team needs a way to help their customer understand the work they are doing. The first force is that the customer can not sit with them all the time. The second is that their customer isn’t a software developer, so they can’t just see code. The third force is that we need the customer to be able to help make decisions of what else they want – recognizing that they won’t know what they don’t want until they see it. This leads to a fourth force – if they don’t know what they want until they see what they don’t, we need to get working software in front of them as quickly as possible.

This set of forces leads to the pattern of System Demo. Which, like Daily Standup we’ll want to set a cadence for. Talking with the customer and the teams, weekly seems about right to be able to demo working software in a way that gives the customer enough information to be able to influence the backlog or at least be thinking about what they want.

By looking at our practices in this manner, we begin to explicitly own the process we use by determining policies based on the patterns in our specific situation. Once we own the policies, we can make the decision of when to modify them, since we understand both the challenges, as well as the principles behind our goals.

Lean Thinking

The idea of explicit policies is core to Lean Thinking through the principle of Standard Work. Teams document their actual process as the standard way of working. They then inspect that process, allowing innovation and individuality to shine a light on it, and then as they modify it, they document that as the new standard. For example, in Kanban we start with where we are – meaning we document our value stream, and then document the explicit policies of work (see Recreating Scrum using Kanban and Explicit Policies). We then observe the flow of work, and modify our policies as appropriate.

…Over Processes and Tools

Back to Team Grasshopper. Their struggle is not with their process, but with the idea that they don’t know how to modify Scrum to fit into the process they need. This isn’t Scrum’s fault per se – one could easily modify many of the methodologies to include guidance on how to pay attention to the principles and modify as they see fit. But the Agile Manifesto is clear – Individuals and the Interactions come before Processes and Tools.

In the end, Team Grasshopper ended up making their policies explicit, which helped them understand how to track the principles behind the “Why” of the practices. They moved sprint demos to weekly, and kept Sprint Planning as every two weeks. They cancelled their daily standups, but added a retrospective board to their scrum wall to keep a close eye on the communication between team members to make sure that they did not see a drop off in communication.

Your team can do this as well. You own your process – not a consultant, not a website, not a training, not a book. To modify it, you need to understand the principles and patterns behind it – so it’s OK to start with a set of prescriptive practices at first to see what needs to change. But remember that it’s you and your team’s interactions that come before any process and tool. Modify your tool for your process – don’t modify your process for a tool.