The Agile Practitioner: Using Agile Tools

Agile Transformation

For the last few years, I have been immersed in the world of software product development. Working as a “scrum master,” my role is to ensure that small teams of people working to create and maintain software products adhere to the principles of the agile philosophy. This month sees the beginning of a new series for BPTrends entitled “The Agile Practitioner.”

Agile was born out of the tradition of lean manufacturing. It should come as no surprise that there are many similarities. Keeping the primary focus on “the customer” and empowering individuals through education and decision-making authority are two examples. We will be getting into more of the theory, philosophy, and practice of agile in subsequent Columns. In support of the transition from my last series entitled “Process Solutions,” this Column will discuss some of the tools that teams use to manage their processes.

What Agile Process Tools Do?

Most obviously, any tool must support the agile principles. I have written about these in a prior BPTrends Column, which you can read here if you are unfamiliar with the topic. In the past, software vendors provided tools for software lifecycle management. Agile process management has now been folded into these tools. The vendors that have most effectively adapted have gained momentum. There are also a few that were born out of the agile movement.

In general, Agile process tools provide support for some or all of the following:

  1. Product roadmapping
  2. Work planning/management
  3. System documentation
  4. Issue management
  5. Communication
  6. Software code management
  7. Software deployment/release management

Using Agile Tools-fig1

Product Roadmapping

Agile practitioners (or Agilists, as I like to call them) often scorn the idea of a product roadmap. Technically, it is a holdover from the waterfall days. Some argue that to be agile, product managers should not plan the product too far ahead for fear of restricting or at least influencing future priorities. Others believe if plans are kept high level and based on customer-driven requirements, roadmaps can be a useful tool. In any case, some tools still offer the ability to create timelines for functionality implementation.

Using Agile Tools-fig2

Work Planning/Management

One of the primary practices amongst Agilists is breaking work into small chunks (called user stories or just stories) that deliver specific value. Breaking work up into small chunks means there will be a lot of them, so managing each story is imperative. In some organizations, each story may not only be built, but deployed into operational environments for testing and even production (where users will have the new functionality available). More about this later.

The tool used to manage this is commonly called an Agile (or Scrum) Board. Teams that don’t break their work into one to four week “sprints” (some sprints could be longer or shorter, but this is the typical range) will use a kanban board, which is similar. The Agile software tools are generally attempting to improve upon what is referred to as a card wall, which looks something like this:

Using Agile Tools-fig3

Card walls display each story and where it is in the the process (e.g. to-do, in-progress, in-review, testing, done). Some teams use card walls (or as in this case, sticky notes) in addition to a software tool because card walls are easy for the team to gather around and rearrange interactively (often, in this scenario, someone will catch up the software tool after the team has updated the wall).

Usually, there is one person responsible for prioritizing which stories will be worked on. On agile teams, this is typically a Product Owner, but could also be a product or project manager. The team often contributes new stories as they identify work that needs to be done. They will also have input into the prioritization based on their specific expertise and experience.

System Documentation

Whenever teams are building a new product, it is important to maintain good documentation. With most products of a physical nature, documentation must be maintained separately from the product (for obvious reasons). However, since software starts and ends with computer code, some of the most useful documentation can be maintained right inside the product itself. Good developers write code that others can read and understand with the addition of some well placed annotations.

Using Agile Tools-fig4

Increasingly, software architects are moving to something called “micro-services.” The idea is fairly simple. Rather than have large monolithic blocks of code that do a lot of things, have many small blocks of code that do one or a few things. By making these micro-services reusable, they can be requested to perform their function by other small blocks of code. To make this work, each service must have a well-documented set of inputs and outputs. These inputs and outputs are commonly referred to as “application program interfaces” or APIs. Large enterprise systems will have hundreds of APIs. An API manager becomes essential to document them.

Using Agile Tools-fig5

Not all documentation can live in the code or the API manager. For this, many agile process suites have something referred to as a wiki. You have probably heard of Wikipedia. The name was taken from the documentation tools that allow authorized people to add pages to a content management system in an organized fashion.

Wikis can contain architectural diagrams, high level product information, and functional descriptions. Some wikis may also contain end-user documentation for public online access.

Issue Management

As with any product, software experiences operational issues typically reported by users. It is important to make the reporting of issues and the tracking of their resolution as easy and visible as possible to encourage reporting. When users find it difficult to report and track issues, they just deem the product to be bad and move on to the next one.

Using Agile Tools-fig6

In some tools, issue management is part of the work planning/management tool such that there is no difference. In other cases, the issue management is held separately, but integrated, so that as work is performed, the associated issue is updated.

An important feature of issue management tools is the ability to perform analytics. These tools can be the main source of data for evaluating work priorities. Users regularly use issue management portals to make feature suggestions. These suggestions can get “upvotes” by many users, thus providing valuable feedback.

Using Agile Tools-fig7


It seems that most Agile practitioners are working in an open collaboration space these days. The purpose of these spaces is to enhance communication (see my article with Keith Harrison-Broninski on collaboration spaces). For reasons elaborated in the linked article, communication doesn’t always happen as expected.

One way to increase the odds that good communication will happen is to provide good tools. Every organization now has email. Different people manage email in different ways. Although most have some sort of notification turned on so that they know when an email is received, many people choose to read email periodically. This is not always beneficial when collaborating. Chat tools are a very popular way to stay connected in software development environments.

Software Code Management

This is where the things start to get a bit more technical. Unless you are involved directly in software development, you probably don’t want to know too much about this and the final category of tools. The easiest way to think of code management is like a library. Each chunk of code is like a book. It has it’s own place on the shelf, where there may be multiple versions (or editions in book parlance). When a developer wants to work on some code, they check it out and after they’re done, they check it back in and a new version is created. There may also be security placed on the system such that only authorized individuals can check out code (which is different to being able to look at the code)

Using Agile Tools-fig8

Code is placed in something called a repository. Agile development teams that are advanced in their practices will make relatively quick, small changes and update frequently (in hours, not days). This means that code organization is critical. These tools allow rapid change with reduced risk of confusion or chaos.

Using Agile Tools-fig9

Software Deployment/Release Management

Having built some new functionality into the code, the team will want to get it into the hands of users. There are two scenarios here (with many variations of each):

  • Web based applications that users access via the Internet
  • Client based applications that are installed on private devices (e.g. smartphones, PCs, servers)

Some organizations accumulate multiple changes into a package called a release. The second type of application above is always delivered as a release. If you have used any software, you’ve probably seen version numbers like Each segment of the version number represents the magnitude of the change(s) made in that release, with the leftmost number being the most significant and the rightmost typically representing bug fixes.

A growing number of agile teams that are building web based applications (#1) are doing something called continuous deployment. In this variation, each developer is free to deploy a single change as soon as it passes the appropriate tests and is deemed production ready. Version numbers will likely still be assigned, but most changes will be small.

In addition to packaging up changes into a release, these tools also support the automation of the deployment process. Some are capable of doing something commonly referred to as “deploy-on-green.” In this scenario, a set of comprehensive automated tests are developed in advance. When the application is deployed, it will first be put into a test environment where the tests are automatically triggered. If they pass, the tool automatically deploys the application to a staging or directly to a production environment where the tests are run again. As long as the tests pass, the application continues progress toward being available to users. If at any point the tests fail, the prior version of the application is redeployed and messages are provided to the developer regarding the errors generated via the tests.

Whether an organization is ready for deploy-on-green or only automates part of the deployment process, deployment managers allow for ensuring that historical data about the deployment is gathered and alerts are generated when something goes wrong.

Software Selection Process

There are so many options available and many factors that go into choosing the best tools for your organization. For some years, I provided software selection consulting. Most of my clients were purchasing ERP software, but a few were looking at other tools. In a future Column, I may do a more in-depth piece on this topic, but for now, here are the basic steps:

  • Understand your process (mapping or some sort of documentation is a good idea here)
  • Research extensively to gather a list of potential solutions (rarely should you settle for 2-3 candidates – there are usually dozens in any category)
  • Compile a master feature list by compiling feature lists from individual products along with features you would like (of find something like it on the Internet)
  • Weight features based on how important they are to you
  • Create a scorecard for each product with a weighted score (based on weights)
  • Get demos of top 2-3 products
  • Pick a winner and perform due diligence

It is easy to fall into the trap of going with whatever is popular or products with which the people in your organization are currently most comfortable. This is why this process-driven approach yields better results. These other factors are not good criteria for a decision that may have high switching costs. Even switching from or to products that are free can be very expensive. In most technology groups, labor is the highest cost. Switching products can take weeks or even months (sometimes many months). This often adds up to far more money than the product costs (or savings), and that is not even considering the opportunity cost of doing projects that are more valuable to the organization.


There are many products that offer multiple components of the tools outlined above. Few (if any) will offer all of them. Even companies like Atlassian, which covers a lot of bases, offer integration with products from other companies.

Your Environment

If your teams use the Microsoft suite of development tools, that is going to drive many of your choices. If you deploy into one of the cloud providers (Amazon AWS, Google Cloud, or Microsoft Azure), you will be looking for tools that work well with your particular environment. Are you currently doing or striving for a continuous deployment environment? That will drive your choices as well.

If you are considering new tools, it is a good idea to consider the environment you are working towards, as well as the one you currently have. Agile organizations are continually improving. That means there will be a certain amount of acclimation during transitional periods. Tools that are designed to support where you are going will help you get there with less disruption.

Learning from Others

Before making choices, look at the organizations that are using the tools you are considering. Are they operating at the same scale as you? If they are all smaller, maybe the tool won’t scale well to your organization. If they are all larger, make sure that you can handle the resourcing required to maintain the tool. If you find that organizations that are working in a similar fashion are using the tools you want to use, there’s a better chance they will work for you too. If you can, reach out to them and ask them what they like and, more importantly, what they don’t like. Make sure you can live with the shortcomings. Every product has them.

Tom Bellinson

Tom Bellinson

Mr. Bellinson has been working in information technology positions for over 30 years. His diverse background has allowed him to gain intimate working knowledge in technical, marketing, sales and executive roles. Most recently, Mr. Bellinson finds himself serving as an Agile Coach for ITHAKA, a global online research service. From 2008 to 2011 Bellinson worked with at risk businesses in Michigan through a State funded program which was administered by the University of Michigan. Prior to working for the University of Michigan, Mr. Bellinson served as Vice President of an ERP software company, an independent business and IT consultant, as chief information officer of an automotive engineering services company and as founder and President of a systems integration firm that was a pioneer in Internet services marketplace. Bellinson holds a degree in Communications with a Minor in Management from Oakland University in Rochester, MI and has a variety of technical certifications including APICS CPIM and CSCP.


  1. Ankit Nikhra says

    Hi Tom,

    Thanks for summarizing the agile software development process in a very easy way. This post has provided an realistic view of the agile software development.
    From a software development practitioner’s point of view; Adopting agile has always been a win win strategy; however there are many challenges when timeline for the development and release are on stake. I would like to know what should be the next action or strategy through agile when timeline has been crossed and delivery of a software is showing Amber or Red signal.


Speak Your Mind