Why are our Agile tools complex?

There are so many Agile tools out there in the world to use. And so many of them try to be very, very, very helpful. Even so, I’ve often found that a team, a group of teams, or even a whole organization has implemented one of these helpful tools and then decided to make the tool “do more work for us,” “automate things for us,” “organize things for us,” and more. The result? Comments like this: “I just added the user story into Tool X, but I can’t find it.”

So often, people’s very best intentions to make a tool work better for us inadvertently make the tool work against us. Our schemes for the perfect tool configuration frequently miss what we think is a rare case but is actually an all-too-common occurrence for a few – if not many – teams. It’s at times like these that I often go back to the good old Agile Manifesto and read the first value: Individuals and interactions over processes and tools.

Individuals and interactions over processes and tools.

When people need to fight against a tool, what happens? They create more workarounds in the tool and hope that people will remember this “special” way of doing something. Do we, as humans, have an operating manual for the tool and update it when we do these things? I doubt it. If we do have that manual, do the people new to using the tool – or even those who have just gotten confident using the tool correctly – know to read the updated operating manual? I think most people would say, “there’s an operating manual?”

A simple Google search for something like “Jira workflow” will return pages full of vendors and examples with solutions to all your problems:

I’ve seen teams implement all these gates that a story or task roll through. Sometimes a story doesn’t even need to go through the work of a gate – but the tool requires those extra stops anyway. Can you imagine the Kanban board that is associated with this workflow? It may have a great many columns, or the various gates may be grouped into a single column. Does the team know when that work is done in that column? Do they all remember the workflow? What if a story needs some additional work done that is not in the norm? How can we apply this first value within the Agile Manifesto? Yep – simplify and increase transparency. In my experience, most Agile tools reduce transparency and increase complexity as soon as you start adding things you think will help. My advice: whether this is a whiteboard with sticky notes or a digital tool, make it simple and let the people guide what needs to be done.

The reason I like a simple board like this is it brings autonomy to the team. During Sprint Planning, the team forecasts the Product Backlog Items (PBIs, or user stories) they think they can fit into a sprint. They craft a Sprint Goal that helps the team chase after the Product Goal. The whole team works together to plan the specific work to change that PBI into a small slice of a working product that then adds to the Product Increment.

I like that while there is a Definition of Done (DoD) commitment to the Product Increment, the work completed to meet that DoD can differ from the PBIs that were forecasted to fulfill the Sprint Goal. Notice the different number of tasks and even the different flavors of tasks (lions and sharks).

And talk about transparency – this chart is loaded with information. We can see that the team has a good level of focus: not all the tasks are in the To Do column. In fact, some work is getting to Done on the top (highest value) User Story 1. Maybe Task 2 in User Story 2 is started early because the team has identified a dependency on a different team. This should be something to watch – maybe add a fun sticker?

Each day during the Daily Scrum, the team can review this board and ask that easy question: “how do we get closer to fulfilling our Sprint Goal?” Maybe the tasks could be done differently. Maybe adding a few tasks to one story will help us take away a whole other user story. The team gets to be creative and work together on finding the right solutions. Maybe the team can do a task differently that still meets the DoD but incurs technical debt. Is that debt something we want to incur in favor of releasing this functionality early for our customers?

My advice: whether this is a whiteboard with sticky notes or a digital tool, make it simple and let the people guide what needs to be done.

You don’t have to be using sticky notes to simplify processes and increase transparency. All the digital Agile tools can be configured to be – well – simple. Try it out. Let the team members figure out if they want the tool to do more for them. Don’t create a complex template that gets rolled out to every team in the organization.

Once you have started to simplify your tools, select methods to measure the progress; in particular, focus on the amount of time an item remains in the backlog from initial ask to delivery (cycle time) and the total output of items (throughput). These sorts of measures are best to understand the number of PBIs in the backlog and how many of them will get done, on average, in a single Sprint. Focusing on these metrics should help keep the backlog simple as well – if it’s loaded with hundreds of items, that cycle time will just keep increasing if new ideas keep coming in. Focus is a key Scrum Value that applies to the work of a person, of a team, and of the product being built.

I would be remiss to not mention adding specific outcome measures for the product – and understanding how each backlog item helps achieve those outcomes. Most teams, I find, are focused on outputs like velocity or defect rates, and they completely leave out the value that the customer should experience with the new features and abilities the team has enabled. It’s like asking only if the car is running well – and not if the car is getting us to our destination (the value of using a car). Both are important.

What can you do within your team or organization that will help turn your tool into something that helps the teams instead of making the teams dread using the tool? As I spend time this evening in my woodshop making some furniture, I’m sure I will always gravitate to the tool that makes my life easier and happier.