This post is the first one in a 'How To' series of posts by Peter Measey. The posts in this series will explain different concepts, terms and practices within Agile, as well as how to run these practices.

Agile teams need the capability to monitor and track progress, and also the ability to be open and transparent about that progress. Many Agile teams use ‘Burn-Up’ and ‘Burn-Down’ charts to achieve this, especially within Scrum. This blog provides some practical advice on how to use these charts effectively, and what they can provide for your team.

I have recently taken up playing golf again.

I’m not really sure what made me make this rash decision, maybe it's because I’ve just turned 53 and need some exercise, maybe it's because I’ve decided being a CEO isn’t stressful enough and I need something else to worry about; maybe it’s just because I secretly like wearing loud trousers.

I don’t really know.

What I do know is that now I’ve started to take golf semi-seriously, I’ve suddenly realized how complicated the game is. I keep expecting an epiphany when I’ll start playing like Jack Nicklaus, but instead I keep going out and playing more like Jacques Tati!

What have I learned from this experience?

A white paper written by Peter Measey, CEO of Radtac, for BCS Enterprise, which discusses the integration of Agile with ITIL® (Information Technology Infrastructure Library).

Read the white paper here

Preview

Agile and ITIL® -  And how they integrate

Within the world of method frameworks it is very easy to become polarised on one specific framework and become a ‘fundamentalist’ on that one single method. Method fundamentalism leads to people focusing on why all other method frameworks are wrong and theirs is right, rather than a focus on how integrated method frameworks can enable excellent delivery (which is the whole point of having them). Most method frameworks have something to offer and, via inspection and adaption, they can normally co-exist.

This white paper discusses the integration of agile with ITIL (Information Technology Infrastructure Library).

It is essential that the people in an Agile Feature Team have the same definition of ‘Done’.

'Done' basically means that we have a clear definition of when the Product Owner can say that a story, defect, Sprint or Release is complete.

Basically there are three things that contribute to achieving done status:

1. The acceptance criteria on the stories (and differing levels of refinement)
2. The Sprint and Release goals
3. The standards and guidelines that apply (what RADTAC call the written down non written rules)

This blog discusses the statement: 'Employing Agile transformation experts causes much less disruption to the business, is significantly cheaper and also enables delivery of much higher value IT products faster and more effectively.’

Or to put it another way, Agile’s easy – transformation isn’t.

WHY should I implement Agile?

OK, but WHY bother, surely transforming to Agile is a lot of hassle for little benefit?

What is 'Vertical Slicing'

An oft quoted facet of all Agile approaches is ‘vertical slices’, the idea that we deliver working products (eg. software) frequently, in the best of worlds every few weeks, at the most every few months. The term ‘vertical slice’ means that we focus on delivering working end-to-end features that add value to the customer’s product

The opposite of vertical slicing is technically driven ‘horizontal slicing’ such as production of Functional Specifications or Databases or any other technically focussed delivery that adds no value to the customer in its’ own right.

I have always had an aversion to fundamentalists, people who insist that their way of doing something is the only way to do something. I fear that a lot of people who specialise in delivery and management methods run the risk of being method fundamentalists.

In providing the impetus to change and transformation programmes, Radtac has developed a generic focus tool called the “Three Wall Workshop” (TWW). This is focussed on the general principles of Vision (Why), Strategy (How) and Tactics (What).

The TWW is to be used where there are needs for team development, project management, product delivery, visioning and strategic planning to name a few situations. The principles of TWW are to reverse common thinking within organisations, the TWW approach focusses on people and their need for a clear ‘Why’ they doing what they are doing, rather than ‘What’ they are doing.

When running training courses or coaching clients we are often asked how to initiate Agile deliveries, whether that is for an Agile project or product development effort. This could apply to the initiation of any type of delivery, whether a delivery capability improvement project, or implementing a new or improved IT system.

Regardless of the overall approach, we normally utilise a core technique from our transformation framework RITA (RITA Information technology Transformation Approach) called the ‘3 Wall Workshop’. The remainder of this blog will describe the 3 Wall Workshop within the context of initiating the delivery of an IT system rather than, for example, a delivery capability improvement project. If we were starting the delivery of a capability improvement project then the structure of the 3 Wall Workshop would be the same but the products being delivered would be different.