Avoiding disasters by including Legal subject matter experts in agile/lean teams.

A friend responded to some comments I made about Agile and Lean Program Management. She said that not all elements of a program can fit into a set Lean and Agile principles. Hmph! name one I challenged. There are in fact quite a few that are serial rather than iterative but she must have been feeling kind to me because she said,

"Legal, you can't do iterative contract negotiations, they are waterfall is anything ever was!"

"I suggest you should rethink that" I replied.

I am not alone. Jordan Furlong lists 7 Reasons For Implementing Agile in Your Law Firm as

1. Early and continuous delivery of valuable service
2. Embrace changing requirements
3. Co-workers must work together on a daily basis
4. Build projects around motivated people
5. Face-to-face — the most effective way to communicate
6. Simplicity is essential
7. Self-organising team

Greg McLawsen’s of Puget Sound Legal says, “I’ve implemented a lot of different technologies since opening the firm,” ... “And without a doubt, Kanban has been the cheapest technology we’ve implemented, because it was basically free, but it was also the easiest. In terms of return on investment and energy, it has been hands-down the best thing we’ve done to improve the practice.”

London firm Wedlake Bell has stated its commitment to agile working to improve the effectiveness and flexibility of its service. Managing partner Martin Arnold said: ‘The use of technology and the flexible working practices that it enables are vital. Agile working is something that is not only possible but essential for a full service law firm that is seeking to achieve the highest level of service integration.’

Within a transformation program having legal subject matter experts (SMEs) work with the technologists also brings benefits. Let's look at a few agile principles and see how they fit into work streams with a legal element.

Once you start to think about this as a proposition you may start wondering what aspect of technology does not have a legal element. Purchasing: software, infrastructure, hardware and technology services in general has huge contractual considerations.

More often than not the contract comes at the very end of a work stream. The final stage before a major new system is installed or new network provision or new software or hardware installed. It comes as a massive 300 pages of closely typed obscure, dense, dry and difficult text.

These immense boilerplate documents do not encourage reading let alone understanding. The stakeholders open it and then quickly fire it of to the legal department to check out. Here lays danger and disaster. Here are three real life examples where involving a legal expert using agile and lean principles in the management of a program would have avoided problems.

Going down with the ship

On moving into a new building and in receipt of some VC funding the company saw a chance to upgrade their IT infrastructure. They purchased a managed service for all their internal network. It aimed to provide virtualisation for the main office, the international centres and the field offices. While it was being implemented they continued to use the old servers in the old building.

Two years later they called in a consultancy in to look at their whole technology systems. The new virtual network was still not up and running. The about to retire very senior director, who had taken ownership for this purchase, and the operations director under who's watch it occurred on both started to get very twitchy when this work stream came under inspection.

"It is not in place yet, but we are pressing the suppliers" ... "and we were very smart because we put a clause in the contract saying they did not get paid a penny until we were satisfied with the performance of the new network." said the purchasing director.

"Oh not too bad then." said the consultant "Their specification is really bad and they are charging you a fortune for the hardware that the VS resides on. Revise the specification to reflect what we are discovering about how your employees work. It would be much better for you rent functionality on their your suppliers hardware rather than leasing your own and having them run it.

They have have stitched you up like a kipper. As they have not been able to provide a working solution it is time to ditch them. Get legal to start the process".

Legal came back saying that the contract still stood even though the supplier had failed to deliver. How is that possible?

"There is no delivery date specified in the contract" says legal.
"I am going retire now" says the purchasing director, "but I before I go I must protect the Ops Director as I hired him. I will also shaft the consultant for pointing the problem out. Then negotiate a new contract with the supplier. We can keep struggling with the old servers if we take on another 3 year lease on the old building.”

• Deliver early and often to satisfy the customer.

This was a ￡4m project and doomed for many reasons that were outside the scope of the legal department. Yet if legal had been operating within a framework of agile principles. If it had taken an iterative approach to forming the contractual relationship the consequences of shipwreck could be avoided. By breaking the whole contract into a series of requirements and having a user story for each requirement; segments that make sense can be delivered.

• Continuous Integration

will allow each story to be evaluated in relation to other segments and its dependencies made visible and tested.

• Continuous Delivery

Once broken out of a single large waterfall document  and into iterations segments be easily be seen by the business. If one of the iterations was limited to completion dates it would be clear to the procurement team that 'delivery date = 0'. By delivering this iteration the procurement team would see very easily that no completion date was set. They would be able to make a judgment on the consequences of this and ask for that to be changed.

• Continuous Improvement

The clause of 'non payment until satisfaction with the performance of the new network' appears to be good one for the purchaser. If a legal subject matter expert had  been a part of the team they may have pondered what would happen if satisfaction is never met. The technical members could express what satisfaction looked like.

IT struggling along with the old servers has consequence; emergency call outs to reboot the system being one of them. The costs of not achieving satisfaction (i.e. continuing to pay for the old premises) were another aspect that could have been brought into the frame of reference. Considering these events would have improved the overall value of the contract.

Each part of the story could be dealt with by legal as a separate iteration and delivered to the team. Being small and digestible the techies could envisage the consequences of the several parts. Not having the virtual network would impact other parts of the program such as rolling out software updates.

Yes there is a cut off point in contractual negotiations, at the point of signing. The pressure to get to this point takes on a frantic urgency and effort spirals as cut off gets closer. The urgency can be allayed by not leaving it until the end, but instead running the process along with the program and with a desire to deliver elements of value early and often.

Changing tack

The company recognised a need for a fast internet connection, the IT department trawled the suppliers. They did a detailed comparisons on many products in the market. They recommended a perfect fit for the needs of the company. A cable connection was leased for three years.

Everything was fine but the business grew and needed more capacity. Over the two years fibre products had changed so an ideal solution was to swap deals. The original supplier had new products that could use the existing fibre and give 50 times more capacity.

OK looks good says IT we will take the new package. Take it along side the old one said the supplier, it will give you a backup system and you can always upgrade when that lease ends. The trouble was that lease did not end it auto renewed 12 months before expiry. "Oh well said the supplier you can upgrade in four years!"
Legal said, "The contract looked fine, auto renewals are fairly standard we did not know you would want to change the deal".

The company had an outdated and useless facility for three more years, it did not provide enough bandwidth to give  a failover capability. Changes in the needs of the business are not confined to applications, they extend to process and capacity. A legal view which looks to the need for change will be able to plan for changes at contractual levels. This is true for relations with customers as well as suppliers.

• Welcome changing requirements.

Having a legal SME as a part of the team that looked at the business need and ways of fulfilling that need would have made them aware that changes to requirements are very likely. No supplier likes changes and uncertainty which is why auto renewals are built in. When a renewal takes place the legal team has the opportunity to look at the arrangement anew. An agile approach would be to invite change from the business.

The legal SME would more than likely highlight the effect of change if they understand the reasons for it. They may suggest cancellations become automated on the earliest possible dates. They may look to add flexibility to the contract. They may propose a different course of action such as building upgrades into the lease.

A legal team embracing change will find opportunities to reduce waste. More importantly they will begin to understand that the business is agile and that change and the ability to respond is important. They will also see the benefits of change as it affects their work how eliciting change gives legal products more value.  The inefficiencies of the waterfall method for producing large documents will become apparent.

A storm in a port

A company wanted to port all of their hosting to the cloud but had a recent three year contract with their provider. No problem they bought the contract out for ￡1.5m. New contract signed for the release from the existing contract in thirty days. Thirty days go by and the supplier sends a ￡500k invoice for the next quarter .

"No way" says the MD "we are not paying you, we bought out of this contract"
"Fine says" the supplier "I will turn off the supply",
"but we are not ready to port yet" says the MD,
"OK pay up" says the supplier.
The MD gets on to legal and says  "We bought out of the deal and now they want to charge us for a new quarter, is there nothing in the new contract to say we have covered the handover period in the buy out payment?"
"You did not ask me to write that in, you never mentioned a handover period!" says legal.

• Business people and developers must work together.

The cloud has many advantages, distributed storage and compute give a lot of benefits but moving from a traditional hosted environment to a cloud environment is for most companies an unknown. The biggest unknowns they face are the amount of work effort required and the time the migration will take.

Yes we can do it say the developers, yes it will bring benefits and substantial cost savings. How long will it take, we are unable to make an estimate until we have completed some stages say the developers. The business as a whole and legal in particular were not aware of this conversation.

What have the legal department and the developers got in common in any event? Well quite a lot really because this change involves two sets of contracts one with the old supplier and one with the new supplier. If a SME from legal was a part of one of the developer teams on this project they would see how the change was being planned and how it was emerging.

The change might start with feasibility installations over different suppliers, this gives the legal SME a view of the velocity of the project. By being a part of the team the legal SME will also see that this migration is made of many parts.

As the project delivers something the time and work effort can start to be estimated as "Working software is the primary measure of progress." At this point the legal SME may start proposing a framework for contractual negotiation that fits with incremental releases. With this in mind they may approach both the incumbent and the new supplier. The incumbent may refuse to provide any flexibility, but at this stage the project does not demand total buy out, it may just be a small change in scale.

If the incumbent is not being flexible on reducing scale then legal can return to the team and point out that the port will need to be big bang. Migration dependant on being able to move everything all at one. This will influence the team's approach, they may choose provide a series continual releases into a mirror of the final deployment.

As cloud services are generally pay as you go parts of the deployment can be turned off once tested. Having been made aware from the legal SME that a successful migration needs to include all of the traditionally hosted services will change the project. The developers will see the value of, and, concentrate on delivering:

• A desire to rationalise dependency management, to provision and configure all the constituents of the stack.
• The requirement for reproducible deployments so that the whole application can be erased and then accurately reproduced.
• The ability to create multiple instances of the same application and significantly to recover from failure at any point during provisioning.

I am not suggesting that every work steam has a legal subject matter expert included as a member of the team. However if it involves high value contractual agreements it is madness not to have them involved. The team will benefit from understanding the implications of what the business is committing to. The legal SME will benefit from knowing what are the important dates, dependencies and critical issues.

Originally published semiotica.co.uk on August 9, 2014.