I am consulting with a client who outsourced software development for a new app. As her acting CTO, I have good insight into this relationship and the work they are doing. Let me start by saying, I am shocked by how poorly this vendor treats us. Our negative experience working with them has reminded me of the principle “treat others the way you want to be treated.”
The bad news is how difficult this experience has been. The good news is that it prompted me to write about how we should treat our clients, and frankly, how clients want to be treated in return. Whether you provide software services, cyber services, or plumbing services, I think you can relate to the following principles:
- Set clear expectations – If you are a software shop and you say that you do Agile development, then explain what your definition of Agile is. Clearly explain your process, especially where and how you will engage the client, so they know what to expect (and what you expect from them in return). If you say you’re an Agile shop, then it should be pretty close to the Agile Manifesto. It most certainly should involve the customer/product owner setting priorities, having short sprints/delivery cycles, and frequent feedback/retrospectives. The main objective is to get feedback from the client early and often and adjust frequently. EXPLAIN YOUR PROCESS.
- Communicate frequently, both good and bad – It’s always easy to communicate good news. “Hey, we’re ahead of schedule,” or “That went smoother than we thought it might.” But it’s crucial to deliver the not-so-great news. “It didn’t go as easily as we expected,” or “We just lost our senior developer.” When we have a problem, we all think that we can hide it and fix it without the client ever knowing. That might work some of the time, but your team knows what you did, and you just caused them to lie about what they got done during the sprint.
Meet with your client frequently. We recommend weekly. If you have two-week sprints, each week can alternate between a user story/requirements grooming session and a post-sprint retrospective. Use your grooming session to build rapport and understanding with your client and use the retrospective to share what you got done. Be open. Share what you planned to get done vs. what actually got done and have an open dialog about why.
Maybe you were too optimistic when you estimated the story points. Maybe you and your client didn’t do a great job grooming a particularly complex requirement. Maybe your testers uncovered a bunch of unexpected bugs. That’s a good thing. You’d rather find them now than later. Maybe two of your team members got sick. Who knows? But the point is to work together, develop lessons learned, learn the lessons, improve, and avoid repeating the same mistakes over and over. SHARE OPENLY.
- Set and meet intermediate milestones – If you are running an Agile shop, this is easy. Set a sprint schedule and hold to it. Most organizations we work with use two-week sprints, and a critical key to success is to hold these dates rock solid. Don’t let the work cause you to slide the date! Another critical key to success is assuring you FULLY complete the work in the sprint. Not all the work you planned needs to be completed, but the work you say got done, must actually be done.
To achieve this, we recommend you set an immutable, unbreakable definition for Done-Done – This definition cannot be gray because if it is, then … Every feature. In every sprint. Is going to be questioned. Forever. Make it easy and clear to your team, your client, and your stakeholders. For us, the ideal definition of “Done-Done” is that you completed both the development and testing for a feature. Ideally, all bugs are fixed, but at a minimum, all critical and majors are corrected, and any minors or trivials are documented in Jira. DO NOT EQUIVOCATE.
- Ensure the customer always has full control of their assets – Go through the process in the beginning of having your customer setup and be the administrator of GitHub, servers, database, and all other tools. Even though they might not have this skillset, you want them to know that they always have full control of everything they envisioned and paid for. Empower them so they can go elsewhere if they want. If you are open and honest and constantly improving, they won’t want to.NEVER HOLD THE CODE AS RANSOM.
- Report progress against a plan – Customers rightfully want to know how long the project will take and how much it will cost. Build a plan and size the project up front. Show them your past productivity on similar projects so they can understand when you think it will be done. Ideally, share cost, schedule, and quality metrics vs. plan with your customer at each retrospective. Track and report your velocity every sprint so you can give them (and your team) confidence in hitting the deadlines. Are you delivering the expected story points/sprint? Are you finding more or less bugs each sprint? How much effort is going toward new features vs. bug fixes? Does the backlog estimate align with your velocity and meet your expected delivery date and budget? Do you have a management reserve built into your estimates? Collecting and communicating this information allows you to improve and provide your customers with ever-growing confidence in you. YOU CAN’T MANAGE WHAT YOU DON’T MEASURE.
- Be honest and kind – If you mess up, own it, and fix it. Don’t try to hide things because it’s always a bad situation when the truth comes out. I think we all learned that lesson in kindergarten. And don’t charge the customer for your mistakes, training, or lack of experience. Be positive and kind in your communications even if you don’t agree with your customer. Explain why your opinion is different and have a dialog. Put yourself on the same side of the table as the customer and realize that you are both trying to successfully deliver this app. I know there are some less than reputable companies, but I think the vast majority of software shops want to deliver successful apps and want happy client references. TREAT YOUR CLIENT THE WAY YOU WANT TO BE TREATED.
I wrote this talking directly to software development companies, but it’s easy enough to flip the script and read these as the expectations you should have when buying software services. If you are in the market for a software development partner or have found yourself in a frustrating situation with one who isn’t performing where you want them to be, ask yourself how you want to be treated. Then, use your answers and the guide above to find a qualified partner who not only aligns with your needs as a company and client, but as a person.
We’d love to hear from you! Do these resonate with you? What have your experiences been? Please share your personal experiences so we can all learn and improve.
Jeff Van Fleet
President & CEO, Lighthouse Technologies, Inc.
After almost 20 years of developing and managing complex software/hardware systems for both commercial and Department of Defense (DoD) applications, Jeff founded Lighthouse Technologies in 2000 with the aim of delivering software systems on-time, on-budget, and on-quality while simultaneously building an intentional culture of caring, growing, and improving – A “Culture of We”.
.png){kind=logo}
