What would be an optmized way to transition from one Agile tool to another? Best practices? Experiences?

Hi Neel, 

A change management plan may be appropriate for such an initiative. Active and visible executive sponsorship to help teams understand why this new tool is good for the organization and for them individually will go a long way in the successful adoption. 

Some things to consider as this is not usually a trivial effort:

• What are the teams feelings towards the existing toolset? 
• What type of resistance do you expect to see when asking to make this type of change? 
• Include team members in the process and take their feedback into consideration
• Consider how you might measure success - % of usage, team member feedback, etc. 

If a team had such a dependency on "agile tools" that they needed a transition plan, what would that tell you about the state of agile practice in that team, and the action that ought to be taken?

Agile is a mindset. Agile has nothing to do with tools. Your organization may be equating business agility with performance reporting and tracking. The former is a cultural shift and a mindset, while the latter is a mirage and a project management method masquerading as Agile.

With reference to migrating from one reporting and tracking platform to another, the worst thing to do is a parallel migration. This is a common practice and results in failed and delayed adoption. You want to rip the band-aid. Rip and replace. Your OCM and OD practitioners would need to prepare the affected business units for this migration. Archive the old in SharePoint or some other repository and start new. 

Hi All,

Thanks for your comments, but I think my question was misunderstood. May be I didn't describe it properly.

@Tony - Thank you; your answer was still closer to the point, but these are one step before the actual point where we decide to migrate. Actually the teams and whole program would rather prefer to move to a new tool because the current tool cannot efficiently handle the the nitty gritties of daily work. Success would be measured on the basis of actually migrating as quickly as possible without causing too many disruptions and using too much effort and in the end saving costs on licenses after switching.

@Rest - It is not one team, there are multiple teams working in a Scaled framework. The type of framework at scale, doesn't matter, because as we all know, Agile is a mindset. It doesn't depend on the type of framework used. Individual teams work in Scrum & Kanban (just fyi). There is no dependency on tools nor does it have anything to do with performance reporting & tracking or other controlling project management methods. People are well aware of those cultural shifts.

To explain the situation a little better. Teams are using a tool, simply for visualizing their daily work on a Kanban board and everything related to it that they need. Nobody wants to use pieces of paper to do this. That would also be inconvenient at scale because we need visibility and transparency between teams, programs and any other areas with which teams may have dependencies. And as we all know, at scale, our objective is to reduce dependencies between teams as much as possible, but sometimes it is not completely possible. So to manage/view dependencies and simply to capture their daily work like refining stories, finalizing acceptance criteria, etc, we all use a common tool. Which is quite obvious for many organizations. However the current tool has a few challenges, license cost being one of them.

So it is a simple matter of moving onto a new tool to help with our daily work. However we can't just do that overnight where people come in the next day and suddenly they cannot find their stories or they see a tool which they have never used before. And hence we need a good transition strategy, so teams can smoothly move into using a new tool without disruptions, distractions and more effort than it is actually needed. 

Now from my experiences too, I have been a part of such transitions before and hence wanted to know, if anybody have had similar experiences and what their learnings were from it, any best practices they observed which helped cause least distractions, smoother transitions. One of the ways, it was done in the past was to announce a future date we would be using the new tool from, which may be a month or two away (depending on number of members at scale, framework, cadences, etc). Then planning for a short window to familiarize members with the new tool - short interactive training sessions. Then setting up the new tool a month before the switchover date and providing access to everybody. And then letting members from then on create any 'new' objects - features, stories, etc, only in the new tool. From the switchover date, teams start using the new tool only. Enough time is given before this so members usually are able to finish any existing items in the old tool, so after the switchover, they won't have the need to use the old tool. But we still keep the old tool accessible for may be a month in read only mode, in case anybody needs to refer to any of the old artifacts. After that, simply sunset the old tool and archive data. It needs to be ensured that the switchover date is well aligned with our cadences - sprint end, sprint start, etc, so it is not in the middle of a sprint.

So this was one of the ways. Is this what is being meant as parallel migration? If so I am curious why this is the worst thing? What other better alternatives have you used? 

And since we don't want to use the old tool any more, what best archival practices have you used. For large enterprises, it is extremely important to archive this old information in a data controlled way upto a few years for audit, etc. We all know from Agile perspective this is not really the most important thing as working software is the best way to show value delivered to user. But in practice, auditors and regulators will always be there. So did you export all the data from the old tool and import into the new tool (which again is not always straightforward and depends on the tools used), or did you just extract the old info and save it on some file server? This part is also important as it impacts the decision whether to move to a new tool. Too much effort and cost in this archival strategy might actually prevent the switch. And manual effort needs to be minimum.

Hence I was curious to know your experiences and suggestions regarding the above.

Regards

Neel

Hello All,

I'm actually in the same situation as Neel was last year. Except - it's the "first time" for me.

Does anyone would be so kind and share the best practicies with migration between tools?

@Neelav Das

What about your migration? Maybe you have more good practices to share with the community? :)

Kind regards,

Bartosz

And manual effort needs to be minimum

 

Then I hope the original tool is as out of the box as possible, because the out of the box features of Jira, Trello, and MS DevOps are "close enough" to simply use the automated project export/import functionality or use API's to push projects between the "legacy" and "target" platforms.