Simplifying Complexity: When it’s time to hang up your legacy system for a platform
Let me start by saying I have deep fears that legacy technologies will force companies to stagnate and die. We all know software is a strategic asset and a critical part of keeping you competitive and on the cutting edge of the market. So, here’s my tangible tale of terror about how old legacy software vendors and antiquated processes, restricted our ability to move fast as an organization.
The Pains:
It was 2015, we were a product organization in rapid growth mode. I was a Product Manager, Program Manager, Customer Support Manager and Product Marketer for a dependency management product we developed as a point solution for Program Managers. At the time, we were struggling with capacity, bandwidth and quality. As a result this led to multiple breakdowns in the process and tools and information overload was a our day-to-day. Teams were struggling to understand the vision in order to make sense of the big picture, understanding the value of the work they were doing was a challenge to developers and to complicate and compound matters further, we all were distributed making collaboration a challenge.
We had 4 cross-functional collaborative teams: Development, Product Management, Customer Support and Product Marketing. Each of our functional areas each used different software vendors to manage our work and all of our workflows had no consistency, didn’t align to the other groups making collaboration a huge barrier. To top it all off, each of us captured our requirements in different toolsets and tried to reconcile during calls. Overall, I found it challenging to reconcile all the different systems, work items, communication touch points so that we could understand the holistic problem in order to make sense of the data. Trying to design a solution to this mess just caused more chaos and friction across the teams and arguments were commonplace in our ceremonies.
- Development used a home grown system
- Customer Support used Zendesk
- Product Marketing used Sharepoint
- Product Management used Excel and PowerPoint
In retrospect, if I only had a crystal ball I could foresee the impending doom and could try to make the right adjustments, just as Agile prescribed. Well, hindsight is 20/20! Looking back on the early indicators, I should’ve saw these pitfalls.
Pitfalls:
Pitfall #1: Software Context Spread Out
Our context was spread thin and everything was being held together by a Frankenstein hacking of systems. We never understood the big picture and could never come close to the end state. After spending over $1M in software to help solve these problems, I commonly got my truth through exports from 4 systems and leveraged pivot tables, so sadly, it was back to Excel for me.
Pitfall #2: Workflow Proliferation & Siloes
Every team was stuck in their own silo. Product Management, Customer Support, Development and Product Marketing had their own workflows, fields and conversations and nothing ever crossed the boundary lines of the respective functional group. This created a wild west mentality and anything we worked on collaboratively could never be visualized in an effective way. We would meet as a team and could never get anything accomplished considering we were siloed.
Pitfall #3: Lack of Ceremonies, Governance and Structure above the team
Based on the fact that we were running so fast, we never stopped to think to simplify our complexity and all get coordinated on one platform, with one defined way of doing things so that we could better deal with the handoffs and focus on solving the holistic bigger use cases and problems. As a result of our system, we tended to focus on a piece meal approaches to implementing new features, customer bugs and enhancement requests.
The Solution:
And The Winner Is… Atlassian:
Our CTO was eventually pushed to start over and we decided to go all in on Atlassian as our enterprise software application for our ALM workflow and work item solution. After a credit card swipe it seemed so fast that we were off and sprinting in a united effort. Looking back on our switch, I noticed a few key standout reasons that made our decision easy to adopt and sticky enough to support our growth as we scaled.
Platform Approach:
We found that development embraced this tool first as their centerpiece and soon after, we saw the desire from Customer Support, Product Management and eventually Product Marketing found that they could also make the move to take advantage of one seamless integrated environment that crossed geographic boundaries, simplified information and kept us always connected to our true north.
Ease of Integration:
Once each functional group validated functionality and checked off on all the requirements, each of the groups committed to a timeline to migrate and consolidate all our data from our old legacy Frankenstein system to the new gold master system. This not only reduced overall total cost of ownership of our software tooling budget but it also allowed us to really consolidate so much redundancy across teams that it helped us go faster as a company. We
We were delighted with Atlassian’s open API approach and our technical team found that they could integrate all their business critical applications by tapping into the API for easy linkages. Our infosec team was onboard and that made everyone happy. Application links inside of Atlassian was my highlight and it allowed us to easily stay in our Atlassian product of choice while still breaking down silos to reduce the interdepartmental siloes. Keeping groups close to the work and close to the decisions was quick and easy with the @mention. I honestly can’t see myself ever going back to the old ways of the past.
The Example:
Consolidation + Migration = Happy Org
We are now deep into our Atlassian experience, the legwork to dump our legacy systems was a good one. Here is how simple our enterprise workflow across functional groups now flows.
- Confluence – The Whole Org
- JIRA – Product + Development + Product Marketing
- JIRA Service Desk – Custom Support + Product
- Confluence + JIRA – Product Marketing
- Bitbucket + Bamboo – Development
Atlassian Highlights:
We all have adopted our own collaborative spaces in Confluence now. The Product team relies on Confluence as their central hub of truth. Business cases are developed and flushed out here. All requirements also start here and break off from the big idea and slowly evolve into the work item and eventually into a workflow as it transitions and breaks down into a dev working on a ticket. As we start to groom the backlog, its so easy to keep everyone abreast on progress and even loop in anyone we need to help flush out the gaps prior to our quarterly release planning meeting. Historically, all this prep and grooming would take months and now seems automated and tidy. Speed was the value we received here. My favorite feature is to insert an issue filter from JIRA to provide context in a conversation on a page. This has revolutionized the way we collaborate.
As the development team breaks features into stories in JIRA, we are still able to maintain all the linkages to Confluence as we break things down and allocate to teams so the traceability is built in. Comments on the issues give us the ability to stay close to what is needed without all the unnecessary meetings. In addition, as each sprint kicks off, I can still stay closely connected to the WIP.
In JIRA Service Desk, we now are managing all our bugs, enhancement requests and questions from one portal and the Product and Customer Support team finds it easier to holistically address larger functional problems vs. getting trapped into feature by feature delivery.
I’m most impressed by the Development team as they were able to queue a releases faster and even find ways to ship product faster by integrating JIRA with their continuous integration server in Bitbucket to leverage application links once again here. It is so geeky to see a branch cut from a story and see the progress and lifecycle of development as it goes from branch created to code check in, to finally code deploy on a test environment in a matter of hours.
Following this path of work was so insightful. We were able to achieve the tremendous value of Speed, Traceability, Better Collaboration, Real-time Auditing, Monitoring and more with Atlassian at the center of it all. It’s easy to visualize and enhances our ability to go fast in the right direction. Looking back on all these challenges that caused me a lot of heartburn, stress and eventually led me to fail on this product, I now understand what we needed. This experience taught me some valuable process and technology lessons that will forever be ingrained in my DNA.
Lessons Learned:
Lesson #1: Leverage an Integrated Enterprise Platform
Thinking back on where the system went wrong, we needed an integrated platform that simplified complexity across the teams so that we could all reference the same work items in the same environment so that we could talk apples to apples. Only then would we be able to understand the big picture and take action on the most relevant and important things. In retrospect, there was too much noise in the way and all the disparate work, conversations and context was just always out of reach.
Lesson #2: Establish Constraints on your Technology Systems.
Thinking back on where the system fell down, I couldn’t help but remember all the different process workflows, different irrelevant fields and such that just slowly created a garbage dump system of record. Over a period of 2 years, the garbage had accumulated to a point of no return and functional groups couldn’t tell what was good from bad anymore. We started drowning in work items and tickets and couldn’t help but resort back to Excel. In hindsight, we should have decided collectively what work items we should use collectively, what one workflow we could all rally behind and who actually needed access. This would have allowed us to standardize around one approach, limited the noise into the system and ultimately gave us a way to normalize one cross functional enterprise story.
Lesson #3: Establish Good Governance & Best Practices
In Scrum, there is great structure for teams, you have ceremonies, artifacts, metrics and more that help provide a roadmap on how-to go about navigating your teams daily, weekly and monthly. I realized once you start scaling and move above team level, there was a gap related to having any good ceremonies, artifacts or anything substantive that you can rely on in order to help with cross-team planning, prioritization and implementation. We also had zero guidance on cadence and commonly hit delay after delay.
