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.

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.

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

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

The Related Post

SKILLS Agile teams need training! One of the missing links in the implementation of Agile development methods is the lack of training for teams. I noticed in our recent survey on Agile that only 47% of the respondents answered “Yes” that they had been trained in the Agile development process, with over half responding “No.” ...
LogiGear Magazine July 2012 Testing in Agile  
When quality assurance teams and management who have adopted Agile practices first put the ideas to work, they face a significant impediment in unlearning the traditional mind-set and practices that experience in traditional practices has instilled in them. “He who knows to unlearn, learns best.” — Anonymous The following are some of the key aspects ...
Distinguishing these terms from each other can be rather confusing. In an attempt to go back to the basics, Nadine Schaeffer explains in detail the benefits and the necessity of using realistic situations.
The sprint is almost over; the burn-down chart has not budged. The test team sits around waiting. They hear about all kinds of issues, obstacles and impediments at the daily stand-up but there is no code to test. Closing in on the demo and sprint review… then at Wednesday’s stand up: the heroes arrive and ...
Our comprehensive issue on Agile, which was set to be released in June, has been moved to early July. We’ve made this decision in order to accommodate an article from one of our industry’s thought leaders. We’re really excited about this piece and we’re sure you will be too! LogiGear Magazine is dedicated to bringing ...
In the decade since the Agile Manifesto, the movement has encouraged a number of best practices like test-driven development, user-centered design, iterative development, clean code, refactoring, continuous integration, and—arguably—cloud computing. I’m a card-carrying Agile zealot, and to me its benefits are unarguable. Is your IT organization ready to be Agile, seriously? Score yourself on these ...
There is a multitude of Agile testing techniques that are quite sophisticated. The DAD process can help guide your process of tailoring decisions. Agile developers are said to be quality infected, and disciplined agilists strive to validate their work to the best of their ability. As a result they are finding ways to bring testing and ...
Build the right test platform including infrastructure, virtual lab and process. Testing embedded software is both similar and dissimilar to application software testing. The first eye-catching thing is that embedded software is significantly less visible to the end user. User interfaces are limited; there may be a console-based text menu, a simple command line interface, ...
LogiGear Magazine – November 2010
To begin this article, it would be a good idea to, remember this key point: Agile Manifesto Value #1 Individuals and interactions over processes and tools Tools work at the service of people. People, particularly intelligent people, can never be slaves to tools. People talking to each other, working together and solving problems is much ...
“Agile is to software development what poetry is to literature. It is very difficult to do well, very easy to do poorly, and most people don’t understand why a good poem is good and a bad poem isn’t…” – from the web

Leave a Reply

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

Stay in the loop with the lastest
software testing news

Subscribe