The Hydra and the Abyss

I recently had occasion to speak to a good friend about the state of agility in general and the needs he was looking at in his organization. This brought me to the question – what is your biggest problem and how are you trying to address it? The answer surprised me a little – because I have dealt with it before. He was looking at the integration of the “last piece” of the IT structure. How do we get the mid tier and back end IT support groups into the Agile umbrella? If I recall my mythology correctly, the hydra is a dragon like monster with many heads – and when you cut one off, two heads grow in its place. I find this an ideal metaphor for transformations, because it seems just when you identified and resolved a core issue – you have two more issues take its place. The challenges I face are always interesting, but they seem to circle around three “heads” – management misalignment of expectations, team misalignment of expectations and product team involvement. I have dealt with all three of these recently, and have realized that any one of these can “kill” a coach immediately.

The easiest "head" to deal with seems to always center on team expectations and understanding. This is normally overcome with experience – a small amount of exercise of the process with some increasing success. This makes some of your strongest doubters turn around and explain how you had a communication problem, and if you had just explained it differently, they would have seen what you were saying. Of course they will help you now, it is SO EASY! Honestly, few things are as satisfying as seeing a genius developer stumble upon a basic puzzle like agile, resist it vigorously, and have her “light up” when the parts start to click. This is so contagious, in fact, I count on it spreading to the other team members. But every once in a while, you get a bad apple – and these guys can make life extremely difficult. Agile transitions to a team can easily be sandbagged, and even sabotaged. Depending on the environment, this is a concern that coaches have to keep in mind. Most Agilists I know come into a client bright eyed and bushy tailed, expecting a full collaborative and open environment willing and desiring change at all levels. What I have seen is one champion, that is usually cornered by the environment and the impossibility of the task at hand, who cares about people and is at her wit’s end. Team issues are complex, and few places are ideal – coach beware!

Product Team engagement seems to follow this type of pattern as well. But the product people I have worked with seem to not resist new methodology as much – and are focused and looking for results. Whether the first attempts are successful or not, the product owners I work with are watching, and listening. By and large, they want to engage and understand – even in toxic environments. And they want results. Maybe because the focus is slightly different, maybe because the personalities are different themselves I tend to see that if you educate and show a product person the ropes, and have a good/bad/indifferent cycle – they are ready and able to go and help out. And they DO want to help out. I have yet to meet a nefarious business user (though two BA’s came really close – but they were both in IT) but I have met some guys that were real drivers. This particular issue is a hydra head because once the Product Team understands their role, they will want much more engagement in product development. This causes discomfort in the middle management layer of IT. And now, we have two competing stakeholders trying to influence a team! Additionally, depending on environment and culture, a few successful PO’s can be railroaded by a few threatened business PM’s or Directors. Again, coach beware!

The last "head" is the most unusual one. Because it comes from within IT, and lies in wait to surface at it’s own time. One study seemed to suggest that the main reason for Scrum implementation failures was IT Management interference. It seems that people in this role feel very threatened with a process that does not call out their role, and with organizations that lack education to be able to function within the new parameters. As the implementation succeeds, and as no one helps the managers understand their new role, being the humans that they are they fall to their comfort zone defensive positions. For a manager, by and large this is the area of Team CONTROL. The very thing we as coaches are trying to get the organization to move away from! Because it happens so gradually, this surprises many coaches. But really, it is a basic human response. Unfortunately, once you see the pattern start to emerge, unless you have either strong and engaged high level support or a fantastic environment to work with, it becomes very difficult to change “hearts and minds”. These guys were hired to lead, and most of them tend to think of this as a control methodology. Once you are the “enemy” their sole goal is to get you to fail or get you out of the project/program/organization. Scrum Coach, be aware and be weary!

This is a basic trio of issues you should be prepared to face when you walk into any company who is trying to change things around. Helping someone change is insanely difficult and has many challenges, with every different player having different expectations and goals in mind. Even a robust communication plan and execution can leave gaps that may come back and haunt you. What is a coach to do? In my experience, going in with open eyes, knowing some of the challenges, and keeping a positive attitude are all good ways of mitigating the possible issues you will face. Having a support group, and measuring progress iteratively help quite a bit as well. But there is another face to this thing, and it is far crazier than the hydra. When you have a defined issue, it is a matter of determining what is the cause, analyzing for possible solutions and executing on your resolution plan. Like identifying a known bug in a program. Once you know where the code is “broken”, it becomes and academic exercise in solving the issue. But like code, sometimes the bug is NOT easy to identify. And sometimes, it can possibly be a behavior that is induced by no “break” at all. When you have an unknown and unquantifiable bug, it is tempting to tell QA “there is no issue here”. But if the users are complaining, and things are not adding up – well, it is time for a spike.

When you face this as a coach, it can be extremely daunting. There are organizations out there with enough money and enough leaders trying to differentiate themselves that getting “Agile Certified” is seen exclusively as a silver bullet. Not for the organization, but for them. Also, there are organizations with too much money and not enough sense – and they will hire you to make themselves feel good. In both of these cases, success is measured differently than execution. For a coach in these conditions, it can feel like you are in a pit of molasses. People in leadership tell you to be patient change will come eventually. But when they hire key people in the organization, you see them going in a different direction. When you try to hold a team accountable, to their own commitment, management undermines you and makes excuses for them. But don’t worry you are doing a great job! We like the way you think – we need someone like you to remind us… And you as a coach are dying. This, my friend – this is the abyss. And to this one, there may not be a solution. I wish I could tell you that I am the only person who has ever experienced this or even observed this. Personally, I know at least 4 coaches that have shared this experience. All of them have been called back by a client who LOVED them, but had no intention or capacity for change. Personally, I am very feisty, I actually try to climb up the sides of this thing. But to no avail, when they like you for other than your cornerstone skill set, it is difficult to get unstuck.

So what can be done about these challenges? What action item have I seen to make things better? What conclusion then, oh crazy one? For this, I have no answer. You as a coach, you as a practitioner need to know yourself to see how you can face these daunting tasks and foes. I write as a coach, and a person that has helped many teams. I admire team members, developers, who take on organizations to put these changes in place. It is crazy to think anyone could do this! But it can be done. The thing is, it depends largely on individuals, on people. So the person coaching, the people asking, those working – getting them aligned, educating and guiding, setting up timeboxes – all of these are necessary. And they may work. They SHOULD work. And if they don’t… Well, keep trying. Keep analyzing your successes and failures, so you are more prepared for the next time. Because if you are crazy enough to try this – you probably care about people; and you probably get in trouble anyways. Just take some time to observe, and good luck!