Happy days or just an illusion!
The initial days were spent in coming up with a detailed plan, dates, and milestones for the transformation journey. The manager in me was pretty convinced that with a detailed plan and with the team’s buy-in, anything could be achieved. There was no way I could be possibly wrong for I have done this multiple time before.
A vetted transformation plan, approved by the senior management and bought in by the team came into being – My very first mistake, my utter disregard of transformation as organic.
It was not just the teams but the entire system that rebelled and revolted.
Transformation requires people, teams, functional silos, business units, management, and support teams to move out of their comfort zone. Agile transformation cannot be mistaken for process transition – you cannot waterfall your way into Agile.
In Agile, servant leadership is the answer and the way forward!
Scrum was the chosen framework and somewhere during the planning and designing phase of transformation, framework compliance became the goal. I had completely lost track of the motivation behind the transformation, I had created metrics that measured framework compliance rather than the ability to change. So, we did reach a stage where we could tick all the checkboxes from the framework standpoint but I had a team that was bogged down by the process, leading a life that was more stressful than before and importantly unable to deliver anything meaningful and regressing on quality.
One peculiar experience that I had was the teams coming up to me frequently and telling me about the various dysfunctions in the system that is slowing or stopping them from making progress. They then were expecting me to handle it but the manager in me wasn’t convinced. It was only later that I realized that all the agile frameworks have this inherent capability of surfacing the systemic impediments but do not necessarily solve it. Many times the expectation is for us as the leaders to figure out the right solution.
For not knowing better, I did what I thought was the best I could do at that time – blame the organizational culture and tailor the framework around the dysfunctions. I literally pushed the very problems we were trying to solve under the carpet and got the teams working around them.
I believed that the teams were all set for self-organization. They were trained on Scrum framework and they were told that they are now empowered but somehow, they never took accountability or ownership of the delivery as they were meant to. This was turning a tough nut to crack, till I got guidance to look at the process and not the outcome.
It is then that I realized we had a structure that was set up to maximize efficiency and the measure of success was individual and department performance. This was resulting in a competitive culture where there was no incentive to collaborate. The metric had to change to overall value delivery and give the teams a reason to self-organize.
The bigger aspect of distributed teams had started rearing its head especially when teams were away by more than 10 hours of time zone difference. How do you do Scrum when team members sit on either side of the planet especially if you are part of the cost center? How do you not stress the teams out?
Especially when time-travelling isn’t one of the defined skills of an Agile leader!
I had by then realized and experienced the capabilities of the collective intelligence of self-organizing teams and had started relying on their inputs. Re-orienting the existing structure to create a lot more colocation, investment in high-def communication equipment, cross-skilling were few of the accepted outcomes for the teams based on the experiments that we ran.