Want to be more Agile? Focus less on the tool.

Image for post
Image for post
Photo by Michal Vrba on Unsplash

It’s been two years since the company I co-founded in early 2017 has pivoted to become almost exclusively focused on helping traditionally bureaucratic organizations achieve agility. As we’ve worked with organizations of various sizes and complexity, we’ve noticed that almost all of the problems that are encountered during the transition are common ones to the so-called “Agile Journey”. Misalignment between development and PMO, lack of empowerment at the team level, managers posing as Scrum Masters, the list goes on. Most of these issues have been written about at length. As we’ve rolled up our sleeves to take on many of these expected challenges, we’ve noticed another more subtle anti-pattern that is often harder to detect — even among the more savvy agile developers. If I had to guess why, I would suppose it’s because it often presents itself as a solution.

Image for post
Image for post
Photo by Olga Guryanova on Unsplash

I’m referring to the workflow tools — most commonly Jira — and the hugely misguided belief that as long as we are writing our work and entering it into an Agile tool, we have moved the needle on our organization’s Agility. Don’t get me wrong — tools like Jira, Rally, Pivotal Tracker and even RTC are extremely useful to track and manage work across teams — but this assumes your organization understands the fundamentals behind them. We’ve noticed a recurring theme among organizations early in their transition to agile:

The focus on the tool takes such a prominent role in an organization’s adoption of Agile that it causes the fundamentals to be overlooked.

This almost always leads to an adoption of technology that causes an organization more harm than benefit.

Here are 8 indications that <fill in your agile workflow tool here> could be making your organization less Agile:

Image for post
Image for post
Photo by Austin Distel on Unsplash

4. Development is more siloed than ever —

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. — The Agile Principles

Jira simply does not know or care if your team is cross functional. The natural tendency for organizations used to local optimization rules (i.e. traditional cost accounting metrics) is to become as efficient as possible at the component level. Because they have always been measured this way, teams dutifully split up by skill sets (for local optimization) and create beautiful component backlogs where they can work unimpeded until the end of a Sprint or even Program Increment before they toss their work over to another team and hope it meshes with the items they’ve built from their own wonderfully siloed backlog. Connecting teamwork to organizational strategic roadmaps typically takes oversight and guidance. It will not naturally happen by using the agile tool. Instead of getting caught in this trap, build teams that can deliver features on their own. For specialized skill sets, require your specialists to cross train other members of the development team. Each story must be connected to the larger enterprise capabilities, goals, and integrated solutions. It’s OK if this slows the teams down at first. At the system level you should begin to see improvements, and that’s the only metric that really matters to your customers.

5. Measurements are promoting local optimization, not system throughput —

Working software is the primary measure of progress — The Agile Principles

What gets measured gets managed — Peter Drucker

If we buy into the Agile Principles, then why do we continue to measure teams’ performance by how fast they produce items of no value? Choosing program-level metrics that address the cross-functional outcomes that we are trying to change (e.g. product quality measurements, coordinated hand-offs, etc.) is important in every program increment. Leaving this up to tool metrics that measure a team’s individual velocity, especially when they are organized as siloed component teams, will of course yield siloed metrics. These metrics are micromanaged with no real benefit to the value stream besides driving up overhead. Instead, allow the teams to use their burn-down rates and velocities for their own inspect and adapt activities and focus program management on system level outcomes — like feature lead times, process times and percent complete/accurate. Creating a simple value stream across the organization may be helpful to take a larger view. We’ve observed that most organizations will find that bottlenecks not visible to management are the actual limiting factors to value delivery, and that focusing on the rate they are closing tickets at the team level is only making the problem worse. Providing a system view, as opposed to team level metrics, will help bring attention to this and allow management to focus on what is actually impeding flow through the value stream.

Image for post
Image for post
Photo by Vlad Bagacian on Unsplash

6. Features/Epics are duplicated throughout numerous backlogs with different wording — This is related to #3 but represents another concern — organizations that rush to add Epics and Stories into their backlogs. There seems to be a belief that Agility means that I ought to throw any idea that pops into my head onto a backlog and let someone else make sense of it. Organizations would be much better off screening their work before entering into a planning tool. Try starting with a planning board where features are roughly mapped against program milestones for the year. After the whole system view is captured, teams can be assigned and backlogs appropriately populated. Getting everything into a program level view first should ensure that features are not duplicated, and priorities are aligned with milestones and dependencies. There really should be no rush to write tickets. Take your time, look at the whole system view, and then decide what value the teams need to deliver.

7. Using stickies and a board freaks everyone out — if the team can’t function without Jira, there may be a problem. We try to recommend teams get comfortable with Scrum before they begin using an electronic tool, and it’s surprising how aggressively this is resisted. But the truth is that the highest performing Scrum teams that I’ve observed all use physical boards. That actually includes the Scrum teams that build these tools! Walk into Atlassian’s development space and you will find boards with post-it notes everywhere. Ironic? Hardly. The developers of these tools understand Agile, and they know when the tools are needed and when they are not. Do they care if your team is using it when it would be better off with post-it notes? Of course not — the software is your drug and these companies are thrilled that you are hooked. While you’re off demanding some new feature in the next release that will solve all your delivery issues, these guys are writing it down on a post-it note and working together as a true Scrum team to deliver just enough value to keep you believing in the fantasy (and paying your subscription.) Try to get your team to experiment for a Sprint without Jira. Even if you go back right away, the experience may help create better work habits.

8. Work is assigned and worked by individuals and not teams This may be the most insidious of anti-patterns because it seems the tools almost require it. We all know that Scrum is by definition a team activity and that teams are collectively responsible for everything. Sure, certain individuals will take primary ownership of specific activities, but the big picture concept is to allow the Scrum team to collectively agree to what it’s going to deliver (based on a backlog prioritized by business value). The team also decides how it is going to accomplish this and deliver something of value, typically in the form of working software. Given that, try to assign a User Story to the collective team. It can’t be done! When tickets get entered into a system like Jira, we assign an individual who becomes responsible. I fall into this trap myself. As soon as Jim is assigned a Story, it becomes “Jim’s Story.” That’s an anti-pattern that needs to be corrected. When we start communicating in this manner, it’s all but guaranteed that the rest of the development team will remain hands off on that work until Jim either asks for help or finishes the work. Instead, when a developer finishes a story, he should not immediately jump to the backlog for the next story, but instead see which assigned stories in the current Sprint are still To Do and ask how he can help. The goal is to get the team to work collectively. I find this much easier with a physical board, where we can gather around our User Stories at Daily Scrum and ask, “What can we as a team do today to move this Story from in-progress to done?” It’s difficult to achieve this mentality when we assign tickets in Jira, and because of this the team benefits of Scrum are often missed.

Image for post
Image for post
Photo by Tommy Lisbin on Unsplash

Getting teams fundamentally aligned is a delicate issue. Our challenge is to lead teams to Agility through an understanding that comes from experience and not mandate. Not too long ago at big room planning event retrospective, where I was participating as Product Owner for a small Release Train, we had another team suggest that it would be much easier to do everything on Jira and eliminate the need to get everyone together for 2 full days — greatly reducing the amount of time and money required to conduct such an event. Seeing that the idea was being received quite favorably — especially amongst the management team present — I flew into a semi-tirade, announcing that I believed Jira to be the enemy of Agile and that, beginning with this PI, my team will only be using a board and stickies. This approach caused a lot more harm than good, and when I did this, I undermined my own team’s ability to self organize. Thankfully, they felt comfortable pointing this out at a subsequent retrospective. So we let the team decide. Yes, they chose Jira, but we worked together to build awareness around the potential pitfalls and adjusted our behavior when it was called for.

It’s not surprising that culture shift is difficult and cannot be accomplished by decree. My work as a change agent only begins with identifying which behavior is working against the organization — the real work is getting teams to understand why it’s hurting them and gaining their trust as you help them to correct it. The shift only happens through an understanding grounded in experience. Our work is creating opportunities to build understanding through experience.

I’m curious to hear how others accomplish this — any thoughts or suggestions please leave a comment below or drop me an email. But please, no tickets.

The Startup

Medium's largest active publication, followed by +752K people. Follow to join our community.

Official Medium Account of Centil

Written by

Centil is a development and consulting firm specializing in driving efficiency across product development pipelines.

The Startup

Medium's largest active publication, followed by +752K people. Follow to join our community.

Official Medium Account of Centil

Written by

Centil is a development and consulting firm specializing in driving efficiency across product development pipelines.

The Startup

Medium's largest active publication, followed by +752K people. Follow to join our community.

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store