Process is Easy; People are Hard
I see a lot of articles decrying Scrum, Agile, SAFe, LeSS, Kanban, XP, or various aspects of them. Some call for the return to Waterfall. Some pit one against the other, pushing their experience as “the better way.”
It’s common — and easy — to point fingers at the process: “you’re doing it wrong,” “do it this way,” “have you tried this new practice? It’ll solve all your problems.” A project fails, so the blame is partly — if not entirely — due to the process. Or, the process was fine, but it must have been executed incorrectly.
The reality is that it’s not about the process: process is easy. It’s about the people: they’re hard.
Surprisingly, the process should be there to enable, support, and improve the capabilities of people. In a way, it’s supposed to free them to focus on the “real” work. Also surprisingly, it doesn’t. For some, it feels like running along the beach, the sand sinking beneath their feet, the waves beating against their legs, each step is a labor, pushing through the wind, the sand, and the water. For others, it’s someone looking over your shoulder constantly, the sense of presence, the awkwardness of a watched pot of water waiting to boil.
When Quality Becomes a Lack of Trust
Organizations typically introduce a more rigid process — a more well-defined, metrics-based, policy-driven process — in order to improve quality. This makes sense, since that’s the real purpose of a software development methodology.
When building software, you have to have some form of requirements to get started. You have to “write” the software, and if you don’t release or publish it, it never happened. You can’t “build” software without doing those things. Everything that’s added, theoretically, is designed to improve the quality of the software. We’re human, and we make mistakes, so we introduce repeatable processes so that we make fewer mistakes (and when we make them, we can quickly identify and fix them).
What gets mixed up in the goal of improving quality is the introduction of a relationship. Management — usually upper-management — wants to ensure that their product meets a certain amount of quality in order to be viable as a business. Depending on the business, certain types of quality failures are acceptable; whereas, some types are not, due to customer impacts, legal issues, or even safety concerns. Process is introduced to meet that quality threshold. What’s also introduced: a lack of trust.
Most everyone admits to making mistakes. If we’re professional about it, we own up, attempt to correct it, and try not to do it again, especially if there are repercussions. However, when someone else is doing the work for you, for some reason, you’re less trusting of their professionalism, capabilities, and motivations.
With that lack of trust comes additional processes. With that relationship — I’m paying for it; you’re building it — comes anxiety of failure. If an electrician makes a mistake that’s not easily visible, the owner of the house ultimately pays the price when the house burns to the ground years later due to faulty wiring. I’ve caught myself watching the electrician as they work on my house, I’m embarrassed to say.
Build Relationships, Not Processes
When engineers continue to make mistakes, when the site keeps going down, when the system gets hacked, when features don’t get delivered quickly enough, look at what can be built within the relationship rather than sprinting to add process.
Within a professional relationship, education, training, mentorship, and understanding will go far in solving many of the quality issues that tend to plague organizations. I’ve seen added processes drive engineers to leave and worse — such as reducing their engagement.
That doesn’t mean that adding processes should never be done. However, they should be done as part of building the relationship, rather than in spite of it.
“We don’t trust you to <do this thing> without causing an issue, so we’re going to introduce these additional processes to make sure you don’t.”
Most organizations would never come out and say the above, but they do it often — they just say it in a different way. Too often.
A relationship represents the respective perceptions, expectations, and commitment between two parties. An example of a perception might be, “do you really care about my wellbeing?” It might also be, “I trust you to get the job done.” An example of an expectation might be, “you pay me for my time.” It could also be, “I expect you to be here until 6:00 pm.” For commitment, it might be something like, “I’ll work late because this is important.” Or, it might be, “If you take this time off, we’ll be right here when you get back.”
Building a relationship is strengthening those areas between two parties, while damaging it is reducing the impacts those areas have on each party. Sometimes it’s measured as engagement: let’s measure how well our employees like their jobs. However, I’ve never heard of measuring the engagement of an organization to its people.
But, Process…
The goal of building relationships first is not to ignore the process. Good methodologies can fail due to poor relationships, and poor methodologies can succeed with great relationships. The goal of building the relationship is to customize the process around the people. This means that, when you get down into the nitty-gritty of software development methodologies, the best ones are customized to the organization (and even the team-level), driven by the participants, and based upon the relationships involved.
Let’s look at some examples:
An engineer causes a site-wide outage. The root cause analysis showed that the engineer missed a test that should have been done before the release.
What are your options? You could fire the engineer. You could introduce a checklist that has to be signed off and approved. You could sit down with the engineer and understand why it happened and see if there’s some training that needs to be done or if they have some suggestions.
There are lots of options, and many of them would work to prevent the issue from happening again. The real question is if the option you chose negatively or positively affects the relationship with the engineer (and other engineers, as they will see how it’s handled, so it affects their relationship, as well).
Teams aren’t delivering on their sprint commitments very often. In fact, delivery dates are frequently missed.
What are your options? You could introduce metrics and goals around those metrics to more consistently deliver on commitments. Or, you could engage in discussions with the teams to see what’s happening and introduce training on estimation techniques.
At one organization, a goal of a “say/do metric” (the percentage of time a team met their commitments) was set at 80%. They felt it was an aggressive goal, but ended up being more concerned with teams that hit close to 100% than they were with those that weren’t close, as they felt that they “must be cheating.” The relationship was obviously hurt.
It’s found out than some engineers are found playing video games during work hours.
What are your options? You could ignore it. You could introduce timesheets to track their time. You could also join in and have company-wide, lunch-time gaming sessions.
At one organization, one team activity was to go play VR at a local gaming company. The relationship improved.
Conclusion
Defining and changing a software development methodology can be easy. However, merely adding new processes to a methodology may not provide the right kind of solution. Looking for ways to build better relationships with teams and their engineers is the right first step, even if the ultimate results are the same: a new process.
This is because process is, basically, easy; people, on the other hand, are not.
