Have you ever had a conversation and then a couple of hours later you come up with a much better way of stating your matter or a better phrasing?
This feeling is shown to great effect in “The Comeback” episode of Seinfeld.
I almost always have those kinds of revelations after coaching gigs. Sometimes during the gig which is helpful because I then can change into something better. Sadly sometimes after the gig which just frustrates me since there’s not much to do at that point.
The story I’m about to tell you is of such an episode. It’s from my, by far, biggest agile (brrrr…) roll-out task. To me, it all ended in a big meh, but I know that some people there were happier when I left and I supposed that meant something.
DISCLAIMER
Below when I write “I” we actually were a complete team. If I got these aha-moments earlier I could have helped us all to act differently and hence get a better output. But I didn’t. It came now. No shadow should fall on my co-workers. If shadows are to fall :)
What I Did
I was brought in to help the banking part of a big insurance company to apply agile in their IT development cycle. We’re talking 150-200 persons involved, 5 development teams and 3 business teams (did I smell something just here?) and quite a few other functions around them such as deployment, maintenance, etc.
When I arrived they had run a big pre-study and also tried ways to work in a bigger project. I was handed a report and told to roll this out in a larger scale (OPPORTUNITY 1). A schedule and suggested classes were given to me (OPPORTUNITY 2); teach them about agile in general, Scrum and user stories (OPPORTUNITY 3).
We were asked to review this and then come up with a model on how this would fit at the company (OPPORTUNITY 4). We suggested some minor changes that didn’t go down easy… as in they didn’t like that.
One of the awesome things about this project was that we had the full support of the management, as in they wanted this to be done and would help us change things. I was given an opportunity to speak in front of the management of this change project to explain what we were going to do (OPPORTUNITY 5).
I was dragged (yes, one of those: “you’re coming here. Now”) into a meeting with the project office that asked me how agile fits in with the 5-year plans that were already laid out (OPPORTUNITY 6).
What in reality came out of that project was Scrum-ish work at each team, a lot of frustration on how the current roles should fit within the “big” (not really) changes that were suggested. And still waterfall releases of the systems (3-4 times a year) because “that’s too hard to change. It’s how it is and there’s not much to do about it”.
Oh, we created an agile coffee meeting each Tuesday morning where people could come and talk about agile things, problems, and challenges. That was really good.
After six months, the teams were all working with Scrum (morning meetings, participations from the business teams in most of the development teams, iterations of 3 weeks, etc. etc.). They were, in fact, trying to fit Scrum within their current system’s frames.
In my mind, it failed because no (big) changes in the output of the system were created. A LOT of frustration and anger were displayed, mainly due to roles changing. Not much came out of that since we didn’t change the system, just how we worked within the system.
The client was happy with the project when I left. I was disappointed with my own efforts. Sure enough; I’ve heard that much of it now is on the verge of reverting “back to how it used to work”.
What I Should Have Done Instead (the Jerk-Store Moment)
Ok, if I’ve got the chance to do it all over (yeah, that’s the Jerk-Store feeling right there) I would have done something much simpler.
At each (and more) of the occasions indicated with OPPORTUNITY above, we should have talked about the desired outcome. The why do we want to do this. Much of the work right now was just implementing a plan that was laid out, without not really questioning why we did thing like we did. Even within the change project itself we failed to do this, which is very ironic.
Now, I happened to know why this change was requested, but we didn’t communicate that. Why was simply that the clients and the business thought that it took too long from idea to finished product.
Ok, here’s what we should have done:
Have the CEO of the department do a presentation with one slide explaining the WHY. “We want to be able to move faster, to better support the faster chaining demands on us”, for example.
Then say this: “Last year we released 4 times. The coming year we will release 6 times; 3 in the spring and 3 in the autumn. Here are the dates: X/2, X/3, X/5, X/8, X/10, X/11. Next year it will be ten, and then we continue to do more frequent releases. We do this to make sure to take the entire chain into consideration. Business people plan what you want to have coming out in each release. Talk that over with the IT teams to make sure what fits”.
Create a change office staffed with people authorized to change the current processes. Suggested staffing; one agile coach, one IT/deployment/production person, one business person, one from IT.
- Seat this office in a well-known location and invite everyone that runs into problems with the current process to come there.
- Get a commitment from the change project management to be able to do changes within 1 week.
Run agile coffee every morning where everyone is invited.
Do agile training on demand from the teams.
Start working and ask people to bring ANY problem they experience to the change office.
Why I Didn’t Do That
Short answer: I was a coward.
Longer answer: If I would have suggested that I’m pretty sure that would have thrown us out. They didn’t really want that, they wanted the project executed.
It was apparent that the management for the insurance company didn’t understand why this change was being done, and all functions were not included. As way too often, this was an IT problem and not until way down the line the production company (yes, that’s a different company) that did deployments and ran the code was involved. Hence the entire process was not taken into consideration.
What I Learned
- Say no. If you don’t think it will work say so. If you get thrown out it will hurt but you will not leave the project feeling disappointed that you achieved “nothing”.
- Agile (or lean for that matter) is not an IT thing, it’s a change in how you do business at the company. Make sure that everyone understands the difference or you will have much frustration and failure.
- You are here to change the process, not to “fit agile into the current process”. I wrote about this here.
- Make sure that everyone understands that you still will have anger and frustration, but hopefully leading to something better. Define that better so that you can point towards this.
- Create a function that can take care of questions. Sending information is not enough. Create a safe haven for asking questions.
My good friend Håkan Forss has done a similar assignment (bigger scale) like I did, but in a completely different way. You can see his presentation here. I think it’s an awesome read.