Breaking the Addiction to Process

An Introduction to Agile Project Management

Elizabeth Scanlon Thomas

• Publisher: IT Governance Publishing
• Year: 2011
• eBook ISBN: 9781849281850
• Topic: Business
• Subtopic: Project Management
• Index: Business

Not sure if you want to become Agile? This book will explain why you should.

We live and work in an age in which clients' needs are changing rapidly. Deadlines are shortening and existing development methodologies are relatively inflexible. Projects undertaken using these systems are coming up against increasing difficulties. Modern processes need to be fast-moving and adaptable to cope with the pace of business today.

Revolutionise your working practices with Agile

Agile development methods offer greater flexibility than traditional methods. Their emphasis on incremental testing allows maximum adaptability, giving you the tools you need to meet your customers' needs efficiently and cost-effectively.

Save time and money

This twelve-step guide will give you a clear understanding of the way Agile works. It can save you time and money by helping you to:

• improve your business practices
• develop your relationships with your customers
• work more efficiently with your colleagues
• create streamlined and successful working practices

Discover how Agile can help you deliver the results your clients want, and improve your own job.

Buy this book today and discover simple solutions to age-old problems.

CHAPTER 1: SATISFY THE CUSTOMER
THROUGH EARLY AND CONTINUOUS DELIVERY

Time will not be ours forever.

Ben Jonson

Breaking the Addiction to Process Step 1: Don’t be afraid to deliver to customers quickly even if it means living without a full roadmap.

This chapter explains how to work quickly from defining a requirement to delivering a working piece of software to your customer. Instead of time-consuming overall planning ahead of time and working towards a big release, you work on a small piece of the project and deliver that continuously. As Peter Drucker points out, ‘Plans are only good intentions unless they immediately degenerate into hard work’.

The failure of traditional project management

You know how people hate to wait to get something big – Christmas is a good example. You’re getting a nice present – you’d rather have it now than wait until the 25th December. Customers (stakeholders in Agile) are the same; they don’t like waiting either. It makes them nervous. What if they pay your company big money and find out at the very end for the project that what you delivered is not what they wanted or needed? This has been a headache for projects run the old-fashioned way; maybe that’s because traditional project management has been around for more than a hundred years.

A little background

The grandfathers of traditional project planning were Henry Gantt and Henri Fayol.

Granddad Number 1: Henry Gantt (1861–1919)

Inventor of the project management tool, the Gantt chart. A Gantt chart is presented like a table where every line represents a task to be done while columns represent the timescale – days, weeks or months.

Here’s an example of a Gantt chart:

Figure 3: Gantt chart

Gantt charts are easy to read and understood by everyone, which is why they are so persistent in project management. That’s their strength. Their weakness is a tendency to depict dates as set in stone – the movement of a milestone on a Gantt chart tends to be seen as failure.

Granddad Number 2: Henri Fayol (1841–1925)

Creator of the basic project-management functions. He said, ‘To manage is to forecast and plan, to organise, co-ordinate and to control.’ At the turn of the last century, he said all projects should have these development phases:

• forecasting

• planning

• organising

• commanding

• coordinating

• controlling.

The Scientific Management movement

Both Gantt and Fayol were part of the Scientific Management movement, popular at the end of the 19th and start of the 20th centuries. This held that efficient management should be based on detailed analysis of processes so that they could be more closely controlled, paralleling the then accepted principle of Scientific Determinism.

An atmospheric depiction of determinism was sketched by Charles Dickens in his book Hard Times. His character Mr Gradgrind has come to epitomise a man devoted to cheerless profit – a life devoid of any imagination or playfulness. Gradgrind states his aim:

Now, what I want is, facts … facts alone are wanted in life.

A man of realities. A man of facts and calculations. A man who proceeds upon the principle that two and two are four, and nothing over, and who is not to be talked into allowing for anything over.

Quantum and Chaos Theory

In the early 20th century, Quantum Theory effectively ended Scientific Determinism. Later (starting in the 1960s) attempts were made to understand this lack of determinism in the field known as Chaos Theory. Agile, following the principle that not everything can be known at the outset, can be seen as a backlash to classical project management in the same way as Chaos Theory was to Scientific Determinism.

John Sullivan comments in a 1989 issue of The Child and Youth Care Administrator:

This system involved forecasts from various levels and persons within the organisation. Managers from each level submitted their best estimates of the coming year’s activity and, based on this information, the Chief Executive Officer would make up a one-to-five year plan.

In the 1970s, we realised (as we sat in gas lines) that the future was just not going to be a straight-line projection of the past. Planning began to become a very uncertain process as all organisations had to deal with over capacity, resource constraints and volatile markets. Hyper-rational approaches no longer seemed to be the answer.

No one has a crystal ball

The old ways just don’t cut it anymore. The world is moving faster than ever, and projects need to be turned around quickly. We need new organisational models for innovation and execution. Our customers don’t want to wait around for months or perhaps a year before they see working software.

A senior project manager explains:

The problem is that requirements are defined at a particular point in time. No one, whether they are a user, an analyst or a project manager, has a crystal ball. Future requirements are very difficult to predict. This is why there is so much emphasis in Agile methodology on delivery of functionality now.

Having an early piece of software helps the customer refine what they want and enables you to understand their needs better. The result is a more successful project.

We need to make a cultural change in companies today from planning to doing and Agile methodology gives us the tools to do it.

An engineer explains how simple it can be:

If you’ve spent time in the Pacific Northwest, you know of the tyre store empire that is Les Schwab. I remember reading an article a long time ago that said the entire business was built around one simple philosophy: ‘Take care of your customers ... take care of your people ... and the bottom line will take care of itself.’ Overly simplistic? Maybe. But why not try something that basic if the current business model isn’t working?

If you don’t get a product out the door fast, your competitors will

In Agile, you learn to live with a rough initial plan that you can start work on immediately (and which you recognise will evolve over time as stakeholder needs change), rather than using up a lot of time trying to plan every last detail of the project upfront.

In traditional waterfall project management, you assemble a team and write a bunch of specifications in advance then stick to that – come what may.

You talk with the customer at first to see what they want, but then it becomes a sort of us-versus-them mentality where the customer wants this or that, but you push back and say it’s not what’s in the contract, it’s not in your remit or you say you can’t do everything. ‘They are so demanding’, you say to each other, ‘that soon they’ll be wanting us to make their tea for them too.’

When relationships become as tense as this, it’s a miracle if any product is built that ends up being what the customer really wants or needs.

So let’s talk about Agile, and see if it can help you.

Welcome to the flexible world of Agile

The following section introduces you to Agile concepts and terminology.

Agile vocabulary

Here is a list of the Agile vocabulary you’ll need to know as you read the rest of the book.

Completed experiences should be demonstrable to customer or prototyped.

Epic	Highest-level requirement element. An epic is divided into lower-level requirements: Experiences and Enablers. It is planned to be released in a certain timebox, but development can take longer than that.
Experiences	Experiences are easy to understand by the consumer (for example, ‘As a customer, I want a mobile phone that is easy to use.’) Experiences are similar to requirements in traditional project management. Completed experiences should be able to be demonstrated to customer or prototyped.
Enablers	Enablers are technical features needed to implement Experiences.
Product backlog	Prioritised list of user stories (requirements).
Daily scrum	Short stand-up meeting. What did you do? What will do today? What is blocking you?
Scrum master	Leads the daily scrum. Tracks work completed and remaining, and organises removal of things blocking the team.
User stories	User stories are like traditional requirements, but expressed in sentences from the customer perspective (‘As a customer, I want a mobile phone that’s easy to use.’)
Timebox	A year (approximately) of the project is called a timebox. This roughly equates to a traditional software product release.
Train	A timebox is broken down into trains (sometimes referred to as an Experience Development Train (EDT)). A train lasts approximately 8 to 10 weeks.
Sprint	A train contains s...

Table of contents

• Cover
• Title Page
• Copyright
• Preface
• About the Author
• Acknowledgements
• Contents
• Introduction
• Chapter 1: Satisfy the Customer Through Early and Continuous Delivery
• Chapter 2: Welcome Changing Requirements
• Chapter 3: Deliver Working Software Frequently
• Chapter 4: Business People and Developers Work Together Daily
• Chapter 5: Build Projects Around Motivated Individuals
• Chapter 6: Convey Information via Face-to-Face Conversation
• Chapter 7: Working Software is the Primary Measure of Progress
• Chapter 8: Maintain a Constant Pace Indefinitely
• Chapter 9: Give Continuous Attention to Technical Excellence
• Chapter 10: Simplify – Maximise the Amount of Work Not Done
• Chapter 11: Teams Self-Organise
• Chapter 12: Teams Hold Retrospectives and Tune Their Behaviours
• ITG Resources