![]()
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... |
