Article For Comments

Agile Customer Cookbook an IEEE initiative

By ole.jepsen@capgemini.dk January 2005

in collaboration with Scott Ambler, Kourus Goodarzi, Angela Martin, Mary Poppendieck, Nancy Van Schooenderwoert, Grady Campbell, Philippe Kruchten

Preface

The purpose of this paper is to give advice to customers, who are having (or planning to have) software developed by vendors, who are using an Agile approach to software development.

The target audience for this article is business sponsors, business experts and business program- and project managers, who are involved in agile software development projects.

The customer and vendor can be separate business entities – or they can be departments within the same company. (It seems, that the the relationship between the “aquirer” and the “development team” are the same whether the two partys are a part of the same company or not.)

Agile versus waterfall

There are a number of areas, where Agile is different to traditional waterfall software development. Some of the most important areas are:

1.Requirements are made to be understood This may sound odd – but in many waterfall projects, the requirements are more a formal part of the contract than they are a basis for communicating the business needs to the developers at the vendor.

2.Prioritization is ongoing In agile projects the customer and the vendor have realized, that it is impossible to come up with a 100% accurate estimate up front – because they know that the requirements will change over time – and because they know, that unexpected issues about the existing requirements will shop up. Therefore they know that they will need to prioritize not just in the beginning of the project – but all the way through the project.

3.It takes trust to get flexibility Agile customers want flexibility and responsive projects. Some customers try to get both flexibility and a firm agreement about the content up front, but this doesn’t work well in agile projects. The reason is, that you need extensive requirements specifications to be able to make a firm agreement – and that these detailed requirements works against flexibility, and pulls the project in the direction of a waterfall project. So you can’t ask for your vendor to be both flexible and very specific about content. You could say, that the “price” for flexibility and responsiveness is, that you have to trust your vendor – and trust, that your collaborative and ongoing definition of scope and content gives you value for money.

4.Software is accepted in multiple releases A high degree of responsiveness seems to be a necessity in most of today’s development projects. The best way to enable projects to navigate is to have short development cycles that delivers a release of the software. When a release have been delivered, it seems natural for both the customer and the vendor, to revisit the overall plan for the project, and change the plans/scope for the future, if the customers needs have changed. A positive side-effect of frequent delivery and acceptance is, that possible misunderstandings about the requirements will be identified and fixed.

Why Agile

If you are in the target audience for this article, your decision is already made: You will run your project(s) according to Agile values – expressed in the agile manifesto: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan

Your motivation for going agile may be some of the following: •Want to get your software less expensive •Would like to be more customer involvement in the projects •Want incremental delivery of fully functional units (getting the software bit by bit) •Need quicker and more responsive development

Some (additional) benefits that you probably will get out of your decision are: •Ability to run the project, so it supports your business better – also when your business situation changes due to market competitions, legislation, etc •Better collaboration with the vendor: Less time spent on discussions and crises and more time spent on valuable work like communicating and detailing your business needs. •Avoiding misunderstandings about requirements – because you will probably “write less and communicate more”. •Early and frequently delivery of the software gives you othe chance to ensure, that the project is on the right track – and othe option to start using and benefit from the software earlier.

Setting up the team

Chosing a vendor

The expectations you should have to a vendor, who claims to be performing Agile software development is described elsewhere.

The only thing I will mention here is, that it takes experienced developers to make a good agile software development team. The reason is, that the items on the right side of the agile manifesto goes without saying the for the experienced software engineer. Novices might ignore these items completely, which can lead to major problems. It takes experience to know how to create the right balance between the items on the left and the items on the right.

(Actually I suspect the great people behind the agile manifesto to be so experienced, that they perform the items on the right without really thinking about it anymore. That is why they are in a position to be able to handle the items on the left.)

Setting up the customer team

The skills needed amongst the customer-part of the project group is somewhat different that the skills for a waterfall project. You need people with:

•Exellent communication skills The work with requirements is more than understanding, structuring and writing for youself. In agile projects you should have people on the business side, who are strong in face-to-face communication.

•Business overview Because of the ongoing prioritizing, your people must have a general knowledge about your business situation.

•Friendly negotiation skills Prioritizing sometimes grow into negotiations with the vendor. It is important that everyone se this a natural part of a project – and know how to participate in a negotiation and still keep the good relationship with the vendor.

•No fear of the unknown Because of the possible re-definition of the project after each release of the system, you can never be sure about what each individual person will be working with “next month” – or whether the project will be solving the requirements, as they were specified when the project was started…

Needs, requirements and changes

In traditional projects is has been normal procedure for the customer to write a detailed and complete requirement specification. The reason for doing so has been to “ensure that we get what we want”. However – experience over the last decades have shown, that the detailed requirement specifications in most cases did not help. Some of the biggest problems have been, that the requirements •were misunderstood by the vendor •did change as business situation changed

In agile projects our focus is that the requirements are understood by the developers. We have realized that the developers are building what they understood – which in many cases is different from the intensions behind the requirement specifications. A limited number of models and documents may help to achieve this understanding – but simply writing the requirements down and mailing the specs does not ensure the understanding. You could say, that the goal is the understanding. The documents are only one of many ways to achieve the understanding – but then can not stand alone. Workshops and face-to-face communication are other important communication techniques, that you should use to ensure understanding.

You could say, that “the role of the paper” is changed in agile projects, where the papers most important role is to support communication and understanding.

This puts the agile customer in a special situation. The traditional customer role was only responsible for describing the requirements. The agile customer should also feel responsible for the communication and understanding of the business needs and requirements.

Problems with extensive requirements specifications

If you have a extensive requirement specifications, there is a tendency, that the developers look things up there – and that this substitutes the face-to-face communication, that would have given the developer a deeper understanding. This may lead to misunderstandings, which again leads to a waste of time and a lot of work from the customer later in the project.

An other problem with the very detailed requirement specifications are, that is takes a lot of work to keep them up to date, when the business needs change – or when you simply change your mind about some of the requirements, because you have gained more knowledge than you had, when you wrote the requirements in the first place.

In most projects, experience have shown, that it is more efficient to document the business needs in more general terms, in the beginning of the project. During the course of the project you need to detail the requirements for each iteration – and if you do so in close collaboration with the vendor, then you save yourself all the problems with the misunderstandings.

Though it sounds counter intuitive – experience shows, that an extensive requirement specification does NOT ensure, that you get what you want. Focus on communicating the requirements gives a better chance for success.

“But how do we make sure that we get XYZ from the vendor, if we do not communicate all the details up front?”

Usually you find out, that what you want is not XYZ but rather ZYX – and the better the collaboration with your vendor, the earlier you find out what you really want.

“But how can we be sure, that we are not getting less from the vendor, than we pay for?”

There are a number of answers to this question: •Agile software development works best, when there is a mutual trust between the customer and the vendor… (But is it not the same with traditional development?) The solution seems to be: Find a vendor, which you trust. Agreements and contracts needs to be in place to, but trust is more important. •Most iterative development makes detailed specs and decisions on a “just in time” basis – meaning that the details about requirements for a specific release is worked out within the timeframe of the iteration. This means, that you will spend much time with the vendor every now and then, which again means that you will get a feel for how well he is performing. •Because you get your software delivered early and frequent, it is easier for you, to abort the relationship with a vendor, if you find, that the vendor is supplying less, that you pay for.

However, there can be some projects, where you will

Use cases

An other way to improve communication of requirements is by specifying functional requirements with “use cases”. This technique has over the last decade been adopted by more and more companies.

Very briefly – the use case technique consists of: 1.Identify the end users (“actors”) of the system 2.Identify the tasks (“use cases”) that each actor need to solve together with the system 3.Describe the interaction between the actor and the system for a normal flow through each use case 4.Identify and describe alternative flows for each use case

Note, that step 4 usually takes 75% of the time, because this is where all the business rules and decisions have to be made.

The use case technique is well suited for collaborative specification, where you make pairs of one customer and one developer – and get them to write the use case specifications together (“pair requirement specification”)

Changes

It’s a good idea to agree on how changes to business needs and requirements are handled between the customer and the vendor. Because needs and requirements will change.

This is one more reason to limit the up front work with the requirements to describing the general business needs – and do more detailed specifications on a “just in time” basis: When you have a limited number of pages with general business needs, then it takes less time and effort to keep it up to date, when the needs changes. The detailed specifications for each iteration will not change much – because they are created just before they are needed. So the time in which changes can occur is short – which will give fewer changes.

Friendly change management

Changes were bad in waterfall projects – because there was no efficient mechanism (like iterations) to handle the changes. Because of old habits changes still has some negative associations. Jim Highsmith puts it this way: “They make change management boards. That’s not the way they work. They work as change resistance boards.”

In agile projects change is OK – and hence both the customer and the vendor must handle the changes in a positive atmosphere. It means that •The vendor must receive changes in a friendly manner. The vendor must examine which impact the change would have on the project and the system •The customer must – also in a friendly manner – receive information about impact •The customer and the vendor must – together – decide whether to implement a change now, implement it in one of the next iterations, or skip the change because it is to expensive compared to the benefit.

Often there are discussions about wether a change request is a “change” or an “error”. In agile project I suggest, that this discussion is skipped. It’s really mostly about who’s “fault” it is. (A change being the customers fault – and an error being the vendors fault). This discussion is very bad for the positive atmosphere in the project – and the result of the discussion is often useless, because both changes and errors should be treated the same way: The more important seen from a business perspective - and the smaller the effort and risk seen from the vendors point of view – the sooner the change/error should be implemented.

However – if the changes get’s out of hand, then they can take over the whole project – and you end up not reaching the project goals within the given timeframe. You have a zig-zag project, where the developers are taking so many detours that they never make it to the any destination. An agile vendor will probably be very open-minded towards any changes. Therefore - to avoid zig-zag project – the agile customer should make sure that only the “right” change-requests makes it to the vendor.

Whether you chose to setup a change management administration is up to the individual project. The bigger the project-team and the more integrated the sub-systems are – the more need for a more formal handling and communication of errors and changes.

How much requirement specification up front?

So you should not try to specify everything down to every detail up front – but how much specification should be made up front then…?

One answer to this question is: 1.A brief list of success factors – and/or a one or two line “vision” of the project 2.A brief list of functional and non-functional requirements 3.A use case diagram showing actors (inclusing other systems) and use cases 4.A short description (1-2 sentences) of actor and each use case 5.Desription of the normal flows for all use cases 6.Specifications of business rules in general and overall terms 7.A sketch over the user interfaces

An more correct answer is: It depends on the situation. You should probably add to the above list, if you have some of these situations in your project: •Your project team (customer reps and developers) are unfamiliar with the technology and/or the business area •Your team is scattered around in various offices, buildings, cities and/or contries – and can not be collocated. •Your project team is big. Up to 10-12 people can share a common understanding mainly based on human conversation and whiteboards. Bigger teams needs more formal specification and communication.

Just be aware, that more specifications work against flexibility and that a larger base of specifications takes longer to keep up to date, when changes occur…

Iterative development – multiple releases of the software

A cornerstone in agile development is iterative development, where you get your software bit by bit – realease by release – along the way. This allows you to ensure, that the project is on the right track, that your vendor performs sufficiently, and to benefit from the software earlier.

Seen from the vendors point of view, the benefits are that motivation is higher, that they identify potential problems earlier, and that they can get accept from you for each release.

Timeboxing

Experience with iterative projects shows, that releases should be triggered by time, not a targeted level of functionality. The reason is, that requirements and functionality will always (and should always) be discussed. A deadline supports a result oriented approach in these discussions – and speeds up business decisions and IT decisions – which again speeds up the development project – which again gives more functionality in the software.

Therefore you should as a customer support your vendor in his attempts to deliver parts of the system on the predefined dates – even if this means, that you must accept less functionality in the current release. In the long run you will get more functionality – as described above.

Acceptance of each release

Without the extensive requirement specification, there is a lack of background for your mutual agreement about the delivery and the price. Also the agile vendor will probably work with less detailed plans. So how do we determine whether the vendor has delivered what you expect?

The main thing, that your agile vendor will deliver to you is software. And his only way of making sure that his delivery is OK – and therefore his only way to make sure that you will pay him – is for you to formally accept the software release by release.

This is a benefit for the project as a whole, because it will close discussions and open issues after each iteration – allowing everyone in the project team to focus on the content of the next iteration.

Focus on the product – demand frequent releases

The iterative approach allows you to focus on the product (the software) more than on the project – which is what you want.

In traditional projects your feedback from the vendor would mainly report status to you by telling you how this and that activity of the project went – as if that was important. The activities are only a way to get to the goal: The delivery of a product. And if we can focus and evaluate the product itself rather than the activities – we are much better of.

Your chance to follow the development of the software product is by reviewing the software along the way, which you can only do if the vendor releases it frequently.

During the last time before delivery of a release, the vendor will probably have a hard time on getting the software out of the door. The vendors project manager can use all the help he can get – and you can help him •by letting the whole development team know, that you demand to receive the release on time and •letting the team postpone possible not completed functionality to the next release without to much hassle.

Let the software work in production

One of the important benefits about iterative development is, that you can give feedback about the software early and frequently.

One way of doing so is to show the software to some people who are representing the real end users. This gives you some feedback. An other way is to show the software to some of the real end users. This will give you more relevant feedback. But the way to get the best feedback is to implement the software for real – and let it “live in the real world” with real customers, transactions, etc.

Even though this may cost some extra work in your business organization, the value is huge: You will stop “thinking” that the software will work – and you will start “knowing” that the software will work in a live business environment.

There are also benefits seen from the vendors point of view. Therefore some developers are talking about “the right to deliver”. As an agile customer, you should do what you can to make it possible.

Organization and responsibility

Take partly responsibility for plan and budget

Of course a customer should work for getting as much software for the money as possible. But if you go to far in that direction, you start seeing negative impacts on the outcome of the project…

In flexible and responsive projects you and your business decisions and priorities have huge impact on the project. And as discussed above, you can not both have flexibility and a specified and guaranteed content in the software.

Most agile vendors will probably suggest the payment to be based on the amount of time they use – or they will suggest some sort of shared risk/reward model. This is their way of protecting themselves against customers, who demands far more then they are paying for. In other words, it is not only the customer who needs to trust the vendor. The vendor also need to trust the customer.

If the vendor gets into trouble, there’s a fair chance, that these problems will affect you as the customer as well. The best way to avoid this is for you as a customer to realize that you decisions and prioritizations have huge impact on the project – and hence take your part of the responsibility for the project plans and budgets. Also if you se potential problems and issues, that are not addressed – then bring it up – even if it seems to be the responsibility of the vendor, to solve them. This will benefit the whole project and give you more value for money.

Spend time with the developers

Many org-chats can be drawn – but what matters more is how the members of the project team is located physically.

Most agile vendors have their teams members sitting together in one room. If they are clever, they also invite the customer representatives of the team, to join them in the project room.

As mentioned above understanding is a key element in agile development. The only way to really, really ensure understanding is for the people to communicate face-to-face. Given the amount of business knowledge, that developers should understand to make the right system, you as an agile customer should spend as much time as possible with the vendors project members.

This will speed up communication and understanding – and it will give you an idea of what slows development down, and what speeds development up. Much of this has to do with the way the business people are playing their role, and when you know this, it will probably influence the way you are playing your customer role in the project. One example of a positive factor is to cut down the delay for developers to get answers on their questions. Developers who are participating in agile projects tells how great it is to be able to just turn around, ask a question, get the answer – and carry on with their work.

If it is not possible for you to post business people with the developers, it is a good investment for later communication to get to know your peers at the vendor. So if nothing else – make sure to spend time with the development team in the early phases of the project.

You might think, that you do not have the time amongst the business people to spend so much time with the development team. Chances are, that you find that you spend less time in total – because sorting out misunderstandings later in the process takes much more time than getting it right the first time.

Communicate to your organization

Some business people get problems with their managers and business colleges when they spend much time working in projects.

One reason is, that you – as a project participant – seems to “disappear” from the daily life – which means more work for your colleges.

One way to avoid this is for you – as a business participant in the project – to taker over the vendors communication about the project to your background organization. If you demo the software after each release, then you also explain what you have been doing – and you might even get some feedback than the vendor would have gotten…

Consolidate and communicate changes

In agile projects, where changes are welcome and therefore more frequent, it sometimes becomes a big task to consolidate new changes with earlier specifications and decisions – and to make sure that the relevant persons understand.

Sometimes the vendor takes the responsibility for this – handled by a requirement/analysis person. Sometimes they don’t.

In any case, it is important, that you take a part of this responsibility, because you are the one having the deep knowledge that is required to make sure, that the development team members really understand what this is all about.

The end

Agile is not a complete methodology – it is a set of values, that you can base your system development on.

This article has given you a few guidelines about how to act as a customer in an agile project.

If you are looking for a full agile methodology with more prescriptive guidelines, it would be natural for you to take a closer look at the agile methodologies like eXtreme Programming, SCRUM, Chrystal Clear, etc.