A bit more than 4 years ago I decided to kill my startup on which I wrote a postmortem (I think it is part of the grieving process, a lot of founders do that). At that time I remember my emotions were not so positive. I was feeling ashamed, small, and hopeless.
After a few months, I decided to pursue the consultant path and help other companies to not make the same mistakes. Or as I like to think, to set them up for success.
Since then, I had the opportunity to work with companies in different markets and of different sizes, but mostly, companies that were in need to change and change fast.
This is my attempt to show the positive side of it, the huge learnings that would have taken me many years to get by working for companies. If you are trying to create your company or help your team, I hope these will resonate with you.
In this post (and more to come), I will try to explain what happened to one of our customers, what we saw there, and how we tackled it. Symptoms are:
When a feature needed to be implemented, the request always came from the CTO or sales. The project manager responsible for the product never spoke to the customer before, she was just proxying work to be done without understanding the reasons behind.
When the team had to fix a production issue, they had to talk to customer support, they were not allowed to speak with the customer directly.
When asked to the team lead why they never spoke to the customer the answer was: We have a process here that makes it more efficient this way
Priority 1 bugs took the team a full day with 4 developers to find the problem and fix it and another half day to merge code back into one of the master branches. And it could only be done by one person.
We got called by their CTO saying that IT does not deliver and they are the bottleneck of the organization.
A normal standup would be the support team telling the development team how they cannot deliver any quality work and everything they do is wrong.
The manager said that they don’t trust some people to do the work in front of everyone.
The team was constantly firefighting production issues or implementing the greatest next feature that would solve all the problems.
The team would say, we have no time to improve anything, because the business wants features, features, features
We have no time for tests
255 branches in version control. That is a true story, not only that they had weird naming for those branches like master-v2, master-lastest, master, master-dev, development, and a bunch of feature branches.
The question that triggers us is the most is. WHY? How come they don’t see this is way too complicated? Why don’t they delete all those unused branches?
For this specific customer, they had a clear vision and a direction and they just needed a bit of help to create an environment that would enable them to continue growing.
This is one of the problems we love to solve. You can tackle this from a lot of different angles and for this one we decided to start with so-called, IT being the bottleneck problem.
Change the environment around people, it will change the way they act and consequently will change the way how they think.
We gave a workshop about Trunk-based development, unit tests, continuous integration/delivery/deployment.
We asked the team to pick one of the 255 branches. All the other branches would be deleted forever. We also said that everyone had to commit all the time to the same branch, no more future branches.
Their reaction?
You are insane, this is the stupidest thing we ever heard
The next step was easy. We automated every commit to production 😙
Reaction?
You cannot do that, what if it breaks? we don’t have test coverage? how is the project manager approve a functionality? They were in total disbelief
It triggered their behavior to change, which is required to change the way how they work.
What we observed was, developers were now very careful to push changes afraid of breaking production. They become more curious to learn how to write tests.
They barely had merge conflicts because we deleted all those useless and confusing branches. And when they did have conflicts, they learned more and more that you should deliver continuously in small batches.
Their cognitive load became lower, they no longer needed to remember all those branches strategy they once agreed upon 🙌. Which created more space for them to improve their own way of working, have more slack, talk to customers, possibilities were endless 😝.
After 3 weeks, they asked themselves. Why did we use branches in the first place?
And the “business”, how did they react? That will be another post 😄. IT can be the bottleneck, but mostly is just a symptom of a bigger problem.
Wattbaan 1
Nieuwegein, 3439ML
+31 85 303 6248
info@fourscouts.nl
.jpg)