We don’t change process; we change mindset.
I’ve been living in Dublin for the past month and heard from different people working in several companies that they modify the process. Sometimes adapting too much a methodology and losing its meaning.
In Brazil, we usually hear similar discussions. So I decided to write about a few experiences that I had to conclude that we don’t change process, we change mindset.
So you’re probably wondering “ok, I work in a company which our process is waterfall, and now we want to adjust to agile. Just grab a huge amount of post-its and split our work into sprints. Done, we are now agile.”
Well, not so simple. Agile is not a process. It is a way of thinking. And in our favor, we have methodologies and frameworks that help us to develop excellent softwares.
A few years ago, I worked in a company that has an extremely innovative owner losing his incredible ideas over and over due to flaw and long waterfall projects. I honestly loved that I had the opportunity to work there because I’ve learned so much with him and other colleagues. I also learned that if one can’t change the CEO’s mind about the process, so the company will get stuck there forever.
Ok so, we were watching this waterfall process over our amazing product ideas and getting nowhere. The owner was not the CEO, but he had the ideas. The CEO was a visionary man who understood the business and market. As Product Manager (at the time it was called product analyst), someone who was fresh and had the world to learn, I felt really bad when I had to land our projects to a project manager. I’m sure you know what happens next — long time no see. The designer and I started to study Scrum, UX, and how we could build user-centered products. That’s when I found Lean and fell in love — but this topic is for another article.
We were not prepared to follow that cascade mindset. Well, we did not want to because we saw a whole new world.
However, none of our new knowledge mattered much for waterfall minds. It was not because of the process, but people didn’t want to open their minds to new things, new techniques, which positively improve our process and products.
One time, we did a guerrilla research with our final users and presented a better solution based on the research’s feedback to our stakeholders, and I heard our project manager saying and I quote “I don’t like it. Because I don’t think users know what they want, I prefer the old way.”
Well, she didn’t believe that much could be done if we listen our customers. And this way of thinking is still out there, even higher positions as VP has it.
Turned out, a few months after I left this firm to a new one agile and also a different CEO took place, they became agile. You know, half-agile. But that’s a start.
On my last company — as a consulting one — we all had to manage our clients’ stakeholders, also we had to teach them how to work with an agile consulting.
We essentially use Scrum as framework and other methodologies to complete our process. We had PM, SM (agile coach) and dev team working for the same purpose. But our clients, few were becoming digitals and others were still waterfall but wanted an agile consulting to innovate their process and have better products.
One of my clients decided to shift their process into agile, splitting their teams into different squads, starting two weeks sprint, planning, retro… they have this new colorful office with post-its everywhere and motivating quotes on balloons. They’ve become digital and agile.
(It’s impressive when a company realizes that they have to do something to pursue better products and to be more competitive in their market.)
So far, so good, right? But again, we don’t change process, we change mindset. And that wasn’t happening there.
Their squads had no autonomy to improve (or even sometimes to think) because the higher staff, like directors, managers, VP… were micromanaging the squads’ every step.
They have weekly meetings to discuss each team’s backlog, roadmaps, what they’re doing now, then and later, besides the scrum ceremonies and other meetings that could just be an email.
Sometimes we — as consultants — performed workshops and talks to teach them how to be agile, how to plan and organize quality ceremonies, product discovery/inception. How to have the team’s autonomy. For example, refining is a good practice. Most of the time, it is conducted by PM. It is not an official Scrum ceremony, but it helps getting you to keep walking towards the right path. In this specific case, the client’s Product Managers (and the teams) had no voice, and they rarely were able to achieve the refining objective. It was not the process fault, as I said, this is a good practice. However, the stakeholders’ mind was in a different state, they want it all, they want dates, and they want to micromanager.
When our team started there, we had our way to play — besides the workshops and talks, we also had squads there. This client became amazed about how we worked. Product discovery, roadmap, release plans, team autonomy, team as owner… just a little of our daily work begun to shape their mindset. But even though there was still too much work to get where they want to.
Well, not everyone’s mind was willing to renovate so quickly. Can’t tell much about the project, but the VP wanted this feature that, after many researchers, wasn’t going to bring value to the product. He said, and I quote, “Users don’t know what they want. I know what they want.” Does it sound familiar to you?
He had this vast market experience, besides the essential knowledge that he didn’t want to have.
Alongside these sad stories, I had another client that once said in a room full of higher stakeholders, and I quote, “We’re considering everything here, it’s not time. Let’s think MVP guys.” And there was a director who stood for less is more.
So, it is not only about the process. But it is all about the way people think, which mindset one is willing to follow and be the transformation. We heard a lot the phrase “don’t change a winning team.” Is it winning or people just got too lazy to be better? Or just got comfortable and accommodated? If a company wants to adapt and shape a framework, like Scrum or XP, this is fine, not a big deal. It’s hard to follow it by the book; we all know that.
Well, it is good to at least try to modify as less as necessary, because it does not matter how many adjustments and meetings you add on it, if your people still think inside the box.
That’s it. I hope you have enjoyed my article. And don’t forget, if you’re in any similar situation than I described, start with the minds.
Let me know your thoughts :)
(Please notice that I’m not native in English and I apologize for mistakes)
