"There are no shortcuts to any place worth going." - Publilius Syrus
I was out working on the boat again the other tonight. I?m replacing the cabin hatch boards, they?re kind of a mess. I really rushed to finish the boat when I first built it. I?m embarrassed to admit that I cut corners in a lot of places. So, I?m doing a lot of that kind of rework right now. It?s all because I didn?t take the time to do a really good job the first time around.
But isn?t that always that way it works? There?s never enough time, and after all, you just want to go sailing, right? I love building as much as the next guy, but I?m not doing this because I love handling power tools. I built this boat to sail it. However, in hindsight, I really should have given more time and attention to quality. I would have avoided a lot of unnecessary rework. So, here I am, late on a lovely summer evening in my garage, not out on a lake gliding across the water.
Of course, it?s not the first time I?ve encountered this problem. I see it in Agile transformation work too. Often, when I start with a customer they are very excited to get started with their transformation. Maybe they?ve seen Agile work really well someplace else. Maybe they?ve actually done it themselves. Whatever the case, they?ve plunked down a sizable investment to make this Agile transformation happen. So, what do they expect? They want predictability, performance, enthusiasm, innovation ? all the usual benefits. Oh yeah, and they want it right now. They don?t want to invest much in building it because what they really want are the results. I really can?t say I blame them.
So off we go! I might start with questions like, ?Can we take the time to come up with a formal statement of why this transformation is important?? Often, I ask for some ways that a customer expects to measure the success of their transformation. I know what you?re thinking, crazy, right? Often those questions get only superficial attention, or even worse, blown off completely. Everyone is in such a rush to get through the training and start doing this Agile stuff, that they neglect to go through these more painstaking steps at the beginning of their transformation. That?s really just the beginning of the shortcuts. It?s not very long before I start having to answer questions like, ?Can we cut that 2-day training down to a single day?? Or ?Who really needs to be in that class??
Just like with building my boat, it?s hard to tell you exactly where the line is between appropriate and inappropriate compromise lies. My experience has been that there are certain things that just shouldn?t be skipped. Here are my personal top 4 items that I consider essential but that often get neglected when starting transformations:
- Executive Agile kickoffs ? Executives are notoriously busy people and fiendishly hard to schedule, let alone keep in a room for longer than 5 minutes. However, here?s what you risk if you skip these. If the executives are not in alignment regarding the need for the transformation, then you are in for serious problems. You might as well take that money you were going to spend on that transformation and spend it on bean bag chairs for the teams. Two hours with the executive team can make or break your transformation. A little face time reveals a lot very quickly. Given the cost of the average transformation, it?s time well spent.
- Getting the leadership team trained in the terminology and practices that are key to the process. Here?s the thing: transformation is a hands-on activity. It?s not something you can delegate. If you try and just write the checks, everyone will know you aren?t committed to the transformation in a meaningful way. You need to go through the training side by side with the teams doing the work. If you can?t make the time to do that much, save us all some time and frustration and don?t even start.
- Building a Transformation Team ? These go by various names (transformation team, Center of Excellence, Leadership Team, etc.) the point is that you are building a team of people who will support and evangelize the transformation in ways that a single transformation coach could never achieve. Basically, you are recruiting a team to help you make the transformation happen. This is also where we can engage people from other silos in the transformation activities. Once you start a transformation, you can?t afford to live in a bubble. You need to reach out and engage your partners and others in the organization. This can be a surprisingly large group. Do this and you set yourself up to win. Fail, and you are almost guaranteed to encounter headwinds that could easily have been avoided.
- Take the time to consider and agree on exactly why you are doing this transformation and also what you expect to get out of it. This is another one of those things that people love to skip. For some reason, they underestimate the critical importance of this step. If you fail to do this, you will find yourself struggling to explain why Agile is a good thing to doubters ? and guess what? Agile really isn?t necessarily a good thing if you don?t know why you are doing it! You need to be able to articulate the ?why? behind your transformation clearly and often. Everyone needs to be so familiar with it that they hear it when they sleep. Finally, you need to back that up with some measure of what benefit you expect to get from Agile. If you can?t measure it, then it?s not an experiment ? it?s orthodoxy.
You could put these items under the heading of chartering activities. They are the key elements needed to create alignment and consensus at the start of any large initiative.
I think I?m going to work a lot harder to avoid cutting corners on the next boat that I build. That?s probably either the voice of experience talking or the onset of a psychological disorder, but either way I?m pretty sure it?s a good thing. As someone who does a lot of Agile transformations, my advice is probably similar: don?t try to go too fast and try to avoid cutting corners. Take the time to do some chartering. If you fail to take that advice, it could be that rather than doing great Agile work, you might find yourself doing a lot of painful rework that you could have avoided. I can assure you that when it comes to rework, doing it with people is much more painful than doing it with a boat.
