Our first year journey after Atlassian Go-Live
We just finished the year with an internal two-days Company Atlassian Summit, the second one since our journey started, and for many of us, it was a time of satisfaction and reflection. Seeing those colleagues, that a year ago where learning about Confluence and Jira, providing high quality presentations in how to use the tools was one of the best moments of the year for us.
Our Company Atlassian Summit and the Voice of the User wall
During the previous year we completed the onboarding of our development teams, migrating from RallyDev and Support Works into Confluence, Jira Software and Jira Service Desk. We provided 8 waves of two-days training to more than 400 new users, refreshing the use of Scrum, standardizing processes and introducing Kanban. As we moved forward with the rollout we were identifying and onboarding super users and champions. As a matter of fact, we could say it was a good ride, not smooth as we thought, but good enough to get to our destination.
There is a “before, during and after” and, in this article, I will share the after go-live experience, a year of lessons learned, corrective actions and pending items.
Going Live
Our core focus was to address the needs of our software development teams synching the go-live experience with the training wave. The strong IT team supporting the effort had the migration of the trainee teams’ items completed the night of the first day of training and then on the second day the team members were reviewing the content into the new platform. Therefore, those that did a good job with backlog grooming had a great experience, on the other hand if the backlog was not well groomed, they faced some challenges. The other aspect of the coordination was to take in consideration the sprint starting and ending dates, so we don’t interrupt their normal Scrum pace. The second day of training was full hands on and a good opportunity to get familiar with the tools. In fact and considering that we asked them to complete some online training prior to classroom session, we noticed the difference between some of the trainees that followed the advice and those that don’t.
The day after
As we all know in this community, the number of "out of the box" resources provided by Confluence and Jira Software are quite comprehensive and challenging to adopt all at once, so we identified the minimum level of knowledge that our team should have in order to be successful using the tools, we instructed in how to master the basics and the education path to follow. We closed our training waves with an internal Summit and invited some of our champions to do presentations and demonstrate the proper use of the platform. At that early stage we already had good stories to tell. However, we knew it was the beginning of a great journey where we will grow together.
Overcoming Challenges
Soon after going live the users were engaged on the adoption of the new platform and provided continuous feedback to the Atlassian support team. However, since the beginning we had an Atlassian Steering Committee with members of all the affected areas and together we prioritized and processed their business needs and applied corrective actions when necessary. Our configuration was enterprise and we created a unique development workflow shared by all teams (Scrum and Kanban) minimizing the number of customized workflows and facilitating the cross-team members interaction. That approach was one of many challenges that we had to face as a team, but little by little, we were able to address our users needs. Consequently, and considering the enterprise impact, the resolution time was affected, on the other hand, after implementation and go live, the support and management was still better than providing unique isolated solutions.
The other challenge was to help the team understanding the difference between Confluence and Jira and how they can be better together. Our teams were used to add all the supporting documentation attached and/or as part of the issue. So, the first step for us was to help them with the differentiation between both products and that JIRA should be the tracking engine while Confluence should be the supporting documentation, where all the requirements, specifications and design should reside. Besides, one of the decisions made was to keep SharePoint as documentation repository and to foster the use of Confluence on the generation of new content, we limited the type of files that the team could attach to Confluence or Jira. It was not a very well accepted decision, but it was necessary to nurture the use of the new platform, a new paradigm that will have to go along with old habits and practices. It is fair to say that nowadays is still a point of friction and conflict, however, it really helped with the transition from word processors to a wiki approach and the driver of that conversion was the tied integration existing between Jira and Confluence.
Trying to maximize the Return on Investment was also a challenge as we need to pace the learning curve, for some it looks like filling a water bottle with a firehose, it was too much to add to their daily activities. To overcome this problem we needed to slowdown our pace in some of the elements we had in our roadmap with a high risk of affecting the overall deployment. Fortunately for us, some teams were embracing the change and moving forward quickly while others were trapped in old practices. One of the key actions to even the field was to motivate immediate supervision to provide coaching and mentoring, in other words, asking the team leads to lead by example, using the tools in the right way and remembering that it is not about individual success, it is about team empowerment. It is a continuous effort and it is very important that managers are involved as well, they need to consume the information generated, they need to use the tools and be on boarded with the teams.
I am sure you are familiar with the common term “Information Silos” and the department taxonomy that we had in our SharePoint instance promoted that very well, however, the adoption of the new collaboration tools was the perfect timing for a fresh start. The new approach was to promote the Product Centric taxonomy, like a bunch of grapes, were each grape is a product that contains all the related information about that product. Starting with the idea, requirements, design to marketing materials, documentation, etc. Then as we have teams that works in multiple products, we added the team spaces, with the goal of maintaining there the team interaction activities. The approach works very well with one to many relationship (one team – multiple products) but it could be confusing for the one to one relationship (one team – one product). Eventually, as we onboard business teams, instead of creating department spaces we provided Team spaces, with the clear indication and rule that those spaces are for non-product specific information.
Continuous education is still a challenge for us and monitoring the use of the platform help us identifying the weak spots or deviation from our baseline guidelines provided. Also, it really affects in how we implement new corrective measures or new functionalities. To help with this issue we launched micro learning units addressing specific training needs, we constantly provide webinars, promoted Atlassian Company and local User Groups as well as lunch and learn sessions. The end of the year company internal Atlassian Summit was the main outcome of those efforts.
Lessons Learned
Assumptions: it is very common to document assumptions during the initial phases of any project, but the most important element that goes along is to identify the associated risk to the schedule or project in general if those assumptions are not met. In our case we decided that we will provide online application training as recommended (but not required) and then classroom training focused in the use of the tools based on their team interaction. We quickly realized during the first training waves that no all the team members were at the same level, and for such the simulation we had prepared were seriously affected. It was too late to apply corrective actions but soon enough to alert remaining teams. Unfortunately, we kept the “recommended” until the end of the training waves, when we should had changed that to “required” as soon as we finish the first wave. Basic application training is one of the items that we try to tackle with microlearning continuously released to the team as part of our Knowledge Burst efforts.
Learning Curve: the typical “knowledge” firehose, the challenge to manage the timing of new features and setting the training baseline. Out of the box, the Atlassian products, have a wide set of features and resources that it could be a barrier for adoption. We identified that no all the trainees have the same desire for learning new features and they felt comfortable with just the basics. On the other hand, we have those that were looking for straightening the steps needed to go from A to B, by optimizing and maximizing the use of the provided tools. Now, as member of the Atlassian Steering Committee, we faced the challenge in deciding when a new feature should be launched to address business needs. One of the Lessons Learned is that we need to think twice and pace the needs to find the best timing for a new capability that could affect the enterprise platform. Perfect example was when we try to promote and implement Portfolio for Jira, we provided professional training too early considering the high level of dependency of this add-on from the teams working in our products. We should had waited until we have a minimum level of adoption and common practices. It was a fortunate lesson learned early in the process that helped us to avoid the same scenario when considering complex add-ons as we are right now with Business Intelligence tool selection. Instead of rushing the adoption of any add-on we are trying to identify what needs to be in place before we even think about installing any new feature.
Marketplace: navigating the Atlassian Marketplace could be addictive and if you multiply that for 500+ users it could be dangerous and distractive. Early in the process, we decided that our users should focus first on the business needs, provide a research about a potential solution and work with our internal Atlassian experts evaluating alternatives. In the case of finding an add-on that provides the solution we test it first on the Dev environment engaging key stakeholders that presented the business case.
However, we found two sides of this scenario: the first one is that after providing the solution some of the features implemented are not being used by those that initially requested and then, on the other hand, some of those improvements were beneficial for other users increasing the Return on Investment. The challenge now is to continue our monitoring and preparing an annual evaluation prior to renewal season.
Taxonomy: When we migrated from our previous department-oriented taxonomy to a product centric one, we designed some spaces and project templates with our overall vision in mind. After a year of using Confluence and Jira we realized that we will need to evaluate those templates generated in order to see if they are just empty scaffolding or actual structure in use. The initial approach for Confluence was to provide, at least, the first two to three layers on the page tree to facilitate the navigation from space to space, but we gave the liberty to the teams to adapt the space to their needs. The organic growth in some cases was within those boundaries but we also perceive that part of the whole proposed structure was ignored and the space grew on its own.
Our Own Company end of the year Summit
The year has passed, and we were ready for our Company Summit 2.0. We had good memories from our first one, just closing the initial training waves at that time and kicking off our Atlassian journey. After a year and with a huge list of items to cover we sent a survey to our team asking what type of content they would like to see in our annual meeting. We obtained good responses from our team that allowed us to shape the meeting.
We found support from our Management team and as we invited our team members to submit presentations and get votes to be among the seven selected to present, we were preparing a great surprise for them. The best two presentations (voted by attendees) will go to the Atlassian Summit, April 2019, Las Vegas. It was really exciting to see our team members sharing their experiences and best practices, there were "pro" 100% and we got the two participants that will be at the Summit. (and they also have some fun during the presentations...)
Deanna explaining our ARG (Atlassian Research Groups) and the Voice of the User effort with the boxes to collect participants votes. One unique color per presenter.
Our team members having a good time during the Summit presentation
Beyond those details, the main element there was the comradery and the desire to share their shortcuts and valuable piece of advices to the point that one of our members prepared a video introduction for the team or got dressed to support the presenter sharing special swags. Topics covered during standards presentations were from using Confluence to run meetings to master Jira Query Language and we found the time to interweave some longer sessions for specific training.
I personally take that experience as a huge success for those attending, but considering that not all the team members were able to attend, we launched a series of webinars to repeat the content for remote attendees. And to close with a cherry on top, we ended the first day of the summit with a local Atlassian User Group social event, in a bowling place called Revolution at West Palm Beach, FL downtown… but that is another story that I will share with you soon.
Palm Beach, Fl - Atlassian User Group - End of the year event
Palm Beach, Fl - Atlassian User Group Leaders
Yep, a year has passed, and we are ready for the next round, our team is embracing the tools as they share knowledge with team mates and look for good ideas in how to maximize the use of each little feature released. I am glad that I had the time to share with them my knowledge and passion, and thanks to you for reading this and sharing your experiences as well. I will keep you posted.
Was this helpful?
Thanks!
Fabian A. Lopez (Community Leader - Argentina, Florida, California)
About this author
Project Manager Professional/Scrum Master/CTSM/ACP-CA
Document Storage Systems (DSS, Inc.)
Lake Elsinore, California
1 accepted answer
12 comments