A couple of weeks ago I was teaching an Agile class for DevelopMentor in London and someone asked “What is the hardest part of learning Agile?” It was a natural question and one I realised I‘d heard several times before in different forms.
So it is a frequently asked question. And the answer is...
Its not so much what you have to learn to do Agile its what you have to unlearn.
Most Agile methods are fairly easy to learn, remember they were originally termed “lightweight” and emphasis simplicity. Any method that gets overly complicated and difficult to learn probably isn’t Agile.
(One of the reasons I don’t consider RUP to be an Agile method is the complexity and size. Although you can make RUP work Agile that doesn’t make it an Agile method, but we digress...)
Generally I deliver an Agile training class in two days. We cover a lot of ground but we can’t cover all the corner cases, rough edges and unexpected situations you come across. When I work embedded in a team, as an Agile Coach, I brief the team as we go along. I might start with a couple of hours teaching to lay out some basics but thats about it. Since I’m there for longer I can teach team what they need to know when they need to know it. Or better still, I can help them find their own solutions.
(In both cases I like to use plenty of exercises. Its one thing to talk about something, its another to experience it. But we digress again...)
But what is more difficult is not what you need to learn, but what you need to unlearn. People need to unlearn previous beliefs and the behaviors that are rooted in those beliefs. For example:
- Unlearn the belief that work can be specified up front. Instead learn that needs emerge, evolve and change.
- Unlearn the idea that work can be planned in advance, specifically unlearn the idea that Gantt, Pert or CPA charts hold the solution. Learn that work is planned reviewed and replanned with blinkers on so we only look at the near future.
- Unlearn that estimates should be padded and schedules include slack time to buffer. Learn that estimates are just estimated, not commitments, and schedule slack hides problems.
- Unlearn that bugs are inevitable and we needs lots and lots of testing to find them and remove them. Learn that quality is free and we can eliminate most rework by prevention.
- Unlearn a faith in tools to solve our problems. Learn that problems are solved by people and our own initiative.
- Unlearn that “thats the way we do it around here, you can’t change the system”. Learn that if things are going to get better thing have to change around here.
(I wrote about unlearning in a guest editorial for ACCU Overload a few years back, The Need to Unlearn.)
Unlearning means we stop doing things. We take things away from the way we work today. In the short run we might make some compromises and add Agile practices before we remove current ones, but that can only be a short lived situation otherwise we drown in contradictory practices and excessive work.
The implications are quite scary for some people. For example:
- Adopting Agile project management means you need to change the way you plan at the moment. Continuing your PRINCE2 based project management while running an Agile project management process in tandem is self defeating. Yes you can use the two together but you need to change your current practices not just add more.
- Agile development work can, and should, start before requirements are fully defined. Work is goal and value driven rather than document and feature driven. Again, you can start your transition to Agile with a big requirements document in place but if you maintain strong resistance to change you will not see the benefits of Agile working and you will not really be Agile.
- You need to trust your staff, your developers, testers, business analysts and everyone else to do the right thing. If you can’t trust them why do you employ them?
A few months ago I took a stab at guess-stimating how many people are “doing Agile” (How many people are doing Agile?). Since then I’ve come to the conclusion that a far higher number of organizations and teams claim to be Agile - after all who wouldn’t? Agile is good for you, like Apple-pie. But I think most of these places are taking the additive approach. They are applying some elements of Agile to what they have already. They are not unlearning and they are therefore not seeing the improvements they hoped for.
Unlearning poor practices that you're already doing is one thing. Learning new practices that you're not doing is another. They're closely related though - it's very hard to get rid of a poor practice unless you replace with something else. One way or another you need to get people to experience the new practices. It’s easier to act your way into thinking differently than to think your way into acting differently. Buckminster Fuller once said "You cannot change how someone thinks, but you can give them a tool, the use of which leads them to think differently."
ReplyDeleteA lot of this discussion around Lean and Kanban Software Development seems complicated and is getting quite scientific. Does that mean it's probably not agile?
ReplyDelete