Many years ago, I was assigned to lead an amazing software technology center, where teams were on the journey of Agile transformation. I remembered clearly a senior engineer passionately gave me a dose of Agile Manifesto right after I took on the role, and it makes a lot of sense. Then teams showed me how they go about implementing many of those Agile principles – office space was opened up (old cubicles were gone), big monitors are everywhere displaying all kinds of dashboards, desks are setup for pair programming, baseline build and auto tests traffic lights are blinking, stand-up meetings daily, retrospective all the time. Everything seems to be transforming smoothly… great! A few years later, I was assigned to lead another amazing software technology center in a different country and a different location, where teams were also under-going Agile transformation. Except this time, in the first few days in the role, I got a load of complains from many people in the center about how horrible the transformation went, because a coach with dictatorial style was hired, who upsets everybody and then was fired a few months later and right before I came into the role. Also office environment was not setup for Agile practices and there is no money to invest in any changes as the industry was under-going tough time. Two amazing organizations full of talented software professionals, two completely different situation of how Agile Transformation set in. This makes me wonder, what really is Agile Transformation and what makes it successful, and here is my take.
It is all about people, so start with people
“People first”, it is so true as everything starts with people, and no exception for Agile Transformation. It is a change of mindset, a change of behavior and a change of habit, everything else will follow through after that. Unfortunately, these changes are not easy to make and even more difficult to stick, so it takes time and you can not really force it. Take time to tune into the “WIIFM” of your people (WIIFM – What’s In It For Me, one of my coaches used to say this is the channel that everybody listens to). Why Agile? What’s the value of doing it? What’s the consequence of not doing it? What’s the context and the state of the teams? Start working on these answers TOGETHER with the teams, as detailed as possible, bring in coaches that have done this before successfully, show and tell, practice and see what’s sticks and what’s not working, adjust – there are some practices work better than the other so do NOT do things by-the-book or copy-paste…Engineers are smart and rational, so when they see the value of it (WIIFM) and embrace it, they will do it and sometimes so willingly and elegantly that it will blow your mind!
It is all about visual management, so create visibility and transparency as much as you can
Why so many dashboards, why flashy traffic lights, why pair programming to have two sets of eyes on the same sets of codes, why open up the offices, these are all means of visual management. People are visual, when things are visible, it is very hard to ignore… no more “bodies in the drawer” story. So visibility and transparency are at the core of Agile practices. And creating visibility and transparency does not necessarily mean lots of investments. Also very importantly, every time we brough light to some information and make it visible and transparent, we need to clearly understand why that is important, for what purpose so those visibility and transparency actually trigger meaningful actions.
It is all about continuous improvement, so get feedbacks quickly and do something about them relentlessly
The whole idea of Agile is not to speculate what’s really needed by users and spend years of building something turning out to be useless (there are so many cases in software world demonstrate this exact point), instead gather inputs and feedbacks (via MVPs) before and while you are building it, in iterative manner. This actually requires disciplines and tactics of how to do that effectively and there are enormous literature and sharing online about this for different situations (enterprise software, consumer software, …). One key tool in the continuous improvement is retrospective, make that process fun and psychologically safe are extremely important in order to get something useful out of it. This again goes back to point 1 in terms of starting with people. And finally, feed all the learnings back into the products and practices, adapt and adjust, so every cycle is better than the previous one.
Bin's Blog 