You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
In every Jira Align implementation, I’ve found myself sharing with the client an analogy that a Jira Align implementation is like a car. An implementation can seem like a car racing down the highway at 70 mph while installing a tire, adding 2 quarts of oil, and deciding what type of car it is. It’s incredibly apt because Jira Align implementations involve so much change on so many levels.
Part of the logic of this analogy is also part of the problem. The common Jira Align implementation is to gather client requirements and alter on the fly. This method works, if you have one of the few teams of highly qualified implementers but makes many assumptions.
A much better, repeatable, scalable solution for implementers and clients alike involves a different car analogy – buying a new car. All new cars start as a standard known good configuration - a base model. All available options are known to work. Once you take the car off the dealer lot you can customize the car, and potentially void the warranty. This is a better model but take care to avoid customizations that void the warranty.
The base model is a known good configuration of Jira Align and Jira that meets agile best practices for both systems. This configuration is a repeatable step-by-step process. This is also the purest agile configuration. Once this base model is in place the implementer can then show the client the impact of every modification to the base model. No more theoreticals – we’re working with a live system and can demonstrate why some customizations aren’t recommended.
The options are all the known good changes/additions to the base model (ex: product functionality) that work without any negative impact to either system or the critical bidirectional syncing of data. There are quite a few options/variations available that work without breaking the integration and data rollup integrity. By starting from the base model and exploring the options that make sense, clients can see the impact of those options in a more concrete manner vs too much time hypothesizing what might happen.
As for the customizations, the equivalent of taking your brand-new car to a shop for alterations that might damage stuff, many Jira Align clients go down the customization path before ever having a working configuration to compare it to. So, when things aren’t working due to bad configuration decisions the blame is put on Jira Align. Having a known good config in place with options before starting the customizations clearly shows the impacts, positive or negative, of the customizations.
If you follow the base-> options-> select customizations path laid out above, you will have a less stressful, faster, and more successful implementation. The known good options are known by only a few and my goal is to spread that knowledge so we can scale and serve more clients. Every company deserves a successful Jira Align implementation.