The fourth of the twelve principles behind the Agile Manifesto states that "Business people and developers must work together daily throughout the project." But what if they don't? An unresponsive business partner can turn an otherwise promising agile software development project into an utter disaster. That happened to me, and here's what I did about it.
The project owner was a new client who wanted me to write desktop and web applications and design a database to improve the way his business worked, paving the way for an IPO.
At the beginning of the project, I drove an hour and a half to see the project owner and spent a full day there. He came across as very bright and had some good ideas. We shook hands, I outlined how I would solve each challenge he faced, and over the next week we came to terms on a software-for-equity contract that I felt minimized risk on both sides.
I had previous experience with enthusiastic clients who were even more geographically remote than this one, so I wasn't too worried about the distance between us. I expected next-day feedback to my biweekly code-drops by phone, and I expected that we'd share the travel burden equally. I was pretty sure I had made that abundantly clear and that he'd agreed to it verbally.
Early warning signs
After the first sprint, I posted a build for the client and his employees to try, then emailed them about what they should test and where I had questions, and took a day to work on something else while I waited for the phone to ring. I expected some excited initial feedback or at the very least an email commenting on the design and the features I had implemented so far.
Crickets.
The following day I called him. No, he hadn't had a chance to look at it or even delegate the task to an employee. He trusted me, he said, and asked me to keep working on the project. A warning bell began to ring in my head. I ignored it.
After the second sprint, I received the same non-response, and the warning bells grew louder.
After the third sprint with no response, I told the client that I couldn't proceed without feedback. "Why don't you come down here and go over it with me?" he said. "I'll buy you lunch. Is sushi OK?"
I drove down, and as we went over the current build, it became clear that he had never bothered to look at it. Fortunately, he liked what he saw; he had concrete suggestions for the next few sprints, and the sushi was pretty good. I was reassured.
I had started with easiest of his five projects, and after a few more sprints he accepted the software, which made me feel better about the partnership. I moved on to the next project. The unresponsive behavior persisted, however, and he never came to me with feedback.
Heading for disaster
By the third project, things began falling apart. I finally heard back from the client, and suddenly nothing was right with my design. Unfortunately, he hadn't said a word about any of these concerns until we were four sprints into the project. We could have avoided this ugliness if he had looked at an early sprint and made suggestions about the changes he wanted while they were still easy to implement. Because he couldn't find the time to fulfill his role as the project's business owner—a crucial one in agile software development—all this critical feedback came at the end.
I fixed the project to his satisfaction, but I had a bad feeling about the way things were going. I persevered, and sure enough, midway through the next phase things broke down between us. It became clear that he never had any intention of honoring the contract we'd hammered out, and that he was doing everything he could to weasel out of his own commitments.
My choices weren't good: I could sue or walk. The client had a law degree, and a lawsuit pretty much guaranteed I would incur large legal expenses while he did his own legal work for free. So I walked. I didn't get paid, but I immediately felt much happier.
Shoulda, woulda, coulda
What's the lesson here? I should have declined as soon as I saw that the proposal was "software for equity," but the contract lured me into a false sense of security. And I should have stopped work the first time he blew off his obligation to review the work in progress, simply on principle.
But I didn't.
In hindsight, I may have been dealing with a sociopath or something like one. But sociopathic business executives can be very charming and smart, so it isn't easy to spot them.
Take my experience as a warning the next time you're searching for an agile software development project and you hear the equivalent of "I have a great idea, and I just need you to develop the software." The correct response comes from Monty Python and the Holy Grail: "Run away! Run away!"
Keep learning
Take a deep dive into the state of quality with TechBeacon's Guide. Plus: Download the free World Quality Report 2022-23.
Put performance engineering into practice with these top 10 performance engineering techniques that work.
Find to tools you need with TechBeacon's Buyer's Guide for Selecting Software Test Automation Tools.
Discover best practices for reducing software defects with TechBeacon's Guide.
- Take your testing career to the next level. TechBeacon's Careers Topic Center provides expert advice to prepare you for your next move.
