Communication is always vital on an agile project to ensure everyone is on the same page, but it's perhaps most important in a relationship between a vendor and a customer. Here, Marcus Blankenship relates a personal story about a project where communication failed, and gives some good tips for how to avoid it happening to you.
I love the beginning of projects. There is so much hope and possibility! I call this the “unicorns and rainbows” phase. The client has just signed on the dotted line, and everyone is enthusiastic.
The biggest project my company ever sold started out this way. It was a mid-six-figure project to build the first version of a software platform for a start-up spun off by a successful manufacturing company. I’d spent ten years building the kind of software they wanted, I had tremendous expertise in the problem domain, and I was excited to get started. The manufacturing owners and executives didn’t know anything about building software, but that didn’t concern me. It should have.
The startup had hired an experienced VP, Ken, who wanted to do “everything agile.” He would play the role of product owner for the project. I’d worked with him on another project for a different company, and we had a great working relationship.
During contract negotiations the executive sponsor, Ron (who was also Ken’s boss), insisted that the contract include a list of candidate stories. Ken assured me Ron understood that the candidate stories were simply a starting point for estimation. Ken told his management that these stories would probably change as they saw product demos and understood the problem space better. That was “the agile way,” he liked to say.
In hindsight, I should have thought it was odd that when Ken told his management those kinds of things, they didn’t appear to care. In fact, their attitude appeared to be “Do it any way you want, but get it done.” This didn’t feel very agile, but Ken assured me he would sell the benefits and bring them on board.
After doing a month of research and interviews, we decided on team size and roles. Phase 1 would be twelve people working in sixteen one-week sprints. The team consisted of UX designers, visual designers, front-end developers, back-end developers, testers, and the ScrumMaster (me). We had unit tests, Cucumber tests, integration tests, continuous integration servers, and continuous deployment scripts. We huddled, sprinted, demoed, and stood up daily. We poured our sweat and blood into the project. It was beautiful, working just like all the agile books said it should.
We brought Ken on site every two weeks for backlog prioritization and grooming sessions, and he and I were joined at the hip in writing and prioritizing stories. We often added new stories based on feedback from Ron, and shifted priorities to align with the business needs. The backlog grew, and the project shape changed dramatically from the original concept. Ron continued to sign up customers before we were done, which shifted priorities even more.
Ken assured me that he was letting Ron know the impact of these changes on the scope and not to worry about the original candidate stories in the contract. After all, this was “the agile way,” right? To be able to make better decisions after seeing working software? To never have to say “no” to customer requests?
My gut was worried, but my head assured me everything would be fine. I told myself, “Just trust the process, keep delivering great software, and everything will be fine.” Ken would make sure Ron and the board understood agile and the increasing project scope. It wasn’t any of my concern.
For fifteen weeks everything was great. Ken signed off on the demos and the client paid each invoice after they accepted the work.
But you knew this wouldn’t have a happy ending, right?
At the beginning of the sixteenth week Ron called me and Ken. Ron said, “I was reviewing the original contract and requirements, and I want confirmation that these will all be finished for the original contract amount.”
You could have heard a pin drop. I’m glad they couldn’t see me, because my mouth was literally hanging wide open.
“No,” I stammered, “the requirements have shifted over the last fifteen weeks based on your feedback. If you want everything in the original contract, we will have to rescope the project and give you an estimated number of sprints.”
“No,” Ron said. “This contract says you will deliver all the functionality outlined in the stories. I’m not going to pay any more, and you’re going to finish everything you agreed to four months ago.”
Panic set in, and I’m sure he could hear it in my voice. I turned to Ken. “Ken, we’ve sat together every week and prioritized the backlog. You approved each sprint’s stories before the team started. You’ve approved every demo and paid us for each one. What’s going on?”
It was quiet for what seemed like a very long time. Ken finally spoke. “Ron, remember when I mentioned to you that things were shifting around … ?” His voice trailed off. I suddenly understood a great deal more about Ken and Ron’s relationship—and how in the dark Ron really was.
More silence. Ron finally said, “Marcus, we will have to call you back. Let’s meet tomorrow morning, and our corporate council who drafted the contract will join us.”
The next sixteen hours were a blur. I won’t detail exactly what happened, but it involved meeting with my partners, then my lawyer; going over the contract with a fine-tooth comb; and gathering the last six months of emails between us and the client, finding every single working document, etc.
The next morning, Ron called at the appointed time. I was informed that Ken would not be joining us; he was off the project. Later I found out that Ken was fired. In the end, Ron and I came to an agreement about how to end the project in a way that was mutually agreeable.
The moral of this story: You can do everything right, but dysfunction on the customer’s side can still kill you. It is your responsibility to take whatever precautions are necessary to mitigate that risk. Never allow yourself to think, “It’s not my problem if they don’t communicate.”
Here are a few things I do differently now because of that project.
- I identify the true power behind the project before the project begins and tie sprint approvals to that person’s signature. I call this person the executive sponsor (ES)—in this case, it was Ron. This is the person who moves money, whose name is on the line for the project, and who’s making internal/external promises about functionality and timeframe. This is often the person who signs the original contract.
- I maintain a direct, regular, and strong relationship with the ES. Meet with them regularly, include them in all demos, and make sure they are notified of decisions.
- I communicate “obvious” things quickly and loudly to the ES. These could include:
- The estimate changes if the requirements change
- The timeframe changes if the requirements change
- Estimates have a great amount of uncertainty in them
- I insist on regular review sessions of the backlog, roadmap, and release schedule with the product owner and ES.
- I re-estimate proactively and regularly, and review the updated estimate with the ES and PO. Estimate using ranges or “confidence multipliers” to communicate uncertainty.
In my situation, Ken was the clear loser, but he was not the only loser. I lost out on referrals from a happy client, future work, and a good many nights’ sleep. Ron lost the product he’d promised to the board and customers. We all lost, and all of us share in the blame.
Direct communication with the executive sponsor and other stakeholders is too important to assume it is being taken care of, especially when you are a vendor. Partner with the PO to ensure the messages are being sent (and received) correctly, and maintain a direct relationship with the project sponsors to make certain they understand the ramifications of their decisions and the project’s status.
Now, if I can’t get them to agree to these things up front, I run away in the other direction—as fast as I can.
About the author
I get paid to coach newly minted technical managers, consultancy owners and startups.
I specialize in agile consulting and helping developers make the leap from Maker to Manager.
My clients quickly feel dramatically more confident and capable and start seeing better performance from themselves and their team within weeks.
User Comments
I see two more lessons that might be learned here:
1. The first mistake was "We brought Ken on site every two weeks...". The PO needs to be continuously plugged into the team, his reluctance to participate actively was a red flag.
2. The second mistake was trying to use a traditional contract on an Agile project, that's how Ron got off track on what was being built and what the costs should be.
Doug,
Thanks for the comment, both great points.
Thoughts...
1) Ken and I talked every day, and he was involved with each stand-up and on a daily basis. I should have pointed out that we were a remote team, and Ken lived 6 hours away, so we didn't have him on-site every week. He wasn't at all reluctant to particiate. I should have made that clearer.
2) Our contract was "schizophrenic" about scope, time, cost, but I didn't realize it until things got troublesome . It laid out two conflicting things:
a) We would work for 16 sprints on the project, with a static team size of Y, and $Z was due at the end of each approved sprint.
b) A particular list of "candidate features" would be delivered by the end of X sprints.
Fortunately, the client had issued us 15 signed "Certificate of Acceptance" documents, and paid 15 invoices, so they could not disavow knowledge that the scope had changed. In the end, that was what prevented this from turning into a "Fixed bid" contract (and saved us).
The contract was something I changed dramatically in future projects, and ensured that the client understood the ramifications of agile on the contract and payment schedule. You are correct that this communicted the wrong expectations to Ron.
I learned a lot of very difficult lessons, and I'm still sorting through them. Thank you for your comments!
-Marcus
What a timely post. I am dealing with a very similar situation -- PO who is a yes man and a ES who out of the blue has made everything a nightmare. Painful lesson and Marcus thanks for sharing your insights.
Ouch, Michael. I hope you can reach out to the ES to have direct relationship with him, and understand what he wants/needs. It's not about undermining the PO. It's about insuring that the real decision maker is as involved as possible, to prevent the "out of the blue" surprises. Good luck!