If you are looking to implement a scaled agile solution, but are nervous about doing a full-scale tool replacement at the team level, you’re not alone. There are both hard and soft cost involved in making the transition; and forcing instant, mid-project change at the team level could put your delivery schedule at risk. Expecting change to happen overnight is not only unrealistic, but potentially damaging to your teams.
Whether every developer in your organization is already standardized on JIRA, or you have three different team tools in place as a result of past decisions or acquisitions, many of your individual teams are already sprinting away in a groove that enables them to execute against their deliverables at the team level.
Some teams may love the tool they’re using and others may hate it. Most likely they are highly familiar with how to use their tool to get the work done. From the developer or dev manager perspective, the switching costs involved in transitioning from one tool to the next can be perceived as unnecessary. This is especially true if the team is nearing the end of a critical project.
But, how are you to launch a scaled agile initiative without some sort of change taking place?
Don’t Force Change: Embrace A Federated Approach
Companies that excel at full-fledged agile adoption are attracted to solutions that don’t force that change. They seek access to the benefits of program, portfolio, and enterprise level functionality without demanding teams switch tools.
We witnessed this first hand during a recent roll-out at a global Fortune 1000 company. Upon implementing AgileCraft, roughly 60% of the team switched tools immediately with another 20% planning to switch over the next few months as their in-flight projects wrapped up. The remaining 20% may switch tools six months from now - or they might not. While the company encouraged adoption of the new tool, it was not mandatory. This reduced much of the resistance to change at the team level and allowed developers to continue to focus on key deliverables.
A federated approach can present a win-win opportunity for executives and developers alike, as long as the right technology is in place to enable unified data at the program, portfolio, and enterprise levels. Use a scaled agile application on top to define your strategy, develop your programs, and write your features. Then, continually sync everything to the team tool (or tools) of your choosing for execution. As work is tasked and completed, all of the team’s data can be synced back up to the program, portfolio, and enterprise levels for unified reporting, tracking, and analysis.
How do you plan to launch your scaled agile initiative without risking your current delivery schedule? Share your thoughts in the comments section below.