“Application Lifecycle Management (ALM) is a continuous process of managing the life of an application through governance, development and maintenance. ALM is the marriage of business management to software engineering made possible by tools that facilitate and integrate requirements management, architecture, coding, testing, tracking, and release management”.
From Wikipedia
Tools will be more important for the future as we go towards a distributed working environment as a result of the pandemic, outsourcing strategies and specialization rather than generalization. I think that specialization from strategy to operations require specialized tools for each need and few tools are suitable for all disciplines. In the future I think we will have apps for each need and integrations in between.
Often these choice of tools discussion ends up in religion war between the people skilled in different tools. This is my thinking of how to choose the correct tools and what to consider in a procurement.
At this old Swedish company where I worked for three years, we happily worked with requirements in excel and it worked fine until we were acquired by a multinational company. I was a manager of the PMO and, as I think, did a great job challenging stakeholders to do MVPs rather than big projects. These MVPs lived in an excel file for each initiative. But then we were told to buy a ALM tool for all teams in the company to collaborate within, as we went back to big projects. The big providers of ALM swarmed us for a month or two but at the end we decided to go with the Rally software suit.
I went to Rally training in England and the Swedish teams that had been working with MS tools had to reskill as well with my support, but after a period the criticism from the tool priests had faded out. It was just another tool. In retrospect the choice of Rally was driven by politics rather that an objective prestudy. This was 10 years ago and now adays they have another tool.
If you look at the same statistics for ten years ago, Excel had 52% (now 32%) and Jira only 29% (now 81%) so from a egositic perspective, Jira is the choice as it has become a basic skill. So here some advice from several similar discussions at other companies on what to consider when choosing the right tool.
Supporting the Way of Working, not vice versa.
First of all make sure you have a process/WOW you want to follow and then put constraints on the tool so it can be configured according to this WOW. Example: If you work in a flow based WOW make sure a Kanban board is a feature provided.
Start small
If you are a small company or an autonomous team the choice is simple. Microsoft Excel or Google Sheets will be sufficient with some basic Excel skills. If you are a big company, create your first backlog in Excel/Sheets and then export it to the choosen tool when your Way of Working is good enough.
Traceability among the lifecycle artifacts (StratBizDevOps).
Make sure that the tool has ability (APIs etc) to connect with other tools as i think there is no single tool for all purposes. Example: When defects come in via one tool it should be an ability to trace it back to the requirements in another tool via links, not detective work. Also the other way around, the strategy objectives (OKRs) we have to relate to should be traceable down to the workitems (Stories) so we do the right thing.
Support for Workflow Automation.
Parts of the work we do can be automated. Example: If a workitem moves in the process/flow it can trigger alerts or other actions automatically to avoid states ”between the table”.
Visualization (Kanban board).
Kanban board is the most popular visualization tool that gives us transparency. This is a must have feature.
Reports and Actionable Metrics. (Flow)
The tool must support governance to avoid manual status reports and their meetings. Example: Today we provide live status for the ongoing effort, delivery, velocity, flow etc so we can use live data to make decisions upon rather than excelfiles with RAG status that no one trusts. Caution though: Bad data in – bad reports out. It comes with a lot of discipline.
Collaboration/integration with other teams and partners
Here comes the API feature again. If not stated in the SLA what tools to use, we need to make sure our tool connects with our partners. Otherwise you need syncmeetings and change forums to communicate.
An open community for QA and general support
If we have any questions of the usage or configuration of the tool, some companys hire full time admin for this. This can be avoided by great training and a community on the web for questions.
Plugins (if needed)
Some tools provide a lot of extra features as plugins. Kanban boards perhaps in not out-of-the-box so beware of this possibility that can be expensive in the long run if it is not included.
Compability with integration platforms
IFTTT and Zapier are common open platforms for integration with support for many products. If they are compatible with our tool we can save time for integration. Nice to have.
Legacy (current skillset/tools/wow/software policy)
Take care of your legacy when it comes to current tools and skills. If you change this will be lost. At the company mentioned above it took a year to have the tool comfortable for all people. Also most companies have a policy to choose from a specific vendor. This constraints us and can be problematic as the ALM tool is not this vendors core business and lacks from the features we need.
Templates for Scrum, Kanban and Waterfall.
A quick an easy start configuration by adding your choice of process should be available via templates or similar so you can get started right away.
Alerts and notifications integrated with email and/or chat.
A lot of stuff happens without anyone notice in your tool. It should be configurable that we get email notifications when something interesting for me happens: Example: If a workitem changes a status i want to know first.
Legal data storage (MS Teams store in US and probably Zoom as well?)
In Sweden a recent directive came from our goverement that not use cloud storage of data outside EU for the authorities. This disqualified MS Teams as a collaboration tool and now it is back to Skype again. Check the legal requirements.
Expert support in-house.
Make sure at least three people have more skills in the tool and can do configuration and support. One can be consultant for a start but then we need this skills in-house. Create a community for the tool.
Non-functional stuff
Don forget the performance, availability, usability etc. There are several companies comparing these tools today. Just Google.
Summary
100 years ago, there were doctors with the same tools for whatever symptom. Ears, heart, legs was fixed with a stethoscope and a hammer. Same, same. Today we have over 100 variants of doctors specialized in their own area with their specific tools and processes. To fix a brain require other tools than an achilles tendon. The same goes for software delivery. We today have business analysts, managers, developers, designers, testers and users that have different needs, and my reconnaissance is we go toward specialization rather than generalization and every team need to decide what tools fit their purpose, if we want autonomy. Specialized tools will be needed in software delivery for the future rather that one-size-fits-all. So take care of your choice of ALM.
Is “Individuals and interactions over processes and tools” outdated? This will be another blog post someday.
/Ove Holmberg