One article about behaviors that impact Processes or Frameworks
That was a polite title for “Hmmm…it is maybe your fault.”
Brace yourselves, this will be a tough conversation! After almost 20 years working with IT I went through several different Frameworks and Processes for project execution or software development: Waterfall, Agile, Scrum, SAFe, “Go Horse”, Product Model, Kanban, you name it. I also went through many transitions from one to another and identified a pattern on it, leading to a loop of behaviors:
- When working through a given Process/Framework A, I see many people complaining about it, but doing nothing to change it or even make it better.
- An executive decision is made that we would start a new given Process B, and many people (usually the same ones in the first step) complain about the changes.
- Once we start stabilizing the new given Process B, for a small period of time, people will love it at the beginning, and completely hate the previous given Process A. Here are some classical statements said: “I swear I will do XYZ if we get back to Process A!” or “I hope we are not stupid to get back to Process A!”.
- Once the honeymoon ends (it is usually a short period), the same mistakes done before pop up, and the loop restarts.
A wise man once said: “The definition of insanity is doing the same thing over and over again and expecting different results.”
At the end of the day, it doesn’t matter which Process or Framework we are working through if we are making the same wrong decisions. Those mistakes are what I would like to speak about in this article.
Let’s be honest, any process or framework ever created in the industry was made to succeed. It is usually done by a group of notable people, with different mindsets, expertise, and experiences, to address issues and concerns the market was facing at a given moment. And I don’t believe any of those people were thinking “Hmm, let’s create this framework, make it popular so that many companies would use it and fail!”.
So, sorry to say it, but it may be your fault if you are struggling with a given process. Either because you are using it wrong or the process wasn’t made to address your issues. Or, most likely, your company has cultural vicious and behaviors that go beyond any process, which means that regardless of which process you are using, you will continue to fail.
Here are some big mistakes I see being done and how it could affect the new process or the transition:
“Adjust” the process so we could sneak in roles and responsibilities that shouldn’t exist in the “new world”
When we transition from one process to another, it’s very common to identify roles and responsibilities that no longer fit within the new process. A good example is when we have a very bureaucratic release management process (very common when running Waterfall) and want to transition to a more fast delivery mode like Agile/SAFe/Product. It’s a mistake if we keep the same release management process as it was, making the delivery process in the “new world” as slow and painful as before.
Another common issue is not preparing the team for the new process. For example, you have many Business Analysts that are very good at requirements gathering, and suddenly they need to be Product Owners or Product Managers, without the proper preparation. The BAs tend to become POs/PMs later but it’s a mistake to think they will naturally fit that role, just because of the requirements gathering aspect of both roles. A Product Manager has many other responsibilities and skills that a BA not necessarily would have.
Focus on deliveries rather than the user needs
If you follow my articles you probably notice I get back to this topic very often. That’s because I see this mistake very often as well. We shouldn’t be focusing on getting rid of a particular feature and look for the next one just as a “check in the box” purpose, but rather making sure that the functionality we are working on will actually benefit our customers and really enhance our product for good.
If it is your first time here, I invite you to take a look at this article:
Define the scope, delivery date, and budget before closing the solution
“I want a rocket powerful enough to land Mars and need that in 6 months. Our VP is asking.”
The nutshell of this is: try, as harder as you can, to NOT define a date or the budget of your delivery WITHOUT having the solution defined. If you do that, YOU WILL deliver a bad solution. There’s no magic, it’s basic math. If you want to deliver a solution that would normally cost $1M and a 1-year time frame, but someone is asking to do it in 6 months costing $500k, you will reduce the quality of your work by 50%, if the scope is not reduced (it never is).
The problem with this approach is that once you deploy that solution and users start to onboard to it, everybody will forget the timelines and budget had shrunk. And it’s going to be your fault because you and your Product Team delivered that horrible solution.
Centralize the decisions
One important thing we should foster in the organizations is empowerment. Empowerment reduces bureaucracy and the time to react to a change. We want our Teams to be empowered to make more decisions and leave only the really tough ones to the leadership. If we invert that logic, we will create a bottleneck, which is another big mistake. Bottlenecks lead to frequent status meetings, command-control type of operation, and a lot of frustrated and unhappy people.
Ensure that the vision and strategy are always crystal clear to your team, and let them organize themselves on how they will tactically operate and deliver, aligned to that vision and strategy. Periodically acknowledge the deliveries (maybe monthly or quarterly) and help to adjust the course whenever needed.
If they fail, identify the root cause and fix it punctually. But don’t get back to the previous command-control state at the first sign of failure. Failures are part of the learning process.
Don’t care about Feedbacks
Listen. Just listen. Listen to what people are saying, what they are explicitly telling you. But also listen to their emotions, what they are NOT telling you. If you have one single person complaining, maybe the problem is with that person alone. But if you have more than one, that is maybe a trend. Regardless of it, listen. You are a leader, your main job is to listen. Just listen.
Define unhelpful metrics
We are currently in the “Age of Data”. Numbers and Facts are more than helpful, are mandatory. They are crucial for organizations to make the right decisions. And more than that, data is really what will divide the good from bad Product Managers, really soon. So the problem is not the metrics, is HOW you use it, and HOW you define it.
It’s very common with the transition that a number of metrics are defined so it shows how the team is progressing towards the goal(s). However, it also very common that people have no idea how to measure it or what that metric is made for. Before defining a Metric, make sure you have complete clarity of what you want to measure. Then make sure you have it clear across the organization about what you measuring. If people don’t see value in it, it’s already a waste of time and it will die even before the implementation.
Processes and Frameworks are something we can change from one day to another. Culture however it’s not that easy. Culture is a separate entity in our organization and has its own life, it’s harder to change. We need to look deep into our organizations to find behaviors that could impact our new process adoption. It may vary from bad leadership decisions to lack of empowerment to our teams.
I invite you to do an internal assessment on what behavior you are making and then think about what you can do to change. I also invite you to have a conversation with your leaders about one of the behaviors above, if you believe it is something you could do better. If at all you don’t feel comfortable yet for difficult conversations, that’s fine. Just don’t be part of that vicious loop of behaviors I have shown in the beginning, it would help a lot already.