All Posts

Veracity's very own Damian Dingley wrapped up 2020 with Part One of his two-part series on how to select the right tools for your Agile organization. We've made his slide deck available here as well as a full transcript here.

He reserved the last bit of the webinar for questions and we had some really great questions! We're recapping those here for you in case you missed it. 

He's kicking off 2021 with Part Two on January 14th and we'd love to see you there.

Over the course of this two-part series Damian will cover the following categories of tools to support your Agile culture:

  1. Go-To's: Everyday Essentials & Must-Haves
  2. Planning: High Level Visioning, Road-mapping, & Oversight
  3. Distributed Teams: Communication & Virtual Office Space
  4. Knowledge Share: Team & Organizational Well-being
  5. Value: Measuring the Value Delivered by an Agile Platform & Culture

In part one, Damian covered those first two categories: Go-To's & Planning.

  1. Go-To's: Everyday Essentials & Must-HavesCharacteristics of a go-to backlog management tool: Hierarchical breakdowns Initiatives Releases Features User stories Tasks Good visualization Ease of use Boards Cards Trends Metrics Metrics Velocity Burndown Release progress Bug management Integrations Source control CI/CD chain Planning Big picture Enterprise & Scale Multiple products Multiple teams
  2. Planning: High Level Visioning, Road-mapping, & OversightCharacteristics of a go-to product management tool: Hierarchical breakdowns Portfolios Releases Features User stories Tools What if? Dependencies Timelines Metrics Progress Risk management Integrations Backlog management Development Visualization Big picture Dashboards Progress metrics Enterprise & Scale Multiple products Multiple teams

Q&A Recap

Q: What is an Agile tool?

A: To sum it up:  it's a function or capability that allows us, in the Agile space, whether we're acting as Agile coaches, scrum masters, or just part of a team, part of a development team, or in the product part of the organization, to move the business value from an idea, through to development, through to something that's actually running, functional, and is delivering value. 

 

Q: How would you go about switching from Jira to Rally based on your recommendation? What's the process for that?

A: It depends on how much backlog is in Jira. It's possible, but it's not easy. It's like, when people ask me, "We want to do Agile. Is it a, get this done in a couple of days, train these people up, and we're all good situation? I said, "Yeah, you can do that, but it's not going to be effective. This is going to be tough, it's going to be hard." Let's say it as it is.

Adopting Agile is not straightforward, if you really want to benefit from all the things that it can bring to you. The same with moving tools, it's not easy, but it can be done. There are ways of exporting the data, there's tools you can export to Excel, and then you can import into your other tool of choice. You've got to manage it carefully. It's something that you're not going to be doing overnight. You've got to plan for it and work carefully through that process.

But, if you're really struggling with a tool or that tool's not working out for you, do not continue to struggle with it. Okay? Because, it's just burning hours on everyone's time and frustrating all the scrum masters and the product owners. So, if there is a drive to say, "can we look at something different?" It's definitely worth going through that painful bit when you transfer.

 

Q: We spend a great deal of time planning in Aha!, only to change it all weeks later. What's your recommendation there?

A: Scream.

Just kidding. Well, we embrace change, right? What can I say?

Agile: expect change to happen.

I get it. This is what Agile tried to set out from at the beginning: don't spend hours and hours and days and days planning. We've got to trim this down. We've got to slim it down so we're delivering value. Now admittedly, we want to be delivering the right thing. We don't want to be working in a vacuum. But, there is a cut-off point where you say, you know what, we've worked this through countless times, let's just do it.

You could really work your plans through almost too long and get too obsessed with the plan itself. The plan's going to change, it was inevitable. So, my advice here was just find a reasonable cutoff point where you say we've got enough here, the best way to move forward now is, to go and learn more about it, reduce those and go and exercise on it. That's why I would deploy all the Lean UX protocols, practices. So, try not to procrastinate too much in your planning exercises. Just remember what Agile's all about? Again, don't let the tool take over. 

 

Q: One of my clients just moved from one tool to another just to save money. Is there any recommendation on sticking with one tool?

A: This is a really good question and it comes up a lot. 

Rally is not the cheapest tool out there for backlog management and planning, and Jira tends to be cheaper than that. So, you'll see a lot of migration. 9 times out of 10, if people are migrating, they're moving to Jira mostly because of cost. But then, you've got to think about what are you saving? Sure, you're saving that monthly subscription fee. In my due diligence exercises of looking at the reasons why someone is moving, you've got to look at the usability of the tool.

So, going back to the characteristics that I look for in a tool, by moving to this other tool, what am I going to lose out on? If I'm not losing out on anything, then it's worth it, and I save some money, if I'm going to achieve the tool. But however, if I introduce new logistical challenges, like ease of use, or button clicks... and that sounds so trivial. But, when you're doing hundreds of user stories, creating 1000s of tasks, and you've got all your scrum masters and your product owners trying to do this, you multiply the amount of time they're working, getting frustrated, outraged, and running off screaming... I've seen it!  I'm not kidding.

It may not look it on the books, but if you look at the amount of time you spend doing what you were doing before, but it takes 5 steps instead of 2 steps, you multiply the amount of time that takes. So, it does require some due diligence. Hopefully, using that set of characteristics I identified earlier for those tools, might help make that decision when you're assessing the alternatives.

 

Q: We tried integrating Aha! with Jira, but kept running into problems. Is there a better way?

A: Is there a better way? Drop one of the tools.

There's a couple of ways of answering this.

First of all, know exactly what you need to do on that integration point, okay? I can speak from experience that when we did this the first time, we weren't quite sure what we needed to do. So, there was some inexperience going in, and some guesswork. It was okay when one or two teams were in the mix trying to work with the Aha! tool and the Jira tool, but as we scaled it out, problems started multiplying.

Then, because we hadn't got our integration figured out properly at the time, we were so consumed by other things. But, we kept scaling and scaling with this problem still there. It's like technical debt, right? We hadn't addressed that, so we got into a problem there. Then, we had to try and stop, hold everything, while we fixed those integration points, and then get better at it. 

Allocate time to work through that and understand it well. Get some experience and pull in some expertise of people that have done those integrations before. Get that experience, get that training to do it, because it's going to pay off down the road when you use that tool more forcefully, at scale later on. It's always going to be a challenge at some level.

It’s not just the financial cost, it’s the emotional cost, too. We're dealing with human beings! We've got our code and everything, but there's humans in the mix here, so we have to think about that.

 

And that wraps Part One! You're all caught up for Part Two on January 14th!


Part Two Preview

Damian is thrilled about Part Two. Part One is your go-to, everyday tools. Part Two, we're going to tackle some slightly more interesting kinds of sides of what we do under the Agile platform. Distributed teams is obviously huge, especially now.

What kind of tools do we have out there to improve communication between remote teams, virtual office spaces?

If you're doing an Agile inception that requires real hands-on interactions how do you reproduce that feeling of all being in a room together virtually? Will it keep people engaged? It's difficult!

How do we engage people again as we're living through the pandemic and working remotely? How do we replicate that feeling of being in the same room? 

In Part Two, Damian will answer these questions as well as focus on knowledge sharing and measuring value.

REGISTER FOR PART TWO


Get your copy of The Project to Product Transformation

 


 

Related Posts

[Webinar Recap] Tooling Agile: Part One

Veracity's very own Damian Dingley wrapped up 2020 with Part One of his two-part series on how to select the right tools for your Agile organization. We've made his slide deck available as well as a full transcript.

Fear and Loathing in Story Pointing

In my years as an Agile Coach and Scrum Master, there’s one topic that generates a look of bewilderment on the faces of everyone: effort estimation on the ubiquitous user story. Let’s take a closer look at the confusion and break down the issues at hand. It comes down to the way the process is explained together with the purpose of user story pointing. In the end, story pointing is all about providing predictability. Software teams are notoriously unpredictable....

The "Why" Behind Agile Inceptions

by Scott Heffield, Veracity VP of Innovation and Solution Delivery