Agile

I made a passing comment in the last blog entry to “the hardest bit” of Agile. I keep feeling I should elaborate rather than leaving the comment hanging.

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 could go on but it would be a very long list. Maybe you’d like to add some of your own.

(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?

Again I could go on.

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.

There is no such thing as Magic Agile Fairy Dust. Neither me or anyone else can come to your company and sprinkle my magic dust and fix all your problems. There, I said it.

Its more complicated than that, there is no out-of-the-box solution. I can help you, you can use some tools, some methods but it involves change.

That change involves not doing some things. Changing to Agile involves subtraction as well as addition. It is not enough to just add Sprints, stand-up meetings and what not, you have to stop doing some things.

And thats the hard bit. I can teach you the basics of “Agile” in a few hours if I need to. But it takes a lot longer to help you unlearn what you did before. Unlearn behaviors, assumptions, ideas and ways of working. You can’t do that in a few hours in a classroom, it has to be done in the workplace and over time. Thats what Agile Coaching is for.

The only thing that comes close to Agile Fairy Dust is Test Driven Development (automated) and Automated Acceptance Testing. You can add those things and start to see a difference. Not immediately but in less time than you think.

A few of points I picked up at the UK Lean Conference the other week I made a note of and think are worth recording.

Point 1: There are two kinds of Kanban limits, i.e. or work in progress limits.

The first is what we usually think of when we talk about work limits: how many tasks are we working on at any one time. This might be an limitation of the machinery and process we are using or it might be a limit we impose to manage the work.

The second type of limit is a limit on events. For example, you may decide the supply truck is only going to visit the factory once a day.

Or, to put it another way: decide what you are optimising. What is it you see to minimise? Maximise? or optimise some other way?

Point 2: Sometimes, flow trumps waste, and sometimes, value trumps flow. Or, to put it another way: Value > Flow > Waste

This was mentioned several times, and someone gave the original reference but it was too quick and I didn’t note it down. If anyone has it please let me know, I’d like to read it. Until then, here is my understanding.

When people learn about Lean there is a lot of focus on Waste. The Waste idea is easy to get and clearly makes sense. Then there are seven wastes to think about reducing – or eight if you read Liker in “The Toyota Way” and some talk about a ninth waste and I’ve even heard talk of ten. Anyway, 7, 8, 9 or 10 wastes, its something to get your teeth into and start doing.

But a more important concept in lean is flow. The idea that the path work takes through a system needs to be uninterrupted, smooth, and we should work to reduce the time it takes for work to move from one end of the system to the other.

So, sometimes, waste is acceptable if having waste improves flow through a system.

Then there is value. The idea that all work should deliver value to customers. And sometimes, we can deliver more value if we break flow.

For example: There was once a software development team who would throw away all their most recent work if the company made a new sale. The team worked in short iterations so they were never throwing away more than a couple of weeks work but, if they could make a sale by promising a quick delivery then the team reasoned they would add more value by just aborting the current iteration and starting over on the customers work.

Point 3: Waste breaks down in knowledge work
There seemed to be an emerging consensus that while the waste idea made a lot of sense that it could be carried too far; and in software work, and perhaps knowledge work in general, it lead us down some dead-ends and got in the way sometimes.

Because: knowledge work requires some experimentation and exploration, from a production point of view this could be seen as waste. However in this context it is knowledge creation.

I’m sure I learned other things at the conference but right now these are the things that stick in my mind.

As usual at conferences these points were made and learned more between sessions than in sessions. That said you need the sessions not only to give the conference form but to attract the kind of people with whom you will have these conversations. The sessions and speakers act as a kind of filter (Point 4).

I spent the first part of the week attending the UK Lean conference swiftly followed by the IRM BA conference. Heres a rough cut at some thoughts from the two conferences.

The first day of the Lean conference was my favorite – and not just because I was speaking. It was “practitioners day” which means it was light on big names. The second day was packed full of big name speakers and oddly that was a downside. While the first day was a two way conversation the second day felt more corporate.

I didn’t make it to the third day of the Lean conference because I was at the BA conference. Now this was a corporate conference. Yet the speaker line up was not so strong. OK, thats unfair, most of those at the Lean conference were already pretty advanced at practicing some form of Lean or Agile and the conference was about improving these activities. The BA conference seemed to contain more introductory material. So perhaps I’m not the right person to comment.

Actually, although I was officially attending, and speaking at, the BA conference I actually attended several sessions at the Business Process Management (BPM) conference. The two conference were running in parallel at the same location and on the same schedule.

Although I was a little unsure how I would be received by the Business Analysis community I need to report the reception was very positive. I was talking about Agile and I found that most Business Analysts were both interested in Agile and welcoming Agile way of working.

I’m happy to report that on Twit on Twitter declared I was the highlight of the conference!

As I said in my last blog entry, the presentation is now online – More important than ever, the role of the Business Analyst in Agile transition.

So what did I learn? What were my highlights?

John Seddon at the Lean conference. He took a few pot shots at Lean and raised some valid concerns. His alternative is systems thinking. Personally I think the two approaches are complementary. I am always keen to relate Agile and Lean back or organizational learning, and I believe that system thinking is an essential element of such learning.

John introduced me to a new term: “Failure demand” – that is the demand created on a organization or system because of earlier failure. He sited examples of companies and organization where the apparent demand was 60, 70 or even 80% related to earlier failures.

One common theme that seemed to span both conferences was the dangers of using inappropriate tools. Whether it was Lean in service organizations (from John) or using Six Sigma black-belt tools when simply asking users what the problem was everyone seemed to warn against excessive reliance on a tools.

One insight that will stick with me came from Jeff Patton (at the Lean conference) who pointed out that a Minimally Marketable Feature (MMF) is not the same as a marketable product. He introduced the expression “Minimally Viable Product” (MVP), an MVP is a collection of MMFs.

Over at the BA/BPM conference I was exposed to the Business Process Management world – speakers, exhibitors, attendees. It seemed to me that BPM far more intwined IT and technology than I ever imagined.

Mary Poppendieck (at Lean) was, as ever, a very entertaining speak. She introduced a new case study: the Empire State building. Built between 1929 and 1931 the main building was completed in 8 months, end to end it was a little over 18 months.

My notebook is crowded with ideas and comments but I don’t have time to document them all here. I am sure the ideas will find there way here eventually.

My presentation from the IRM IIBA Business Analysis conference 2009 is now online

More important than ever, the role of the Business Analyst in Agile transition

Some people quite liked it, see Twitter.

Another article by myself, this time in Tools and Methods. Anyone familiar with my work will probably recognize the theme: The Learning View.

For anyone who’s not familiar with these ideas this is probably my shortest yet introduction to the topic.

There is no such thing as “Quick and Dirty”. All my experience tells me “Quick and Dirty” actually means “Slow and Dirty” or “Slow, Dirty and everyone is unhappy.”

It came up again last week. I was asked: “When there is pressure to deliver something and you have the choice between getting it done, doing it right or getting it done and right, where do you come down?” It was a fancy way of dressing up the “Will you do quick and dirty?”.

Or rather, since we were talking about the management of software development the question was “Will you make your developers do it quick and dirty?”

This question, in its various forms, is used as a kind of test for us. The person asking the question wants to know if you have a similar set of values to them. In order to answer the question “right” you need to look into the soul of the person sitting opposite you and determine what they value.

All my experience tells me that when someone chooses a “quick and dirty” path a) it takes far longer than is expected, b) the quality is so low we go around the loop a few times making things slower, c) every one involved will feel bad, even “dirty” about the soltiion and d) it causes more problems very soon.

Perhaps (c) and (d) are where the name comes from: “A choice of actions which makes you feel dirty and quickly cause more problems.”

The “quick and dirty” or “slow and right” dilemma is only a problem because of the way we approach the question. There is an assumption that there are two, and only two, options. One will take a while and one can be done quickly, one is “good” and one is “dirty.” These two options are then juxtaposed and connected by the “tyranny of the OR.”

Everything about the question smells of winner and loose, or zero-sum game to give it a fancy name. “Quick and dirty” means “customer wins, developer looses”. And the alternative is “customer looses, developer wins.”

As someone who manages software development teams I find the question particularly naive. When I’m managing the team I can’t actually make anyone do anything. I may tell a developer to “do it quick and dirty” but I have no way of knowing what they will actually do. Indeed, asking developers to repeatedly do things “quick and dirty” not only damages the code base but means I’ll probably p***-off my developers. Before long they will be heading for the exit.

My solution: don’t accept this framing of the problem. Get more options on the table. (If you can stomach the tired old cliche: find a win-win solution.)

Define what you mean by the “quick and dirty” solution. What will it involve doing? Why do we think it is “dirty” ? Why do we think it is “quick” ? What will be the outcome? Will it meet our needs? Indeed, what is the real need? Is it what we think it is?

Repeat the exercise for your “slow and clean” option. Now if these two are opposite end of the spectrum what are all the thing in-between? What other options are available? What questions do you have which you should clarify first? Often there are questions over what is actually needed, when these are clarified the problem and solution may look very different.

Now of the options in front of you can you combine any of them?

Usually when I do this exercise more options open up. There are now “clean and quick”, “minimal” and other answers available. Sometimes “do nothing” becomes an option.

Unfortunately you also find that sometimes you options are very limited. Everything looks “dirty”. The “right” solution is not even on the table so there never such an option in the first place. Doing it this way also makes people feel better, if you do have to compromise somewhere then at least everyone involved has had a chance to have their say and look at the options.

If this all sounds like it will take too long then try it and see. Taking longer in the “what are we doing” phase usually saves time in the “do it” phase.

This is not to say there are not times when you should not take fast action. Sometimes the right cause of action is to “damn the torpedoes,” push on, take the risk and get something done. However those occasions are about getting stuff done, not about making choices.

So, next time someone asks you to do “quick and dirty” remember: there is no such thing as “quick and dirty, only dirty and slow.” Then get some options on the table.

Suggestions please.

I few weeks ago I received a request to create and deliver an “Advanced Agile” training course for a Scandinavian client. My first reaction was: that is more of a consulting or coaching assignment. But when I thought it through and considered the kind of material I covered in my own “Agile Foundations” course, and the introductory courses I know from other people the more I realized how much more there was I could cover.

I’m not most of the way through creating the course and I’ll deliver it in a couple of week. I’ll report back on what I put in and what people thing.

In the meantime, I was wondering: what do readers of this blog consider Advanced Agile?

Suggestions please, on this blog or e-mail me and I’ll summarize them.

I have a piece by me in the latest issue of e-Technology Management entitled “Agile agile everywhere – not a definition to speak of”. Believe it or not, for all the stuff I write in this blog about “agile” I’ve been trying to define what “agile is” for a long time. When I deliver a training course I always want to say “Agile is…” but there is no simple/short definition I can come up with.

In the e-Technology Management article I distinguish between Agile methods, the Agile toolkit and Agility or, to put it another way “the sate of being Agile”. The term “Agile” is really a label for all of these ideas. Its short hand, its useful in conversation but if you want to really understand it you have to go beyond the label.

One of the problems with “Agile” is that it are often defined as “not the waterfall.” Someone says “What is Agile?” and the answer starts out “Well you know traditionally we did requirements, then analysis, then development, then…. ?”

Yes its laziness, yes I’m guilty, but I’m not the only one.

When we define Agile by what it is not then the scope is unlimited. In my experience, very little development work happens the way it is supposed to in the “waterfall”. So most development is “not waterfall”. Thus, if you define Agile as as what it is not (i.e. not the waterfall), and most development is not waterfall (at the point the work is done) then most development is Agile.

Anyway, I’m sure this is a theme I’ll return to.