What I've should done - my Jerk-store moment

· August 4, 2014

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 revolutions 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 meeeh, but I know that some people there was 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 a 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 was 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 as 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 meeting with the *project office* that asked me how agile fits in with the 5 year plans that already was 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 was suggested. And still waterfall releases of the systems (3-4 times a year) because "that's to hard to change. It's how it is and there's not much to do about it". Oh, we created a 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 systems frames. In my mind it failed because no (big) changes on the output of the system was created. A LOT of frustration and anger was 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 to 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 an change office staffed with people authorised 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 run 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 was not included. As way to 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, its 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 written 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 have done a similar assignment (bigger scale) like I did, but in a *completely* different way. His way is much closer to what I wanted to do. You can see his presentation here. I think it's an awesome read.

Twitter, Facebook