Joshua L. Roberts

Agile / Lean Enterprise Transformation Coach

Week Thirteen – It’s Tool Time!

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):

  • Project Definition and Demand Management
  • Requirements Definition and Management
  • Quality Management
  • Build Management
  • Software Release Management

I like the visualization that HP offers below.

ALM integration

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.

Transparency

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.

kanban flow

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.

scrum-framework-diagram1

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:

  • Executive Reporting
  • Project/Release Planning
  • Iteration/Sprint Reporting
  • Team & Member Reporting
  • Issues/Defects Reporting
  • Test Coverage
  • Build Information
  • Other Information Radiators

Collaboration

“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.

DevOps-infinity-loop2

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

  1.  Deliver value frequently
  2. Collaboration through the entire delivery stream (Dev à Ops)
  3. Bring operational requirements to the front of the delivery stream

 

Value

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.

  •  Individual Development Environment (IDE)
  • Defect Management
  • Continuous Integration
  • Source Code Management
  • Test Management
  • Requirements Management

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!

TAGS

Josh Roberts

Agile / Lean Transformation Coach - Passionate About Delivering Value!

3 Comments

02 September, 2014 Reply

I've not heard the term "continuous integration" before. Can you say more about that?

02 September, 2014 Reply

I see that the Wikipedia article on CI is quite descriptive. It sounds like a very interesting approach. I really like the idea that automated Build Servers "In addition to running the unit and integration tests, such processes run additional static and dynamic tests, measure and profile performance, extract and format documentation from the source code and facilitate manual QA processes."

I also found this statement intriguing: "In the same vein the practice of continuous delivery further extends CI by making sure the software checked in on the mainline is always in a state that can be deployed to users and makes the actual deployment process very rapid."

02 September, 2014 Reply

I also found this interesting Comparison of Continuous Integration Software:
http://en.wikipedia.org/wiki/Comparison_of_continuous_integration_software

Leave a Reply

Your email address will not be published. Required fields are marked *