Key Practices for Agile Services Delivery
How to Get What You Really Want - Not What You Think You Want
While trying a new restaurant one day not too long ago, my 12-year-old son ordered the fried tilapia. When our meals arrived, my son’s eyes widened in shock as the waiter placed in front him a whole fried fish…with tail, fins, and an eye looking right at him.
It may have been exactly what he asked for, but we all knew it wasn’t what he had envisioned.
I’ve seen this throughout my career in the software industry, particularly in places where agile principles have not taken hold, and even more so in services organizations where a detailed statement of work (SOW) is expected before an agreement is signed. In those cases, the item articulated so meticulously on paper often turns out not to meet the customer’s vision, which begins a tedious change request process to get to the desired outcome.
If you’ve been through this tedious process, you know it’s unusual for any amount of detailed documentation to accurately articulate how a deliverable will feel and behave to a customer in their environment – and the longer we spend on trying to articulate the details, the more convoluted the painted picture becomes.
When I decided to join the CA Agile Central Technical Services team, I was wooed by the team’s vision, of which a large part is delivering customized solutions and platform extensions to our customers while modeling agile and collaborative processes.
I have been delivering agile services for this team for over four years, have many repeat customers and do not write detailed SOWs. Even without the details, we have yet to need a change request because the customer didn’t get the outcome they expected.
We accomplish this by modeling agile principles, while also making some non-traditional adaptations because we are a services delivery team.
Two key practices are critical to maintaining our vision:
Key Practice #1: A Lightweight Requirements and Estimation Process
Our team does not produce a SOW with enumerated detailed requirements for a customer engagement.
Does that surprise you or make you nervous? Read on…
Our sales cycle typically begins with a customer discovery call.
This is an informal call with the customer, account team and technical services team so we can gather enough information to provide a timeline and materials, and a not-to exceed estimate back to the account team for the customer’s request.
To keep the requirements gathering lightweight, we focus on getting three key pieces of information during the call:
What is the overall goal and business value for the request?
Understanding this is crucial to the rest of the estimation process.
Not only does this help us provide guidance for the right solution, but it also helps us start to tease out the boundaries of the request and also what follow-up questions we might need to ask.
There may be times when a customer has a request for which an acceptable solution already exists. In this case, we will guide the customer towards the more cost-effective solution, even though it may not end up in a sale.
Our team believes that a good interaction is any interaction that helps the customer solve a problem. We also know that not all solutions are software-based and sometimes the right solution isn’t the most elegant.
What are the potential land mines?
What requests do we anticipate that might blow up a typical estimate for this ask? For example, does the customer have specific security requirements or is there an unusual data shape that will impact performance?
What are the boundaries of the solution?
These questions relate to the customer’s environment or expected usage. For example, if this is an integration, what is the potential volume of requests or what are the constraints of the customer’s network infrastructure?
The key to a successful and efficient sales call is avoiding the smaller details that people often get hung up on. There may be details that the customer feels very passionate about, but these need to be balanced by the amount of time that it takes to reach the desired outcome. There may also be details that the customer feels strongly about but, if given ample lead time to address, they may see things differently once work begins.
Our Estimation Process
After the sales call, the notes are documented in an Agile Central Initiative and taken back to the team for a group estimation process.
Like the sales call, the goal of the estimation process is to have a quick discussion about the request so that the team can ask questions or raise any concerns about the ask that might inflate the risk or the amount of effort necessary. The estimate discussion may also include proposed approaches for some requests.
For example, there are a number of different approaches for a custom integration and the approach that is used will depend on the customer’s scenario and budget. In this case, we will generate an estimate for each approach. If it becomes apparent that different approaches will have the similar costs, we stop designing and move on to producing an estimate.
Within a few days, we communicate the team estimate and any key assumptions back to the sales team and the SOW is initiated. Other than an Agile Central initiative with notes from the sales and team discussions, there is no requirements document generated before creating an SOW.
The lack of an SOW with detailed requirements is often uncomfortable for people, particularly for those who may not be accustomed to working with agile principles.
In fact, I’m sure that by now you’re thinking:
“How do we know we are going to get what we asked for without detailed requirements?”
That question brings us to our Key Practice #2.
Key Practice #2: Customer Collaboration and a Continuous Feedback Loop
In order for us all to be successful, we collaborate closely and use a continuous feedback loop to ensure customers can follow the progress and get what they asked for, or as in many cases, not necessarily what they asked for, but the outcome that they need.
Creating a backlog
When we kicked off one skeptical customer’s engagement, we started with a backlog of their requests, broken down into bite-sized stories and prioritized in a joint kick-off meeting. At the end of the meeting, I suggested a time within a week for a checkpoint to demo the progress and re-evaluate the items on the backlog.
Demo, Refine, Prioritize, Estimate…Repeat
Regular demonstrations are critical in this process for the customer to feel comfortable with where their money is going, without the need for extensive upfront documentation or even a long discussion. Demos give the customers a chance to see the progress, steer the development and ask critical questions. And like my son’s restaurant order, it’s not always clear to them what they have asked for until it’s placed before them.
Demonstrations typically happen daily when onsite and biweekly or weekly when doing work remotely.
When possible, we strive to deliver incremental code for the customer to “play with” while development is continuing. This provides incredibly valuable feedback for testing and discovering unforeseen edge cases.
At each demo checkpoint, the backlog is refined, prioritized and sometimes changed. As we burn down hours on the contract, the customer sees their request take shape, and may provide new requirements or remove old ones. The team or individual working on the engagement will (roughly) estimate the new requests so there is full transparency into the relative sizes of the remaining requests and the customer can decide how they would like to spend their remaining hours.
The backlog and “burndown of time consumed” sets the expectations for the customer as they understand the tradeoffs in prioritizing items against the time that is remaining on the contract. When there is a properly defined and estimated backlog, there is no arguing over the interpretation of the functionality included in the SOW.
The Results: Moving from “How Will We Know…?” to “What If…?”
As one skeptical customer began seeing the progress within the first couple of days, they stopped asking, “How will we know…?” and started asking “What if…?”
They were delighted with the ability to pivot, steer and prioritize the shape of the deliverables as they were being built.
This type of collaboration and feedback is only possible with light requirements and a time and materials delivery model. When detailed requirements are documented in the SOW, then the requirements as written become a legal document which do not leave room for change and amendments. But, with a light SOW process and continuous customer collaboration, requirements and details are discussed just before they are implemented as the deliverable evolves. This ensures a lean process, a valuable outcome, and most importantly, an engaged and delighted customer.