This is a guest post by Peter G. Walen.
How can you deliver the best possible work when the “process” you are supposed to follow does not help you? Can we deliver good work in spite of what we are mandated to do? When the “rules” are hindering us, can we make good things happen and aim to delight our customers?
Perfect organizations don’t have this issue. Everyone involved in making software — from requirements to design to development, testing, and delivery — has a say and their input is considered valuable and important. Most of us don’t work there.
Can we do good work using the official process? Can we do good work in spite of the process? I suspect the answer to both questions, based on my experience and discussions with others, is a resounding “Maybe.”
It doesn’t matter if the “official” process is being introduced as new or if it is something that has always existed but no one really paid attention. What does matter is building an understanding of how the process impacts the delivery of good quality software.
Before the beginning
Here is what I have done.
We can argue against the work model. We can raise all sorts of objections. Those arguments and objections often do not carry much weight if we have not actually attempted to engage with the work process. While we can relate experiences with similar process models and their results, we usually have a hard time getting management or leadership to understand what you saw the results to be.
Be calm. Avoid grand statements foretelling disaster and consider the intent behind the official process model. Look to find the reason why it was implemented or the emphasis on why it is being enforced when it wasn’t before.
What is happening that might not be so obvious? Consider the concerns, if not outright fear, the process is intended to address.
Initial “short term”
To begin, most organizations with mandated working models will resist the attempts of people to change them. Any opposition to the process, as defined, often results in a response to the effect that they need to be “given a chance.”
Try working with them. Meticulously follow the proscribed approach while taking notes on impact and progress along the way. Note what worked and what did not. Make sure the results noted go beyond the opinion and reflect objective evidence.
Taking great care to follow the new practice precisely as stated gives everyone a chance to see if it does, or does not work. When the product ends up with software problems or misses key dates, there are grounds for having discussions based on everyone’s experience.
Oftentimes the advocates of the official process will respond that the teams did something wrong. That they failed to achieve the objectives or had problems with their work because they did not follow the process closely enough or did not interpret the instructions correctly.
When this happens, a meaningful response is to have the advocates join the project teams and work closely with them, teaching and coaching them how these steps can be executed and how the goals can be achieved. A more common “solution” has the advocates walk through the process steps again, with the same main checkpoints outlined.
The former approach is rarely seen. The latter is far more common.
The problem, of course, is the theories that some models are based on do not hold-up to the reality of the project work. When models are derived from hypothetical concepts, they can show some interesting possibilities. Until they are tested and proven in actual working conditions, they remain unverified hypotheses, at best.
The fundamental question which must be addressed is this: Does the official process model help or hinder the ability to deliver good quality software that addresses specific needs?
Can we deliver this software in a timely manner following the process “to the letter” or does it need some tweaking along the way?
Changing tack without changing direction
Sailboats of any size cannot sail directly into the wind. If you want to go East, and the wind is coming from the East, you need to move “sort of East” – meaning you need to tack (or wear or jibe) – that means, you change direction slightly so the boat can take advantage of the wind. Sail for a given distance, then change direction. You will still be going “sort of East” but just a different path to get there.
You zig-zag toward your destination.
Along the way, you find small adjustments you can make for the situation you are in. You can improve your “trim” by shifting weight or changing the tension on the sails. In software projects, you can sometimes do similar things.
The stated process demands X, Y, and Z. In some circumstances, those can work just fine. For others, they might not help us reach the goal of delivering good quality software. In some cases, they may block that goal.
Sometimes you can demonstrate that doing X or Y or Z in the way the process model requires they be done will not improve the quality of work for your particular project. Will doing something that is similar to Z and does help project quality be close enough?
The ends are achieved and the “intent” of Z is achieved. How you got there might be slightly different than what the mandate is. The main objective is still achieved. We have delivered good quality software meeting the customer needs.
Once this has been demonstrated successfully, then perhaps a little shift for Y might be on order as well.
Keeping the project work going and delivering the best possible quality software is vital to the organization. Keeping the team in good spirits is vital to the quality of the work being done. If morale is suffering because of the work process model imposed on the team, this becomes a risk to the success of every project.
The spirit, not the letter
That challenge comes back to “following the process.” Make sure the team can show a solid, good-faith effort. Make sure the team can show success was not within reach in a way that would meet the needs the project is to address.
You can demonstrate the team was moving toward “the goal” while meeting the customer and the organization’s immediate needs. Learning along the way how they can improve their practices and maintain and improve the quality of the software.
Presenting these findings to leadership might shed light on what it is that the real purpose behind the process. It might reveal the need they were attempting to address by implementing the process model.
If they are open to various interpretations of the intent of the process model, and willing to allow some variation in the execution of the model, it is possible the various teams can address the spirit of the new model, if not the precisely documented steps.
It is possible that an open, fact-based discussion might result in a process model that meets the needs of leadership, management, and the teams doing the work. It takes an effort on both parts for this to be the case.
Keep the focus on the question of how the official process model helps or hinders the ability to deliver good quality software that addresses specific needs?
It takes a demonstrated effort to execute following the mandated process model for many advocates of many processes to understand the problems encountered. Everyone needs to be patient and listen less to the words and emotion. Instead, listen to the message around the concerns.
Making it work
In the end, there are some things most people can agree on. Success can be found anywhere, including the unlikeliest of places. For that to happen, everyone must be willing to be open and be willing to try and compromise a bit. If we can show some gains from the effort, most people will be willing to acknowledge that some improvements can be found.
There is usually a need for “managing up” as generally managing communication well can build trust. Without meaningful, open communication across the entire organization, any “work model” – old or new – will ultimately fail.
Success, for the individual, team, and organization, can come in time. It takes individuals and “teams” to work as a Team. They must work together and not as a collection of individuals. They must support each other, hold each other up, and hold each other accountable to contribute to the best of their abilities to team success.
For software organizations, this success is the delivery of high-quality products that delight customers. Without these things, not much else matters. The cool gimmicks and “motivational techniques” won’t result in success for anyone.
“The People” need to be able to work together and make “The Success” happen. The most meaningful measure of success is delivering quality software that solves customer needs.
Peter G. Walen has over 25 years of experience in software development, testing, and agile practices. He works hard to help teams understand how their software works and interacts with other software and the people using it. He is a member of the Agile Alliance, the Scrum Alliance and the American Society for Quality (ASQ) and an active participant in software meetups and frequent conference speaker.
