Pages

Friday, February 11, 2011

ScrumBut is a good think after all

And a lot of work

A joke to start

Did you know every German factory has a Portuguese guy working there? He is locked inside a glass dome with a sign that reads: In case of emergency break glass.

I’ll explain this joke for you just in case you don't know anyone from Portugal. Portuguese people are very nice and kind. We truly enjoy making other people comfortable and we are also very adaptable and full of initiative, which is a good thing for work in general. But... We can break any rule of any kind that anyone can think of. Thus the joke. When you have your processes running smoothly (a stereotype for the German way) and everyone is happy (ok, not a great match for the German stereotype) with the results they’re getting, I can assure you that the last thing you want around is a Portuguese guy. But when things get off track, and you need someone who’s not afraid to try out new things, then a Portuguese guy is a great option. Note: (i) I have to thank this joke to a good German friend of mine and (ii) the use of "guy" is meant to replace either man or woman and is not gender specific.

Agile in a glass dome

And this is why I like Agile. Agile is the poor guy locked inside the glass dome. He’s the one willing to fail while trying to make things work. But on the other side, you probably don’t want to be all that Agile when you have everything running smoothly, just like the German factory doesn’t want the Portuguese guy to be in the way. Let me elaborate a bit on this.

Where Agile fits in
Think of a marketing project. It’s very common to have marketing projects starting with a deadline, a budget and some needed outcome. And no clue as to what to do. It’s not too farfetched starting to think about getting email addresses for some Newsletter with a particular target audience and end up with a new stationary. Agile is perfect to get a grip on this. A couple of examples of Agile approaches for this particular case may clear things a bit:

Having short term deliverables (or sprints) helps you correct course faster;

Having a demo helps everyone involved realize if what is being done helps to achieve the desired outcomes.

Both these examples contribute to solve problems that this type of project brings because:

You'll probably change it frequently and drastically as you don't have a way to know what your project is supposed to do, you just have a needed outcome;

You have to make sure you're working for the desired outcome and not doing things for the sake of doing them.

Where Agile doesn’t fit in

Now imagine yourself managing a construction project. These projects are bound to change as well, but they change in a different way. If they had the same kind of radical changes that are common in marketing projects, you could start a construction project for an Hotel and end up with a bridge. I’d say this kind of change is near impossible for this industry. And I'd say Agile doesn’t feel fit for these projects.

And we get to the ScrumBut
In the middle of this type of projects lie most projects with a wide range of characteristics associated to. Each of them has its own problems and for each of them you have to find a solution.
For instance, in a software development project where there is no trust between the customer and the project team, Scrum as it is won’t work. But. Consider this: why not get someone with a Business Analysis background into your Scrum team and turn him into the Product Owner? Would that work?
This is a choking thought. Next thing you know you’ll have a Design sprint... But then again, who cares? As long as it makes your project work out and you a better Project Manager...
And in this scenario, adding a Business Analyst to your project could be the solution. For starters you wouldn't have a trust issue. And someone with a Business Analysis background would probably have the required sensibility, knowledge and expertise required for the Product Owner role.
So getting a framework (Scrum or whatever) that solves most of your problems and changing the things you need to solve your particular problems in your particular project is in fact not only a good thing to do but the best to thing to do. Of course this is not all that simple as you have to make sure that the resulting “framework” works. Two year sprints doesn't sound very manageable with Scrum, does it? It’s much easier to go for Scrum and then if things go sour you can always blame it on Scrum itself.

But where’s the data?

I feel I have to add a final comment as I don’t have any hard data to back up all this. But at least you have to agree that this makes sense: there is no one recipe to solve each and every problem that you can find in a project, on any kind of project. You can find this same approach on some literature. One book that comes to my mind is “Agile Adoption Patterns” by Amr Elssamadisy. I’ve read it some years ago and I really enjoyed it. I’m actually planning on reading it again in order to review it here, but in general the book goes like this: you have a particular problem in your project and Agile has a solution for it; and then the author explains how the proposed solution helps solving the problem and the pros and cons of using that particular solution. This makes all the sense to me. But it forces you to adapt to context. And to think about solutions. And to check if they actually did work. And all this means a lot of work.
On the other hand, it’s much easier to follow some recipe. But assuming there is one right way to manage all projects can only lead you into trouble. If you put it this way I guess it’s pretty obvious which way you should go: ScrumBut is the way. So ScrumBut a lot and maybe then......you can be a better Project Manager.

7 comments:

Agile lays emphasis on a collaborative leadership style where we closely work with the customer. There are rapid feedback sessions with the customer very frequently. Why isn't agile approach a fit for the construction industry?

We can start constructing the major stuff say the dining hall for the hotel all the while in close collaboration with customer and get rapid feedback from them if they need a change.

Regards,Arunahttp:\\www.technologyandleadership.com"The intersection of Technology and Leadership"

Agile was built as a solution to problems in Software Development and there aren't very similarities between Software Development and Construction. In fact, many are quite the opposite, namely:- Most of the Construction work is not intellectual work- You have to build what's in the plan- Construction is naturally phased (design, structure, cabling, piping, and so on)- Construction is a very old industry- Construction has very slow technology changes

These are just a few of the things that come to mind that makes Agile not fit to Construction. It doesn't mean you can't use some Agile approaches with success in planning, for instance. But the problems you find in Construction are not the problems Agile tries to fix, namely:- Intensive intellectual team work- Bring together in one team all the necessary skills- Put in place a framework that puts in you control over fast paced changes

I hope this explains a bit better why Agile isn't fit for Construction. And I hope to hear from you soon.Again, thank you for taking the time to comment this post.

There are tools like http://v3.planningwiz.com/ that can make planning and design phase for construction agile. The rest of the phases as you said involves physical labor rather than intellectual capabilities. Looking from this point of view, I agree that agile isn't a fit for the construction industry.

Thanks,Arunawww.technologyandleadership.com"The intersection of Technology and Leadership"

"..start a construction project for an Hotel and end up with a bridge"...

Great analogy!

The voice of the majority is often drowned out by the voice of the "extreme" minority; after all, these are the people with the passion! Whether a debate between creationists and Darwinists or Waterfall and Agile aficionados, it is tempting to forget that the vast majority live within the two extremes.There is, as Luis suggests, a place for both, you just have to understand the best (combination of) approach(es).

Thank you for your comment.That is precisely what I meant with this post. Instead of asking “what is the best framework to do Project Management”, learn it and apply to each and every project you manage, you should ask “what are the best tools to solve these particular problems with this particular project”. I’ll second the latter on every occasion.