The Startup
Published in

The Startup

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

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.

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:

Photo by Austin Distel on Unsplash
  1. Your team prefers writing tickets to face-to-face communication This is the most common anti-pattern that the tool will unfortunately help promote. People that spend most of their day on a keyboard (coders — of course, but probably most of your engineering team too) are inherently more comfortable communicating with email and messaging. The tool provides the perfect excuse for not having a conversation — after all, isn’t it better to have everything documented in the Jira ticket anyway? The answer really is no. One of the fundamental principles of Agile is that the most efficient and effective method of conveying information to and within a development team is face-to-face conversation. The founders of the Agile movement understood how easy it is to misinterpret ideas and concepts that are written down and handed off. Face to face forces two key things to happen — first, the need is communicated at the same time that the developer is about to begin work (see item 3 for more on the shelf-life issue) and second, ambiguous direction can be cleared up on the spot. Teams that understand Agile don’t stop using Jira, but they understand that a User Story is a reminder (card) to have a conversation and then confirm understanding of the need before they begin coding (see Ron Jeffries: Card, Conversation, Confirmation from 2001.) Organizations new to Agile miss this every time. When miscommunications occur (and they always occur), the knee jerk response is “we need to write better tickets” or “everyone needs to follow the prescribed user story format”. Instead, when you encounter these issues with your team, try to encourage face-to-face dialogue as a solution.
  2. Management thinks that if the teams are using Jira, they must be Agile — Sometimes this means management will direct teams to directly convert their requirement sets into Epics, Features and Stories, and likewise convert SLOC and bottoms-up hour estimates into story points. “Voila!” Agile conversion complete. As backwards as this sounds, it’s exceedingly common. If someone’s only exposure to Agile is a two-day SAFe® training course and he/she has been managing waterfall development for the past 20 years, this outcome is actually just what you’d expect. A good change agent must anticipate this and work with leadership to ensure that the big picture fundamentals that underpin the transformation are clearly understood. The big picture concepts are much more important than the mechanics — that is, the philosophy behind agile estimation techniques and the use of story points are essential for management to fully grasp first. Only then will the mechanics bring benefits.
  3. Your backlog is littered with stories that are over a year old, but no one thinks they can be deleted — We usually tell teams to scrub their backlogs and get rid of any item more than a year old. The resistance to this is surprising. If we agree that in its initial form the user story is nothing more than a card to remind you to have a conversation with product management, and that conversation hasn’t taken place in over a year, what could be the harm in trashing it? If that same need comes up again, then rewrite the card. There’s almost a 100% chance that something’s changed since you wrote the story a year ago, so even if it’s still a valid need, you will need to rewrite it anyway. In reality, the reluctance we observe is an indication that the team has converted waterfall requirements into user stories and is intent on delivering them as is. It also indicates that communication between the user/customer and development team could be better. To overcome this, create a backup of all your Zombie User Stories. Next, without making a big deal about it, delete every old item that hasn’t been worked out of the planning tool altogether. When people freak out, ensure them that everything will be safely maintained in your new Excel file for posterity and you are happy to add any item back into the planning tool if the need is validated with the customer. Your teams will thank you for making their life simpler, and management will appreciate not having to carry the additional incomplete work on their books.

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.

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.

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.




Get smarter at building your thing. Follow to join The Startup’s +8 million monthly readers & +756K followers.

Recommended from Medium

Dependency Injection — What’s the point?

The Web, MVC and Routes on Rails

How to Handle Typos in Elasticsearch Using Fuzzy Query

Demystified: 5 Myths of DevOps Services

What my Software Resume Looks Like

A Linux Developer’s Flight Through Azure Skies

Introducing Beekeeper Time-To-Live (TTL)

A beekeeper tending to a beehive box

7 Steps I follow for developing a Device Driver

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
Scott Worden

Scott Worden

Scott is and engineer, attorney and tech enthusiast helping others reap the benefits of today’s technological innovations.

More from Medium

How to run your daily Stand-up… firstly Sit Down!

Retrospective meeting on a remote setting

The Agile “Mindset” or Why Agile Fails

Agile Quickies: Business and Developers work together daily