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.

Comments on this entry are closed.

  • Scott Ambler March 11, 2014, 12:14 pm

    Cory, great blog posting. Just wanted to share a few thoughts:
    1. A team should definitely own its own process, although sadly I suspect that most merely “rent it”. See http://disciplinedagiledelivery.wordpress.com/2014/03/03/does-your-team-own-its-process-or-merely-rent-it/ for some thoughts.
    2. What you’re talking about in terms of process patterns the Disciplined Agile Delivery (DAD) framework addresses via its process goal driven approach. See http://disciplinedagiledelivery.wordpress.com/2013/01/21/disciplined-agilists-take-a-goal-driven-approach/ . Very similar to process patterns although potentially a bit more straightforward.
    3. Instead of prescribing a single way of doing things, such as holding a demo at the end of an iteration or sprint, DAD instead suggests that you address the process goals in the way that is best for your team. DAD explicitly gives you choices, although it does suggest some potential defaults (such as holding a demo at the end of an iteration/sprint) to give you a decent starting point. The choices are summarized in goal diagrams, see previous URL for examples, and each choice is described in terms of advantages, disadvantages, and contextual advice for when to consider following that practice.
    4. The DAD framework also supports multiple life cycles. You referred to the basic/agile lifecycle, an extension to the Scrum approach, where the default is to perform a demo at the end of an iteration. DAD also supports lean, continuous delivery, and exploratory life cycles (think Lean Startup). In those life cycles it’s suggested that demos should be performed on an as needed basis. See http://disciplinedagiledelivery.wordpress.com/2012/12/20/a-full-agile-delivery-lifecycle/ for a discussion of some of the other life cycles (now that I look at that posting, it needs to be updated. Argh).
    5. By giving people explicit choices, and contextual advice about them, it enables them to tailor and improve their approach more effectively via some light weight guidance. I recently wrote about improving your effectiveness with retrospectives in such a manner at http://disciplinedagiledelivery.wordpress.com/2014/03/06/improve-retrospectives-with-process-goals/

  • Ronald Jeffries March 27, 2014, 7:02 am

    I think this story represents a problem that is rare, if it ever happens at all.

    Is this team taking on a load of work at the beginning of the Sprint, and almost always getting that much done, and almost always absolutely bug free, and almost always with clean code?

    If not, standups are not their biggest concern.

    If they can do that, they will have already learned long ago whether to keep doing Scrum by the book.

    Regarding DAD: If you can’t ship working software out of every team, every couple of weeks, DAD won’t help you do that. If you can do that, DAD is more than you need.