As someone who’s done projects for over 30 organizations in my career, I’ve run across a wide variety of development methodologies. Most folks know by now that when an organization says they are “doing SCRUM” or “doing Agile” what they really mean, is that they are cherry picking practices that work for them, and avoiding those that are uncomfortable.
As a consultant, it is often not possible to help organizations with their development methodology without some initial wins. Who would trust their guitar technician to restore their 1960s Martin without first making sure the person can do basic repairs? It is during this initial first effort, whether as a technical lead at a product company or a consultant where we have an opportunity to lay the groundwork for future development process improvements. This post is about some key interpersonal skills that when used well on even small projects, will hopefully help you win the trust needed to move on to higher value process improvements.
If we want the best chance of organizations we do work for getting the most value from us, it starts with establishing an authentic relationship. This means from your initial conversations all the way through the conclusion of the project, you should get to know the people you will work with on a personal level. If you don’t show any interest in people outside of the work, it’s less likely that they will come to you when something’s really bothering them. And it is often personality conflicts, or issues in a person’s life, that block progress more than any technical hurdle.
Setting Expectations for Change
In 20 years of software development, I have yet to see a single SCRUM team get into a sprint and not have changes be necessary. The User Acceptance Criteria may have had some holes. The test plan wasn’t robust enough. The team didn’t think about compliance regulations. The list of opportunities for this to come up is endless.
Rather than bringing this up for the first time as it happens, I communicate at least once a week, in front of my entire team, a reminder that we as a team will run into issues. I remind them that we are humans, and humans can’t be expected to remember everything needed about a system through conversations.
I’ve spent heaps of a client’s money that insisted on a fixed bid design before starting development (no, I was not involved in the statement of work on this one), only to find that when engineering went to build it, 30% of the feature set that the product manager thought was part of the “minimum viable product” was still missing. This one’s solved by releasing early and often, but that’s another topic.
The key takeaway here is to be “real” with your client or immediate supervisor, and not leave them with rose colored glasses, thinking the process on your team will eliminate having to deal with changes.
Establishing Your Role
Whether you are a consultant or in a permanent position at an organization, how you work with those who you report to has a huge impact on the success of projects. In Peter Block’s famous book Flawless Consulting he outlines three roles in which one can interact with their “customer” on a project:
- Expert: The expert swoops in, does something for the client, and then vanishes.
- Pair of hands: The pair of hands mindlessly follows the client’s instructions regardless of whether they actually make sense.
- Collaborator: The collaborator partners with the client to define the problem and create and implement the solution.
You want to get to the collaborative style, and start there if possible. I usually get an idea of how well this will go by bringing it up at the beginning of the project. Educate your client or immediate supervisor on these three roles and help them to understand the value of collaboration. If you get pushback, be prepared that what they probably want is an expert or a pair of hands. If you allow yourself to be relegated to this role, it greatly diminishes your impact.
Establishing Change Management Procedures
When changes do arise, as a technical person it can be tempting to bark “nothing new gets added in the sprint!” and I’ve certainly been there. In reality, new work often has to be added to a sprint to complete scheduled work within it. It is here where you can show leadership, helping the team to make the decision on when to add the new work and get it done in the current sprint, and when to push it to the next one. It is essential to establish change management procedures at the beginning of a project when other leaders at the organization are under the least pressure and most willing to hear advice on how to proceed.
When you make a mistake, communicate it to those it will impact as soon as possible. But this too should be taken with a grain of salt. There is a right way to admit a mistake, where it is simply stated along with some possible ways forward, and a wrong way. The wrong ways I’ve seen this done (and done it myself!) is to admit the mistake, but either blame it on someone else, or to use positioning statements to trivialize the mistake. The first one is a problem because unless you are very careful, you can leave the dependent party feeling thrown under a bus. The second one is a problem because it leaves your client or immediate supervisor with a feeling in the back of their mind that you will not want to let them know about your mistakes. Both are bad for the relationship.
Positively Reinforcing Behavior Changes
When other people on your team begin to change their behavior to follow a process better, be sure to thank them publicly. If you are a consultant, thank people in front of their peers. If you are an employee, thank them in the most public way possible. This doesn’t have to be some big schmooze fest – just give credit where it is due.
Increasing the Regularity of Celebrating Progress
Insist that your team celebrates their releases in some way. If releasing multiple times a day, get together at least once a week! That’s one great team that deserves to celebrate progress! When people are reminded that they are doing a good job by getting out of the office and spending some time together (on the organization’s dime) it helps keep morale high as inevitable challenges are encountered. Especially if you are a consultant or someone new to the team, doing this will help other people accept you into their inner circle. This one is more important than you might think.
Have you used some of these approaches in establishing trust before making big changes with your company or clients? Leave me feedback below! Thanks for reading.