As those that have read my blog before will know; I have had my fair share of software delivery transformation experience, I am growing increasingly reluctant to even call it Agile these days to avoid any kind dogma based resistance. Some of my efforts have yielded results, some I’d even be brave enough to say were successful; but there are others that were complete failures. By failure I mean that the real fundamentals of delivery and value were not improved, people may have felt better, those refinement sessions were better organized, but the things that really matter didn’t move.
So I’d like to reflect and share what I feel makes the difference between success and failure, between charting a course though a minefield and rearranging the deckchairs on the Titanic.
I believe it comes down to having three things:
Knowledge is pretty fundamental, whenever there is a discussion or article espousing the virtues of soft skills there is always some precondition that you need to know what you are talking about first, and my experience backs this up wholeheartedly. The knowledge in my world is mostly about Agile theory, practices and the management models that support them. Things like Scrum and complexity theory, Kano analysis and TDD, Lean UX and the workings of those highly controversial scaling frameworks. However, the big differentiator here is that it is more than theory, more than what can be studied and parroted back from Wikipedia articles, the ability to know what theory to apply in a given situation, that is the real skill. The difference between tacit knowledge and explicit knowledge.
When I refer to understanding it is about context, do you really understand what is going on, how the organisation reached its current situation? The drivers that got it to where it currently is are likely to still be the strongest forces that will be applied to any of your transformational efforts. Ignore local politics at your peril. As they say “Culture eats strategy for breakfast”. It takes time and an open mind to really understand this, to hold back from fixing the “simple problems” until you appreciate why they exist – chances are they won’t seem quite so simple when you do. There is a tradeoff to be made here though, the longer you work in a context to understand it, the greater the chance of that context influencing you, you go native and become as much a part of the problem as everyone else.
Lastly and most importantly trust. Without trust then you won’t get to influence the people that really can make a difference. Trust is the difference between being heard and someone taking action. As a transformation agent we have a number of skills we can pull from, facilitation can be beneficial with limited trust, mentoring requires a stronger relationship and coaching even more. Trust is usually harder to win the higher in an organisation you go, the time you spend with these people is less and they have more to lose.
This quote by S Covey pretty much sums this up:
“You need to have a good idea, you need to know how to implement it and you need the trust to carry it through”.
Requiring these three things also implies a fourth, something that people may not like to accept: time. Building knowledge, learning about the organization and winning trust; all take time, the latter two require time specifically in the current organisation. You can’t hope to enable substantial transformation quickly, regardless of your potentially staggering intellect.
The best approach I have seen is to focus on achieving understanding and trust through small changes at a low level that enable slightly larger changes at higher levels, until you work to a position of being able to support substantial changes at the highest levels around the same time that you have a deep understanding of the organisation and the trust of those that are accountable for it.
Best of luck