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.