Agile-ish – Why Our Customers Love Us
By Rodney Guzman, CEO/Co-Founder/Owner at InterKnowlogy
Our Simple “Secret”
Most of our business is repeat business. Our customers come back to us again and again, not because of our rugged good looks, nor our super smart engineers (although they would argue that point). Our customers love us because we do what we say, which is deliver on time and on budget. How can we hope to achieve this when we fix price greenfield software projects, and without killing each other with change orders? Let me share our simple “secret” – it is all about managing your customers’ expectations.
Managing expectations? That’s it? This is no small task. From the first contact of our business development team to the final software delivery and deployment, we are constantly managing our customers’ expectations. Why does this matter? To many customers, custom software development is a mysterious and scary thing. To others, they have witnessed failed projects in the past, and they are not eager to put their job on the line with a perceived risky proposition of building a new custom solution.
To overcome initial concerns and fears, we employ a visualization process that takes what we have learned about our customer’s needs and produces a series of sketches and storyboards to echo that back. The customer sees that we understand them and are excited that what they want to achieve is possible. This is the start of a trusted partnership with our customers, which then begins the path to lessening their aversion to perceived risks. This is how we get our contracts signed.
A Visual Process
The visualization process is used to flesh out as many aspects of their application as possible. Pictures are important. If five people in your company read a document describing what we proposed to build, they would each have five different opinions of what we meant. Sketches and storyboards are the quickest and most effective way we have to communicate what we intend on building. This process is iterative and requires feedback from our customers at each step – this drives more clarity and a more refined visual definition of the application.
A customer quickly feels validated by this visualization process, and that their domain expertise has been effectively brought into the creation of their application. A customer sees immediately that they can be an active member of creating their own product, even if they are not a technologist. This is important as we move into the construction phase. Significant effort is spent in the visualization phase so that big decisions can be made early before software is written. Understanding what the feature will be, how it will interact, if there are dependencies on other features, and ultimately how complex that feature will be to implement is critical in planning how the features will be built.
During software construction, our customers remain closely engaged. They hear what will be in a sprint before it begins, and then see the result of that sprint. We build towards the visual definitions they have already approved, so all of those decisions already made are coming to life before their eyes. We enable our customers to make micro decisions on features wherever possible. This constant engagement is important because we want our customers to be on the same train we are on at all times. When software construction ends and we reach the final destination, the customer needs to understand how and why we ended up at that location. If they are not on the train and engaged in all the decisions made along the way, then it is impossible to manage their expectations. It is too easy to end up with an unhappy customer even if you built exactly what you told them you were going to do.
If a customer is not asking for new features during software construction then they are not doing their job. We want our customers to be engaged and excited about what we are building together and this often leads to new ideas when they start seeing the impossible come to life. How new feature ideas are handled is important to managing expectations.
We educate our customers that if they want to change something after construction has started, it is possible but there may be tradeoffs. Throughout a project, we work with our customers to define the features that will be built. We ensure we have agreement every step of the way while aligning these features to the original scope of effort – this is fixed price after all. As a new feature emerges, it is more likely that a feature the customer once thought important will no longer be. This gives us some flexibility to target pushing out the lower priority features for new ones. As long as we have not started work on a feature and that it does not have far reaching dependencies, a “horse trade” of similarly sized features can be done. No change orders needed, and the customer is getting exactly what they want. We aren’t saying that we don’t use change orders at all – it’s just not what we reach for first. Many times a lower priority feature can be complex and higher risk – working with customers to help them understand ways to simplify a feature or trade a feature for a more important one that they really want is part of what makes our customers love us.
It has taken us a few years to refine our Agile-ish process. This our recipe, and the ingredients are our employees. We would love to show you how we cook and what we have been cooking. To find out more please contact us at firstname.lastname@example.org.