Recently I’ve been in many discussions about using agile in bigger enterprises that shows that one message of agile has been lost. It goes right to the basis of using agile (or lean for that matter, more on that later) in the first place.
I think I speak too little about this, or at least I feel the need to be much more open and transparent about it. This post is a first attempt to bring some clarity.
NOTE I know that this will come out like a rant. Sorry. It’s not. It’s just the state where I’ve seen it. If anything I think that I have not been candid, clear and transparent in how I communicated.
Background
I will give you some flashbacks first and then try to tie them together.
In the beginning there was Scrum
I remember when I took the Scrum Master certification way back in 2004. I was fortunate enough to have Ken Schwaber himself as my teacher. Many of the things he said has stayed with me for a long time.
Regarding this post, this was a quote that I’ve used many times since then:
Scrum will find every problem in your organization. Fast and without mercy!
That is of course scary when you read it… depending of what your goal with “agile” is. Finding problems?! Why on earth would you want to do that?
“Go over there and make them agile, will ya?”
I have, more time than I care to think about, been sent to teams or department to “help them to become agile”. Often these poor people don’t understand why they need that, when the problem is somewhere else.
My favorite story about this was when I worked with the mainframe developers of a big Swedish company. They are slow - everyone knows that, right? As it turned out even small requirements took about 9-10 months to complete. Average development time for these was 3-5 days.
But still I was there to help the developers to become more efficient. And there was no efforts being made to change in any other part of the organization.
But they really should use agile, that will make them faster.
“Oh, so that’s almost like a UAT tester then?”
Many places I’ve consulted at tries to fit agile into the current ways. It’s almost always bad advice. The most common way this manifests itself is something like this. When introducing Scrum, for example:
Oh, that's almost how we did development around here for about 10 years ago
No it’s not. Most likely not. And by trying to shoe-horn it into your current ways you’re hurting both your current ways. AND limiting the benefits of using agile.
Why do we do agile in the first place?
Sadly most companies I’ve been helping to “do agile” has absolutely no ideas as to why. At least not around benefits nor consequence it’s meant to bring. Sometimes it’s called “improve IT efficiency” or “shorten the period from requirement to finished product” - but seldom the real benefit of agile is talked about.
What did Mr Schwaber mean when he mentioned that Scrum will find your problems? Why is it stupid to send someone to fix the “developers” in this organization?
Because agile is not meant to improve part of your process - it’s meant to improve your entire process. Hey, even your entire business model in the long run. I would love to have had the guts to ask this:
Client: Help us start using #agile
— Marcus Hammarberg (@marcusoftnet) February 27, 2016
Me: Oh? You need to change the fundament of how you do business?
This is where we heading. Changing the way we are doing business. That’s where “implementing agile” will lead you if you let it.
In fact, if not… in my experience most efforts of implementing agile is not only useless but probably harmful. People will have to change the way they do work, probably titles and most likely many people will not like the new playing field.
I’ve been in many many conversations where people say things like: “Well that’s cute and everything but here at X we have our processes, and these roles etc. We are NOT about to change that”.
Well, that kind of mindset will not mix nicely with agile. Because, make no mistake: agile is here to change how you do business.
By the way… so is lean.
Start where you are
I am ready fond of the kanban battle cry:
Start where you are
In this way kanban is much nicer to get started with; change nothing in your current setup, no new roles, no new jobs, no new organizations. It’s just like before.
However the “start” in there marks the start of something. What? Well of the change. As David J Anderssons book is subtitled: “Successful Evolutionary Change for Your Technology Business”.
Yes, it’s about the same thing. Of course. Why would we add kanban or agile at all if we don’t want change?
There’s a nice little story about Toyota’s early years in USA. At that time all car manufacturers were given directions, by the government, to develop electric cars.
Most of the American manufacturers said:
We can't do that. With our processes today it's simply not affordable for the end customer
Toyota went:
What do we need to change in our processes so that the car can be manufactured to an affordable price?
Change is built in how they do business. Reaching the goal is more important than the current ways and processes.
Summary
For many of us this might sound like obvious things, but I have met many big organizations where even thinking that you would change the process, the roles or working outside your normal roles is frowned upon.
I think I don’t tell people enough about that. Because changing the organization and process to support a faster flow is what agile is all about.