Topics

Featured in Development

Understandability is the concept that a system should be presented so that an engineer can easily comprehend it. The more understandable a system is, the easier it will be for engineers to change it in a predictable and safe manner. A system is understandable if it meets the following criteria: complete, concise, clear, and organized.

Featured in Architecture & Design

Sonali Sharma and Shriya Arora describe how Netflix solved a complex join of two high-volume event streams using Flink. They also talk about managing out of order events and processing late arriving data, exploring keyed state for maintaining large state, fault tolerance of a stateful application, strategies for failure recovery, data validation batch vs streaming, and more.

Featured in Culture & Methods

Tim Cochran presents research gathered from ThoughtWorks' varied clients and projects, and shows some of the metrics their teams have identified as guides to creating the platform and the culture for high performing teams.

How to Remain Agile When You Have to Sign a Contract?

Agile development based on a contract that has been accepted by lawyers seems impossible. The nature of traditional purchasing and contracting processes does not match the Agile principles. When a project is small you can manage to find a workaround, but for a huge, high risk project the situation is different. The client wants to know what he gets for his money, while in fact he cannot really specify his needs in sufficient detail. Having adopted Agile working principles years ago, at a certain moment we had to face this challenge. And it just appeared to be like Nelson Mandela once said: “It always seems impossible until it’s done”. Let’s share our experiences with an insurance company.

It was an unusual situation. An insurance company wanted to introduce a new health insurance service to the market in about 6 months’ time. The supporting workflow and communication applications had to be developed from scratch whereas integration with the existing policy registration application was a must. Clear specifications were lacking. All in all a very ambitious and risky project. Several providers prepared a proposal, which the client did not trust because of the extreme price bandwidth. They fortunately realized an Agile approach had to be followed to have a working solution within 6 months. This was our luck, because in many other cases it took us quite a lot of effort to convince the client that an Agile approach would be best.

RFPs provide a lot of information, but most often not what is really needed

The RFP consisted out of several pages of technical and functional requirements. It was immediately clear why the other providers prepared such different proposals. Despite all the work done by the client’s business analysts too many things were unclear and essential functionalities and descriptions of integrations were missing.

Related Sponsor

Because it was clear that information was lacking we proposed to introduce three weeks of brainstorms to meet with the analysts and domain experts (several end-users included).

Together we discussed the different functions and tasks, defined user roles, which all together resulted in the “scope of the project”. We summarized the discussion through epics and where possible user stories to show how we understood their needs.

Even the client understood the complexity of their own processes better after the workshops.

Estimating to prepare the proposal

Is it reasonable to agree about a deadline and budget if you don’t exactly know what should be delivered? The answer is yes – but only if you use project methods suited to this type of project challenges. Agile is one of them. Although we managed to agree about the scope, we were still facing one of the major challenges: defining and formalizing all the agreements. Nowadays a framework for Agile contracts is available, but not when we were preparing our offer.

We decided to estimate in two different ways. First of all we estimated in a more traditional way by discussing how much time a certain user story would take. We checked this assumption by “guessing” how much design, development, test and implementation capacity would be needed to realize the project within the agreed timeframe. The second approach was based on “Planning Poker”. The team members basically defined the complexity of the epics and user stories by comparing them. Based on our historical experience with similar projects we more or less knew what velocity (amount of development hours per story point) we could assume.

Of course these methods lead to different estimations, but by having the estimations from different approaches we were better able to define the project amount we assumed to be needed to deliver the requested solution. We included a risk factor as well, because we considered a lot of additional management would be needed to run the project.

And then the price negotiations started

For the client the budget amount we mentioned was too high (like always we could say). Thanks to our fully transparent project estimation the client was fully aware how we had estimated the project. Thanks to this transparency they knew that all we included was really needed.

We convinced the client to increase their budget to get closer to our estimation. We agreed that the client’s budget would be the so called “target” budget for the project. On top of that we added 40% which lead to a maximum budget, the “cap” budget. As soon as the project would cross the target budget, the client would be invoiced half the hourly rate of a developer. We also agreed that in case we would manage to realize the agreed scope within the cap budget, that we would share the savings. Above the cap budget we would have to work for free. Cap budget should not be used to cover any brand new requirement that was not agreed before. In this case a standard change-control process should be raised. The Target-Cost-With-Cap approach has been inspired by John Rask’s article “Target Cost Contracts”.

Once we reached this verbal agreement the project execution started. The formalities would still take about two months, but we couldn’t wait any longer. Based on a gentlemen’s agreement the project was being kicked-off.

Lawyers are needed ……

Drafting a business deal is one, but writing it down in such a way that bureaucratic administrative processes will be pleased, without blocking the agile project execution is a real challenge. As by our request the client send us their purchase conditions. And these were far from Agile.

Our lawyer who had learned to be more agile already prepared an agreement, including several of the client’s conditions and we send this back to the client. Their lawyer reviewed the document and basically all our proposals were removed.

We concluded that these legal iterations were going to lead nowhere and therefore we organized a meeting in between the directors representing the “business” side and both lawyers to explain the client’s lawyer the aim of the project, why it had to be agile and what agility means.

That helped.

The construction of the contract

A framework agreement was being drafted. This framework agreement included apart from the general purchasing conditions rules like:

The scope of the agreement being software development. Maintenance and administration, user documentation, user trainings, etc were for example excluded.

Division of the project into releases.

The high level release planning of the releases.

The explanation of the Agile process, including division into iterations, usage of user stories to define the scope of the releases.

The acceptation process per release based on acceptation criteria and the final system acceptance after the final release and the client satisfaction. The acceptation document was being included as an attachment.

Fault handling procedures.

Communication in between client and provider and the decision making power of the key persons involved.

Templates and documents to be used during the development process.

Payment terms based on the project division.

For administrative reasons at the client side quite some paper work was needed and we agreed about the following paper flow around the project.

Dividing the project into smaller pieces

The whole system was divided into 10 releases to be able to define and manage the scope of work better. Every release had its own budget, based on high-level estimations of epics and user stories. Thanks to the “story points” and “planning poker” approach we were able to determine the needed time to accomplish a certain release.

We managed to draft a framework agreement with the “rules” of our cooperation. In addition every release had its own agreement and acceptation protocols.

Per release a team of analysts and consultants defined the scope, resulting in a “Release Product Backlog”. The Release Product Backlog contained all the use cases that we were supposed to implement together with appropriate acceptance criteria and the Definition of Done, which each use case had to comply to. Thanks to this we knew exactly what should be done and when it was really well done. Together this formed the “Release definition”.

Then the development team would break down the release into a lot more detailed user stories. Together with the product owner priorities were set resulting in a planning per iteration. This was all formalized through the “Iteration agreement”. In addition per iteration the team defined the expected velocity, which was used as one of indicators to measure the success of an iteration.

During the development the product owner was frequently informed about the development status and domain experts were involved as well, among others to provide more detailed information, to review user interface designs and to test new or changed features.

Every release was tested by the client, based on the earlier defined acceptation tests. In case the client confirmed that the release was more than 85% “done”, the project would continue, the release had to be paid and the planning of the next release would start. Remaining work would be included into the next release. This would lead to a sign off of the release acceptation protocol, a document needed for the client’s financial administration. Otherwise the invoice couldn’t be paid.

Thanks to the great cooperation the acceptance level exceeded the 85% by far in all releases.

(Click on the image to enlarge it)

Within the framework agreement the start and delivery date of every release were defined and this obliged all project participants to stick to them. Shifting a deadline wouldn’t be allowed. The budget for every release had been defined as well (both the target and cap budget). The only variable part was the release scope, meaning what features exactly would be realized.

How the contract supported the project in reality

When the client approached us with their RFP we didn’t feel comfortable about this project at all. It was too high risk. Thanks to this contracting process the project became a manageable one. In fact the big project was divided into ten smaller ones, which were (re)contracted every time. The advantage of this process was that all the main stakeholders met each other frequently to discuss the status of the project and to adjust the approach if needed. Client satisfaction was measured continuously. It made the process a bit more bureaucratic, but a lot more predictable. It dramatically reduced the project risk for both sides.

All these advantages were noticed by the client as well. They realized they needed an Agile way of working to reach their goal and to prevent bureaucracy when they would like to introduce changes during the development process. This contract provided them the essential documents to manage their administrative processes, meanwhile safeguarding the Agile development of the project.

The framework agreement remained unchanged during the project. Slight adjustments were made to the different documents used during the process to make them better match both our client’s and our development teams’ needs.

The contract provided clear directions to the project and it defined the playing field really well. Based on the contract we could force the product owner to provide input to the project in time, we stimulated them to show up with the acceptance criteria in time, etc. Frequently we had to remember each other about the obligations of the contract, but just and only to make the whole team stayed focused on delivering the project scope on time and within budget.

The contract supported us in getting paid for the work done as well. The contract clearly defined when project parts had to be paid and the client fulfilled these obligations in most cases according to the plan.

We internally decided to include the client satisfaction level into the personal reward of some of the key members of the development team. This appeared to be very stimulating.

Flexibility with costs permanently under control – is this possible?

Frequent interaction between both sides and testing new elements of the system on regular basis are genuinely supportive in case of introducing changes to the initial scope of requirements. This is usually not possible when the project is managed using one of the traditional methodologies – each change leads to an increase of the overall cost or long discussions between both sides on whether a certain requirement has been already well-defined and springs from the initial documentation.

Knowing that during the development the ideas about the optimal system would change (and they always will!), the client was allowed to adjust both the scope and the priorities of the releases/iterations. As long as this was “budget neutral” there was no problem. Because of new insights during the project development several new request led to both scope and budget increases. Fortunately, the deadlines still didn’t have to be adjusted. The development teams managed by adding additional resources when really needed. This enabled the client to explore in an empirical way what functionality would add most business value. They were able to tune the platform to their real needs.

A well-adjusted solution on time

Thanks to the chosen approach we could show initial results of our work – a fully functional user panel – already after the first iteration (2 weeks). After 2 months we started the deployment of the first part of the system and users could start filling the system with production data. By that time the formal agreement still hadn’t been signed.

For the client this way of working meant that at a very early stage they could start using parts of the system, instead of waiting till the first planned deadline. For their business planning this meant a big relief. Besides, they could immediately start tuning the system based on real experiences. For them the whole business process was brand new and they also were not fully aware what to expect.

Every release new participants (from the client side) have been introduced to the project. Representatives of end users were validating the system and they provided useful feedback, which enabled the development team to refine the system and re-prioritize the implementation of certain features.

This approach resulted not only in a stable, working system, but made it a well optimized one, delivering the highest possible business value.

Thanks to the iterative delivery of the system it was frequently tested. The amount of potential bugs and problems has been considerably decreased by means of automated tests which enabled the team to test the backwards compatibility.

Each iteration ended up with running automated tests covering previous versions of the system – to make sure that any new version would not break the existing set of functionalities. Furthermore new automated tests were created to cover new features and functionalities in tests as well. In addition end users were testing every iteration.

This made the acceptation of the full system become a formality.

Tips for Agile contracting

Depending on the type of cooperation a “bureaucratic” contract might be requested by the client. We believe this doesn’t have to block an Agile cooperation. Take the time to reach a mutual understanding about the needs/demands, exact project scope, work approach, etc. Define the needs in the form of user stories, because this stimulates everyone to describe them in a more understandable way than regular functional descriptions.

It might take some missionary work to convince client representatives who are just slightly involved into the project. Do not “attack” them, you will have to realize that they might not fully understand what an Agile approach means. In general they want to feel they are in control and you will have to explain how they can control an Agile project as well.

Step by step by working together the mutual trust will grow and both parties will profit from that.

Together with the client we allowed a little bit of bureaucracy to be part of our Agile project. We managed to limit it to the paper work that the project manager could handle. It supported the project governance in a more traditional way, a way our client’s internal organization needed. The development teams were never bothered, they developed the solution following the Scrum method. In the end almost the whole cap budget had to be used, which didn’t surprise us to be honest. We expected this. A significant additional budget for new developments and a long term maintenance agreement, made this investment from our side more than worth it. Our client was really happy to have a very well-tuned working solution on time and within the agreed budget.

Based on the project description above we concluded it is possible to develop a huge project in an Agile way by cutting this into smaller pieces. It took some time to define these pieces and to prepare a matching contract, but it was worth the effort. By spending a significant amount of time together at the beginning of the project we very well understood each other’s wishes and needs. This mutual understanding grew into mutual trust when we noticed how well the cooperation went, thanks to the initial time investment.

Now we can conclude Mandela was right.

About the Authors

Paweł Bejger is a Microsoft .NET architect based in Gdansk, Poland, where he is the Operations Director of Goyello, an Agile Software Solutions House. He is always searching (and creating) the most efficient ways of working that satisfy both the development team and the client. As a certified Professional Scrum Master he is a real advocate of Scrum.

Peter Horsten is a Dutch entrepreneur based in Gdansk, Poland, where he is the co-founder of Goyello, an Agile Software Solutions House. Graduated as both an electrotechnical engineer and a sociologist, he is always looking for (IT) solutions that best fit the organisation. He implemented the Scrum methodology within Goyello in 2009 and is a real Agile advocate since then.