By Josh Roberts | September 1, 2014 | 3 Comment
We are selecting an Application Life-Cycle Management (ALM) tool and wrapped up the high-level demos last month. As we move to a more detailed product evaluation, it’s a good idea to remember the capabilities we are seeking from our ALM tool. Generally speaking, it’s those capabilities that help us manage the following areas of the Software Development Life-Cycle (SDLC):
I like the visualization that HP offers below.
In an Agile/Lean delivery organization, we are also seeking an ALM tool that supports team collaboration and automation.
“The success of modern Application Development projects relies heavily on process automation and team collaboration” – Gartner
Using our three words, let’s go a little deeper into the required tool capabilities.
Most importantly, we are seeking an ALM tool that will allow us to continue to visualize our work. Our physical Portfolio Kanban boards will be replaced by virtual boards. This requires a card based, configurable workflow such that we can manage the flow of work through our delivery processes. This is a key component in managing our portfolio demand and capacity.
As we decompose work at the portfolio level, we will define system features along with the user requirements (Stories). Like the Portfolio Kanban boards, Agile teams will be using a Kanban system to manage the delivery of features, requirements, and team tasks. This will require our ALM tool to support team level practices such as Scrum.
While we will be transparent in “what” we are delivering, we also must be transparent in “how” we are delivering. The ALM tool must provide metrics and reporting that can be used by both the teams and management to gauge overall progress/health of work in the portfolio. This will include, but not be limited to the following capabilities:
“Collaboration facilities associated with ADLM include wikis, threaded discussions, documents, shared workspaces, and other synchronous and nonsynchronous forms that capture the discoveries, discussions and decision processes of teams at work.” – Gartner
The ALM tool must help us create strong lines of communication with customers to build the right product while enhancing team collaboration to build the product right. When we talk about collaboration, the focus is often on the development teams and business partners, but this only covers the front-end of our delivery stream. See the blue portion of the infinite loop below.
As promoted by the DevOps movement, we must extend this definition to include our operational (Ops) teams to include the release, deployment, operations and monitoring activities.
Three Principles of DevOps
Agile/Lean practices are focused on frequently delivering value to the customer. This is accomplished through collaboration and transparency, but feature-driven development plays a big part of it. And, if we are delivering features more frequently, we must automate our delivery processes through an ALM tool. This automation largely comes in the form of the following ALM integrations.
And, while these are all very “Development” focused, we cannot forget the need to integrate with our “Operational” process. Yes, we are talking about DevOps again.
“The emergence of DevOps as a primary driver will further push the connection between the traditional ALM and IT Service Management (ITSM)” – Gartner
While Agile ALM tools are built around practices such as Scrum and Kanban, ITSM tools follow ITIL practices. Generally speaking, ITIL is focused on the operational services of an IT department. Bottom line, both ITIL and Agile/Lean practices are aimed at delivering value to the business.
Let the next round of ALM tool evaluations begin!