CHAPTER 2: AGILE TERMINOLOGY

2.1 Artefacts

In Agile-speak, artefacts are products. Agile talks about six ‘common’ artefacts. In PM4A terms, these artefacts are project management products.

The six common artefacts are:

Product vision statement

The vision statement is a ‘what we are trying to achieve’ statement that the development team, Scrum Master and stakeholders refer to throughout the project. Anyone involved with the project, from the development team to the CEO, should be able to understand the product vision statement. In PM4A this might be the project mandate.

Product roadmap

A product roadmap is a high-level visual summary that maps out the vision and direction of your product offering over time. A product roadmap communicates the why and what behind what you are building. It is a guiding strategic document as well as a plan for executing the strategy. In PM4A there is the project justification document.

Release plan

Project plan.

Product backlog

A list of all the products needed for the end product.

In PM4A the first of these would be called the project plan and, using product-based planning, the product backlog would be shown in the product breakdown structure.

Sprint backlog

In PM4A the equivalent would be a plan for the Create phase.

Increment (timebox)

In PM4A this would be a work package.

2.2 Information radiator

A general term used to describe the use of noticeboards containing information that can be readily accessed by people working on the project. Information radiators should be big, visible, unavoidable and able to convey information at a glance from across the room.

An information radiator can contain any information, and it typically shows such things as work to do (the PRL), work in progress and how work is progressing. If we enlarge this concept to include identified risks and issues, the PM4A action log for these becomes more open. Such boards often include policies for changes of work states. The concept is to have this information available on physical noticeboards for all to see, rather than in electronic form where visibility is less easy to achieve.

2.3 Iterative development

You might think that in general, an iteration is the act of repeating, but for many Agile practitioners it has a slightly different meaning.

For many Agile practitioners, usage of the term ‘iteration’ refers to the small section of work done in a single ‘timebox’ and in only ‘one repetition’; that is, just doing a small part of the entire work once. So in their Agile terms, there is no idea of doing a piece of work, going back to refine it, then doing it again, say, a third time to ‘get it right’, which is what you might think ‘iteration’ means. So, doing the whole job in a series of short ‘timeboxes’ is what is conveyed by the sense of ‘iterative development’ by several Agile practitioners.

Just to make sure we are clear on this, although the adjective ‘iterative’ can be used to describe any repetitive process, it is often applied to any heuristic planning and development process where a desired outcome, like a software application, is created in small sections. These sections are ‘iterations’. Each ‘iteration’ is reviewed and critiqued by the development team and potential end users. Insights gained from the critique of an ‘iteration’ are used to determine the next development step.

I don’t like the idea of using a name in such a misleading fashion. To me, an iteration means testing the first result, going back to revise it and maybe doing that a third time. In 2007, Jeff Patton said:

I most often see people in Agile development use the term iteration, but really they mean increment. By incremental development, I mean to incrementally add software a time. Each increment adds more software – sorta like adding bricks to a wall. After lots of increments, you’ve got a big wall. By iterative development I mean that we build something, then evaluate whether it’ll work for us, then we make changes to it … We never expected it to be right. If it was, it’s a happy accident. Because we don’t expect it to be right, we often build the least we have to to then validate whether it was the right thing to build.⁴

As in our method, we are going with the concept of a development team that includes the product owner, which will greatly help such evaluations. Naturally you must bear in mind what the end product is. Maybe three iterations of building a bridge isn’t too good an idea though!

When creating project plans, make time for iterations where appropriate. Don’t overstuff plans by scheduling exactly as much work as can be done in a particular time period. A full project plan is a late project. Allow for iterations. Allow for changing and modifying requirements.

Let’s take a simple example of iteration. I want to redesign my back garden and I draw, say, three different designs on paper, and discuss them with my wife. If I am lucky (seldom), we will agree on one. More likely the result will be either a hybrid of the three designs. If not, I go back to the drawing board. When we finally agree, I take a piece of string and pegs and mark out the layout of the design on the actual back garden. Now another review. Does it look as good as it did on paper? Again, another possible set of iterations to get it right. So, in our method, iteration is not a single timebox and it can be done from the start of the project, not just during development. Even planning the project can be (and should be) an iterative operation.

2.3.1 Iterating and incrementing

Incrementing means adding a little bit at a time. Here is an example:

You open a transport café. Formica tables, metal chairs; one person takes the orders and handles the drinks, another person cooks and serves, (there is a small, basic menu). As business grows, you add more items to the menu, more types of drink, upgrade the chairs, use tablecloths, better signage outside and so on.

2.4 MoSCoW

This is a technique for grading requirements:

M = ‘Must have’– this feature is required or the end product may be useless.

S = ‘Should have’ – a very useful requirement but if not possible, there is a workaround.

C = ‘Could have’ – a useful feature that would be nice but is not essential.

W = ‘Won’t have’ – a feature that is not needed in this project. It may be added in a later project.

2.5 PRL or prioritised backlog

This is a list of all the work that anyone thinks is required. It may comprise several new requirements, change requests and/or work that was not completed on time and has been returned to the PRL for re-prioritisation against new work. There is no direct PM4A equivalent. It contains all the work (possibly) still to be done, but not in a plan showing when it will be worked on. Work for the next stage is selected from the PRL. The PM4A equivalent to this section is a stage plan.

2.6 Retrospective

This is a regular event that examines how the work processes can be improved based on recent experience. This is the same as PM4A lessons learned. Agile emphasises that it is done more regularly than is implied in PM4A and often feeds back into future work within the project. In PM4A, the use of lessons learned is aimed more at future projects.

2.7 Scrum

Scrum is a working framework within which people can address adaptive problems, while productively and creatively delivering good quality products. It is a way of bringing together the required skills in a team and empowering that team to work in a series of timeboxes to deliver functionality very quickly. In the past, it has been closely aligned with software development, but there are now case studies where it has been used in construction and even emergency aid projects.

I have not used the term ‘Scrum’ in this generic method of flexible project management, but the philosophy behind the development teams is the same.

2.8 Stand-up meetings (also known as Scrum meetings)

Figure 2.1: Stand-up meetings

Important questions to ask during stand-up meetings:

1.What did you do yesterday?

2.What are you going to do today?

3.What’s stopping you from achieving this?

This is a short team meeting, usually held daily and normally lasting 15 minutes or less. The team reviews the previous day’s progress in order to plan the next day. This meeting is a course correction, an instance of inspect/adapt for the sake of the work package. The leader of the meeting (the ScrumMaster), has a role to understand any potential blockages and see that they are resolved by the next stand-up (Scrum) meeting.

Together with the information radiator (see chapter 2.2), stand-up meetings dispense with the need for most formal written reports. Because the user (product owner) is part of the team, there is a continuous flow of progress information to the customer.

2.9 Timebox

This is a finite period for work to be carried out to meet an objective or deliver a product. It is a key Agile concept that the time allowed is never extended. Instead, the work allocated is prioritised and done in that order (see MoSCoW). If all the work is not complete by the end of the timebox, the unfinished part is returned to the PRL to be re-prioritised and re-estimated or sized to reflect the remaining effort required.

The work in the timebox is to deliver the selected features. The PM4A equivalent is a work package with no tolerance on time. The generic method developed in this book will use the term ‘work package’, but it will follow the Agile timebox rules.

⁴ www.jpattonassociates.com/dont_know_what_i_want/.