(image by peminumkopi)
I quit one of my biggest clients last week.
For almost 2 years, it has been a major part of my professional career. You can imagine it was hard to say goodbye after such a long period.
So why did I decide to leave?
Number one reason is that I started to feel settled.
This is my biggest fear, getting so used to the job that it becomes a routine. I’ve seen this happening to former colleagues of mine. Sure they knew everything about the company, its politics, it’s business rules, it’s history… They felt in control. But then suddenly the company started a big reorganization, and their world instantly looked different. While they used to be experts in their domain, they had now become legacy, standing in the way of the new business processes.
From that day on I decided that I would never let that happen to myself.
When I experience one week without (healthy) stress, I would force myself to change. Maybe inside the company, maybe outside. That’s why I’m still happy to work as a consultant. I get to switch projects once in a while, meet new people and face new challenges. Basically, as long as I’m learning, things are fine. When I’m not, it’s time to do something about it.
I thought it would be fun to share my view of the past 2 years in a small personal retrospective. I’m sure some of my former colleagues will read stuff they didn’t know about.
My 1st week was very hectic. I remember I first went to the SDC conference before starting at the company later that week. I was tired of travelling and the stress of public speaking, but the friendly atmosphere at the office made it much more bearable. As with all new projects, I started to dig into the business domain and local terminology which were quite new to me at the time. I had never worked in the recruiting business before.
It soon became clear to me that this client had an extremely ambitious vision. The entire business model was turned around to provide better value to its customers. At the same time, the entire IT infrastructure had to be modernized to be able to support the new business processes.
I entered in what was later seen as the kick-off project of this change program. Lucky for me, the project was still starting up.
Since I was hired for my Agile/Scrum experience, I unleashed my knowledge to the team. With wild enthusiasm I was confident we could become a great agile team. Things did change. Not at the speed I hoped for, but we became a closer group and started to get into the cadence of our 2-weekly sprints.
The project entered its final weeks, and things started to heat up. It was almost time to release, but there were still too many bugs and missing features.
As a result, discussions got more intense. In my opinion because I wanted to go forward full speed ahead, while some members of the team just didn’t care. I learned later that the organization actually drove this kind of behaviour.
Our CIO who was, and still is driving the vision, helped the team and the product owner to get out of the deadlock. One of his biggest capacities is that he can slice projects into releases like no other. He can spot options which others will never find. I learned a lot about release planning from him. So instead of dragging on until we could finally release the whole thing, we released a 1st version and updated it 2 times later. While I thought quality would delay this project in the classical sense, it became a success by applying aggressive release planning.
If I look back at it now, we never had that energy and motivation again. I haven’t found a reason yet. Did it take too much of the team? I ‘m not sure. Personally, I felt pretty confident for the next project.
At that time we had already split up into 2 project teams. While one team was supporting the freshly released application, the other team was building a brand new customer website. But since this was an architectural renewal, we had to deal with a lot of legacy and synchronization. What struck me most was the big variability during this project. We tried different methods of planning & measuring, but never really got it under control.
This was a painful project, from a PM perspective. But again, we managed to release a pretty decent first version of the website and gradually finished the remaining details. From a team member perspective, this was a project to be really proud of. A new fancy website with lots of visitors every day. The shiny access gate to the company!
Meanwhile the second team started a 3rd project, which got highest priority from our stakeholders. A couple of new people came into the picture, and we continued on our way of working. Many ‘Agile’ practices were present, but with less and less enthusiasm.
It became harder to keep the business stakeholders closely involved, since we seemed to slip from a product view to a technical view. This made it hard for them to understand what we were discussing during planning meetings and daily standups. Demos were of fewer interest to them because of the technical angle. As a result, feedback got delayed and the gap between what was planned and what was delivered became bigger. But again we managed to successfully release the system.
We came to a turning point. Or we could pull our act together and try to move back to the agile core, or we moved to a more classical phased gate approach.
The 2nd option was chosen with best intentions. I was not disappointed because we knew we needed to try something different. After almost 2 years, it became clear that the organization was not ready to embrace agile and get full use out of it. In my opinion this is in many cases the root cause of why an agile adoption doesn’t sustain.
I loved this customer so much that I was willing to give it a try.
But one of my biggest fears started to form. The start of the next project got delayed because it first had to be analyzed to a large degree. However, because of the rapid changing business, it became impossible to pin down the requirements in that amount of detail. One week, we felt like we were almost finished. The other week we were back off to zero.
At the same time, the development team was waiting, eager to get started. So they kept busy cleaning up their stuff, doing technical tasks, until they got tired of it and the atmosphere started to change. A classical decision was made to add more analysts to speed up the requirements gathering. Off course this resulted in even more discussions and less progress.
This is when I realized that I had played my part and should leave it to others.
It was a tough decision to make, but a necessary one. Although I’m going to miss my ex-colleagues, I’m also looking forward to learn new things, meet new people and most importantly have healthy stress again.
Many thanks to all! I’m sure you will release many more fine applications and I hope together you will find a process that fits the organization. Who knows, we might meet each other at a conference where you’re presenting an experience report.
Since the beginning of the year I started my own business. You can now hire me as an independent consultant. Keep an eye on this website. Things are going to change!
(image by -eko-)