Tools to support Agile

There are many tools we can use for agile with all sorts of levels of support and sophistication. Being agile, we can make best use of any tool we are given, but it is important to know what we want from them so we can make best use of what we have and propose new tools in a rational way if we feel they would help us work better.

The most important thing is to make the tools fit to the way we want to work. We must never change the way we work to fit the tools. However, it is always interesting to see what a tool does ‘out of the box’ and compare it to what we need. Even if we do not use the tool, thinking about how it relates to our work helps us think about how to organise our work better.

This article is just an overview of key ideas and what is possible.

What we need (minimum)

Whether we are a small team or part of a larger organisation, all individuals, the team and stakeholders need to see (at the appropriate level):

• What is on the backlog
• What is ready to work on (including priorities and estimates of effort)
• What is in progress
• What is unable to progress (what in blocked for any reason)
• What has been delivered
• Statistics on development and delivery cycles
• Communication and interactions between people supporting all of the above

Like a lot of things in Agile - Keep it simple. Do not over-engineer the tooling solution, but keep it as simple as is possible while satisfying the needs that you have.

Physical tools

The simplest tool is just a physical whiteboard, or better, sticky notes and a whiteboard. Or 3x5 cards, or a combination. This works for small, independent teams but is unlikely to satisfy the needs of a larger organisation, where levels of progress and reporting are needed.

{{add a pic or two}}

Advantages: Cheap; easy; very visible (for co-located teams); great for small pieces of work.

Disadvantages: limited information; different views for different audiences not possible; no easy analytics; takes a bit more maintenance.

Standard computer tools

You can capture agile information with the basic ‘office’ tools (e.g. google office tools, LibreOffice or Microsoft Office). This has an advantage over a physical tool because it can be shared, so it works with distributed teams and sharing information between delivery and management teams. Plus these are tools everyone has and knows how to work.

If you are using these tools, make sure you do not rely on single copies of the files hidden away on the computer of one individual with restricted access. Make them as widely visible and collaborative as possible (see “Document Storage”{{}}).

Advantages: Everyone has access to them and some knowledge of using them

Disadvantages: Become too much effort for anything more complex than simple projects; need to think about how to best use them in an agile way - it is easy to be unagile with them.

Common Office tools

Office tools are the standard suites we all probably have, such as Google office tools (), LibreOffice () or MicroSoft Office ().

Presentation tools (e.g. PowerPoint): Don’t (on the whole). The clue is in the name - they are for ‘presenting’ and are not great for collaboration and information sharing. There is already too much use of them for reporting. They can create intermediate layers of communication and interpretation in an organisation which get further and further from the ‘real’ data with which we want to work. There are cases when they are appropriate, but you need to make a strong case rather than using them as a default.

Spreadsheets: Used as 2 dimensional collections of data, spreadsheets can be very useful in Agile - either as stand-alone tools or integrated with specific agile tools. For example:

• Track progress by creating a grid with columns based on item status and a row for each item
• Manage planning by reviewing backlog items in a spreadsheet, capturing the refinement process and adding data such as assignee, priority, estimate of effort etc. Can also drive planning sessions to determine which work to plan for the immediate future (e.g. next sprint)
• Support work hierarchy breakdown by putting highest level items in the first column, then breaking down into multiple items at the next level in each successive column

They have graphing/visualisation tools which can be set up to show some useful information about our work

Most organisations have lots of people who are already have advanced skills with spreadsheets.

There is quite a lot we can do here, but we need to keep track of the effort involved. Using spreadsheets is effectively re-writing things that come for free in the specialist agile tools, so if it starts getting complicated or taking a lot of effort, then consider moving to a dedicated tool

Word processors: Useful for shared information and documentation {{}}

Other general tools

These tools do other things than the core agile work management, but something like this is immensely helpful in delivering the effective overall agile working experience - particularly with distributed teams and organisations.

e-Whiteboards

These are collaborative online tools such as Mural or Miro (there are many others). They can be used for almost anything - as flexible as a normal whiteboard but with many extra features.

{{}}

Wikis

Wikis are a quick way to produce and edit documentation for many purposes. Wiki is the Hawaiian word for ‘quick’. Anyone who can use a simple word-processor can use a wiki.

{{good structure matters}}

Chats and emails

Live chat tools can be a very effective way of facilitating communication with agile working. People can interact with them as needed (so it does not interrupt their existing work pattern) and they are self-documenting - maintaining a history of the chats that took place. {{more}}

Email also has a place. It is not a replacement for actual conversation, but has the advantage of being self-documenting (you keep a record of emails) {{more}}

{{Do not forget telephones and live calls}}

Document storage

Documents are essential to Agile (but not central, as they were with waterfall processes). There are many sorts of shared storage we can use to keep these documents - especially when working with cloud-based platforms. You need a good strategy for working with these documents:

• The default is to make everything open and visible. Do not restrict visibility without reason
• Ensure the maximum number of interested parties have access to edit them
• Make sure all relevant participants know how to get to them
• Provide a clear structure and guidelines around producing the different sorts of documents

{{More?}}

Dedicated agile tools

Not an exhaustive list, but: Jira, ADO, Kanbanize, Trello, Pivotal Tracker are all options (and there are many others). In almost every case, these tools will be inappropriate if used ‘out of the box’. You need to take some time to think about how you want to work and customise the tools to support your ways of working. Some tools will be better suited to your way of working than others - some are simpler or more visually appealing, and some are very powerful (none have really achieved both yet).

These tools provide a lot of features which specifically support agile working and also support working in structured organisational environments. This is the level of tooling you should be aiming at if you have more than a few teams or a large organisation. Do not assume buying/subscribing to the tool is the solution to your problems though. It is just a tool. It needs to be set up in the best way for you and everyone (at all levels) must adopt it and maximise the value it provides.

All the tools include:

• Work items (with titles, IDs, descriptions, assignees etc.)
• A set of states that an item can progress through (e.g. backlog, ready, in progress, blocked, in testing, awaiting deployment, deployed)
• Tools to let you analyse and visualise the work in various ways (e.g. sprint progress, cycle times)
• Some sort of hierarchical structure of work, so work items can be constituted of smaller work items which contribute to the parent work item

Most include:

• Ways to relate information across multiple teams at different levels of abstraction
• Customisable items types and workflows
• Customisable visualisations
• Dashboards which can capture a wide variety of information in the best way for you (as a group, team or individual)
• Automated processes to carry out activities when certain things happen

Customization is a really important part of getting these tools set up in the most effective way for you. There is a lot of customisation when you first acquire the tool and after that it becomes easier. Do not assume you will stop customising though - as teams and work evolve, so will the way you use the tools. Building the knowledge and experience in the organisation for each team to control the tools within overall constraints is essential. While there are a lot of variations in detail, some of the core activities in making best use of a tool are:

• Understand how you work now and how you want to work (external help is very useful here)
• Understand who the audiences are and what they need to see from this information (include at least individuals, teams, stakeholders)
• Choose which sorts of work item you want to have
• Decide what hierarchical relationship you want between work items (can be more flexible is some tools than others). This relates to all the above
• Choose the information you want to be visible on each work item and set up the appropriate templates
• Decide what states you want a work item to go through and set up those states and corresponding columns on your boards appropriately. If needed (and only if needed) add conditions and behaviours associated with moving an item between states
• Decide what sorts of visualisations of the work are appropriate for each audience and create dashboards of relevant live data to display the information in a clear and relevant way

As mentioned above - this is not a once and done process. Do it when you first get the tool, but then expect the customisations to evolve over time (especially the last two) and at all levels (individual team, stakeholder, management etc.) as the ways of working evolve. Being Agile includes agile tools and agile use of agile tools.

{{How to choose a tool is a different conversation}}