Hot News - Magazine

Agile ALM and the Tools to Practice It

Armed with the right tool or set of tools, a development team can incorporate ALM into its Agile process and start reaping the benefits of Agile ALM.

By Eric Landes

As the software development industry matures, it is devising methods for ushering products from inception to completion—a process that has come to be known by the buzzword ALM (Application Lifecycle Management). Of course, development teams having been practicing ALM since software development began. The fancy acronym is the new thing!

For its part, Agile software development methods  support all aspects of ALM. In fact, Agile puts ALM practices at the forefront of software engineering. This article explains how ALM can help organizations in general and then discusses how Agile practices utilize ALM.

The Elements of Application Lifecycle Management

Practices in ALM can be grouped into three areas:

  • Governance
  • Development
  • Production

Within each area, the following practices can be applied to any development team’s ALM strategy:

  1. Requirements gathering.
  2. Project management tools.
  3. Source control.
  4. Defect tracking.
  5. Automated testing and more.

As software teams have grown, tools to manage these parts of the lifecycle have become mainstays for many organizations and an important consideration in the ALM space. But what makes an ALM tool or practice Agile?

Agile ALM

Because of the discipline that Agile methods have imposed on development teams, many tools have emerged to assist with those methods. As the Agile Manifesto states, “Individuals and interactions OVER processes and tools (that is, while we VALUE the items on the right, we VALUE the items on the left MORE).”

Clearly, Agile does not discourage the use of tools. What makes an organization’s ALM practice(s) Agile is not the tools or which ALM practices it uses. Organizations need to utilize ALM practices only when it helps them to deliver value. Agile is not a silver bullet.  It is a better way of developing software. So, making sure that individuals on the team interact frequently and do not rely on the tools over the interactions is one way to ensure that your ALM practice is Agile.

To ensure that interactions are valued more than tools, do not choose the tool and then make your process fit what the tool does. Have your team members familiarize themselves with the Agile methods first, using a team room if possible to conduct lots of high-bandwidth communication. Then use low-tech options such as cards on a wall and spreadsheets for your ALM requirements and planning tools until you need something more advanced. All the while, hone the interactions between your team and the business. When it becomes too painful to continue with the low-tech approaches, research the tool that allows you to eliminate the pain.

How Agile ALM Improves Planning

For some folks, planning their software development project means putting the plan in Microsoft Project (or Primavera or some other project management system). This involves a lot of initial planning, followed by deciding what gets done first, and then writing a plan that estimates far into the future what will get done.

For Agile teams, while comprehensive project plans can help to coordinate large initiatives, most planning takes the form of release plans with stories. The focus is on team collaboration. The planning happens within planning sessions that allow for changes to scope, resources or dates quickly. Using reporting mechanisms like burn down charts (release burn down charts show the progress of the team), velocity charts, and cumulative flow diagrams helps teams plan. Task boards also make the team’s planning more transparent.

Planning also happens in a more collaborative way using Agile methods. Scrum, XP, Sprint, or iteration planning sessions allow the team to plan and commit to what they will get done within a fixed amount of time. This also allows them to adjust their plan quickly when things change (as they always do).

Here are some examples of tools that can be utilized for planning activities. This list is by no means complete, but these tools support Agile methods:

  • Pivotal Tracker
  • Version One
  • Rally
  • Lean Kit Kanban
  • Microsoft ALM
  • IBM Rational

How Agile ALM Improves Requirements Gathering

Agile teams rely on smaller scoped work items in their requirements gathering. Most teams utilize user stories to convey features that need to be built.

ALM tools must have a way to capture stories and use these stories in planning sessions. The easiest ALM tool one could use for basic  requirements gathering is index cards on a big board. Using a board and index cards is a great way for a team to begin a project. It is also a great way for co-located teams to show requirements and track them (planning). With large distributed teams (large being more than 10 people), however, it can become difficult to use this method.

Other types of requirements include acceptance criteria. In Agile teams — as in most teams — these take the form of wireframes, mockups, and some written format. Another twist that Agile teams use is automated acceptance criteria, tests that act as acceptance criteria for the team to develop against. Depending on team maturity, using an electronic tool to capture and keep user stories, mock ups, wireframes and Acceptance Criteria can help large distributed teams in requirements gathering. Teams would use the same tools for requirements gathering as they would for planning.

The Role of Version Control in Agile ALM

When writing code as a team you must have some type of version control system. This is a given nowadays for most software developers, but I still hear tales of teams that are using a file system as their version control. And I do not mean Visual Source Safe!

ALM practices — Agile in particular — inform your version control practice. They require that your version control system allows you to get back to a particular version of software easily. Your version control system also should allow your team to work on new features while still allowing you to perform maintenance work if necessary. So you should establish a branching and merging strategy for your team.

This is not necessarily an Agile-only ALM practice; it is necessary for any ALM implementation. Your version control should not be an impediment to delivering frequently. Agile teams must have a way of doing continuous integration when a team member checks in code. This can be done with an integrated ALM solution like a Visual Studio ALM, or using an open source product like Jenkins.

 

 

 

 

 

 

Version Control Tools

Below are some examples of tools that can be utilized for version control. Again, this is only a partial list of (version control) tools that support Agile methods.

  • Git
  • Subversion
  • Perforce
  • Microsoft ALM
  • IBM Rational

Quality Assurance in Agile ALM

An ALM strategy always contains an organization’s quality plan. In an Agile ALM solution, this includes Test Driven Design or Test Driven Development (TDD). So automated unit tests are necessary, along with the ability to have some metrics on those automated tests. Let me emphasize that the metrics are not meant to be punitive; they are meant as information for the team. For example, using a metric like code coverage can tell a team that all the code they have developed has a coverage level of 86% against a goal of 95%. In that case, the team should examine the reasons why their coverage is at 86%.

However, the tool cannot directly tell the team whether those tests are good unit tests. Teams must perform code reviews through pair programming or some other mechanism to determine that. As previously mentioned, automated acceptance criteria can be used for quality checks as well. Some teams use tools for Behavior Driven Development (BDD), which can help in this regard too.

Most tools also include support for automating GUI testing. Since GUI testing is very fragile during some phases of development, use this feature with care. When your product has maintenance releases with new features, GUI testing can help reduce regression testing costs greatly. But if your team has good TDD and BDD tests in place there is not as much need for automated GUI testing. Most tools allow you to track metrics on these automated tests as well.

Whatever methodology or tool your team uses in your quality process, the process itself is another pillar in your ALM strategy.

QA Tools

Below is a partial list of tools that support Agile methods that can be utilized for quality assurance:

  • Cucumber
  • RSpec
  • NUnit
  • JUnit
  • Raconteur

DevOps in Agile ALM

One aspect of development that gets overlooked is the involvement of infrastructure groups with a product. The DevOps approach encourages greater collaboration between the development team and the infrastructure departments, in particular the operations group. ALM practices work well with the DevOps concept because they prescribe stable, consistent development environments that help assure product quality and seamless deployment.

Different environments need to be set up depending on the product (Web facing, desktop, or mobile). For instance, a Web product team may need integration, QA, staging and production environments. If these environments are set up in a haphazard way, your risk of introducing defects into production increases. The assumption is that the environments are set up in the same way. Keeping your environment stable and having a consistent, easily deployable build go a long way to eliminating variables between environments. This is critical to the DevOps concept, which includes a build system that takes the source control and builds and deploys it in a consistent manner on each environment.

Some Agile ALM practices in DevOps include continuous integration practices, where a team deploys to an environment once a day or sometimes every time they check in code. Some teams are using continuous deployment to quickly deploy to production, following all the good practices they want.

Picking ALM Tools

Choosing Agile ALM tools is a team decision. Development teams have different experiences and may be more productive when allowed to use the tools they select. I urge organizations to listen to their development teams and allow multiple ALM tools to be used. Also, allowing teams to pick their own tools (within some parameters) talks to the self-organizing nature of Agile teams. Organizations should give development teams some power in selecting the tools and making the ultimate decisions.

Armed with the right tool or set of tools, a development team can incorporate ALM into its Agile process and start reaping the benefits of Agile ALM. ■

About Eric Landes

Eric has been working in the software field since 1986.  He is currently a solution architect at Agile Thought where he engages in Agile coaching, consulting on ALM practices, good engineering practices and leading software teams.

Eric specializes in Agile Project Management (XP/Scrum variant), Lean Software Development, Kanban, EPM, Enterprise Project Management implementation (Microsoft Project Server) and Software Project Management. He is a Microsoft MVP Visual Developer and Certified Scrum Master (CSM). You can read more from Eric at: www.ericlandes.com

Leave a Reply

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

*


*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>