Agile software development grew out of a movement to establish within IT, practices that are founded on tight feedback loops, timeboxing, collaboration and communication, self-organization and empowerment. It was as much a reaction to, as a recognition that, traditional phased approaches to project management (e.g., Waterfall) introduced structures that potentially inhibit initiative and innovation. Instead, agile encourages adaptive planning, reflection, servant leadership and an open embracing attitude towards change and risk. The inherent structure of agile processes comprises of multiple overlapping timeframes that capture the essence of iterative development and incremental delivery.
Therefore, when it comes to describing agile software processes, linearity simply doesn’t cut it! Try mapping out daily rituals such as stand-up meetings and nightly builds and you quickly find that it is not only tedious but largely pointless since even minor changes to practices require major reworking which in turn inhibits feedback and continual process improvement.
Instead consider how things might look if we used circles instead of lines. This idea can be traced back to the notion of process cycles originally attributed to Don Wells and has been developed into agile charting by the Institute for Agile Risk Management in the context of agile risk management. Let’s start by taking a look at a simple generic agile process described using three concentric circles, the transition of each of which implies multiple transitions of its inner circle. We begin at the top left and work our way clockwise from the outside to the inside.
This chart describes an agile process wherein each increment commences with the formulation of a business case for the release followed by high level delivery planning. During the increment acceptance testing preceeds training of staff before the solution is deployed into a production environment after which any benefits realised may be analyzed. Each increment, however, requires several iterations, each of which begins with iteration planning, updating of project management artifacts (e.g., information radiators), ongoing testing and tracking of progress followed by a demonstration of what has been achieved by the iteration and a gathering of any lessons learned (e.g., a retrospective). Of course each iteration comprises of several days (typically 2-4 working weeks) each of which begins with a daily stand-up meeting, followed by solution development and often concluded with a build to ensure that everything is in working order. This compact description of an agile software development process is very simple to understand, maintain and clearly communicates how the team intends to work.
Another advantage of agile charting is that it makes apparent recurrent activities i.e., those that are linked over multiple timeframes. This is a natural feature of iterative processes. Consider planning as an example: This is initiated at the release cycle in the form of high level plans that are refined at the iteration level and acted upon after the daily stand-ups. Slicing enables the team to visualize recurrent activities by grouping them together and helps frame the search for missing elements of the process. As seen here there are several natural slices in our agile process (i.e., planning, testing and deployment).
Agile charting not only communicates intent but is also excellent at soliciting feedback. By simply placing indicators (e.g., stars for positive and thunder bolts for negative feedback) on the chart, it becomes possible to make precise where issues arise. For example, the build issues in this chart suggest that there might be future cause for concern for demonstrations which might ultimately impact live deployments.
There are many other applications of agile charting and a terrific resource on this topic is the free publication Agile Charting: A Practical Guide available from the Institute for Agile Risk Management website. Download it and send us your feedback. In fact, we invite you to explore these ideas for yourself and submit your own contributions for future editions (see publication for further details).
This article was originally posted by the IARM on LinkedIn, June 17, 2014.