Who Cares If You Are Agile?

by Pawel Brodzinski on February 8, 2010

agile

Let’s play a small role-playing game. You are the vendor and I am the client. I exactly know what I want to buy. Sort of actually. OK, we may have to face some course changes as we hit the road. Anyway, I know what I want, okay?

At the moment I’m going to decide how your offer is best of breed because it surely is. So you tell me how great all the projects I can find in your portfolio were. You boast how enthusiastic reactions of your other customers were.

And we both know that’s complete bullshit.

Oh, maybe it isn’t but you wouldn’t tell me if things looked different anyway. You would try to sell me exactly the same sweet talk no matter how far from the truth it was. So no, don’t expect me to buy it.

What’s next?

Well, not the price, this is the last resort. Now it’s time for “we’re such a professional company” part. Methodology! That’s the thing. “As you may know, we employ agile approach in our teams so the software can’t be anything but top-notch. You had to hear about agile, this is one of the most popular and basically the best methodology these days.

I don’t give a damn.

I mean really. Why should I care what approach you use? Because agile is better? There is no such thing as the ‘better’ methodology in general. Silver bullets just aren’t produced yet. Oh, I see, agile is the best approach in this very case. This is the best choice in my specific project and my specific environment. Yes, looks better that way. But you know what?

I couldn’t care less.

I mean really. I couldn’t care less what you say you use. The thing I could care about is how you really work. But you aren’t going to show me that. How could you anyway?

The trick is you can do equally crappy job under the banner of agile as under any other. You can tell waterfall stinks because Scrum is thousand times better. Or you can tell Scrum stinks because Kanban is thousand times better. And both will be equally false.

On the other hand if your teams are well-organized the name of your approach is third-rate. You will deliver and will deliver quality. And yes, I’ve just said you can perfectly do it using one of old-school heavy-weight approaches grouped under infamous ‘waterfall’ name.

Results produced by suboptimal (for any specific case) but well-organized approach will easily trump those produced by optimal but in-the-name-only approach. You can do terrible job using agile, or any other methodology for that case, which you use as your selling point.

So no, I don’t care whether you’re agile or not. What I care about is whether you build quality products. Unfortunately the latter is so hard to present.

{ 4 comments }

Project Management Failure Stories: I Want Them All

by Pawel Brodzinski on February 3, 2010

fail

Once upon a time there was a project. It was rather small and, to some point, not very important. Bob the Young Manager has chosen one of the specialists to run this project. You know, all this boring stuff like reading specs, splitting the work to small chunks, telling how much resources he needs and organizing the work.

Mike who was asked to do the job agreed willingly. At least something appropriate for his ambitions. For more than two months no one asked Mike how things going and by this time Mike was all stressed since he was more than sure he’s not going to meet the deadline. Finally the problem reached manager’s ear and it was the best time for Bob to show his skills and bring the project back to the right way.

What Bob did was to move all resources to help Mike in the project. Barely few people were left at what they were doing before – the rest was told “Stop doing whatever you do now! Go help Mike.” People followed the request of their boss. After all he was their manager. Bob wanted all people to rescue the project. And he got them.

Whether Mike’s project ended up well or not we don’t know. Actually it doesn’t really matter.

Failure

It doesn’t matter whether the project was rescued because failure was around all the time.

1. Lack of project monitoring

The first thing which was failed was project monitoring. If anyone supervised Mike they’d know much earlier there weren’t enough people engaged. Actually it was enough to measure how much work is marked as done and extrapolate it for the remaining time. At the deadline percent complete wouldn’t be anywhere close to 100%. Earlier assessment means earlier reaction. Earlier reaction means smaller fire to extinguish.

2. People left alone

Mike was nothing like a seasoned project manager – he was just a specialist who was given a challenging task. No one cared to coach him. No one thought he could have had some problems just because of lack of experience.

3. Project firefighting the worst possible way

What really happened here isn’t really about Mike delivering his project on time or not. It’s about the impact of crappy management on other projects run in the team. That isn’t something which is seen instantly. The effect of throwing all people to firefight in one project actually means they don’t other projects. To rescue one small project three other were sacrificed in some way. They’ll be late or will have compromised quality. And I bet when they approach their deadlines there will be even more project firefighting needed to put them back on the right track (with no guarantee of success).

As a side effect a couple of people refreshed their resumes seeing enough to realize they don’t want to work that way whole time.

See all project management failure stories.

{ 2 comments }

Project Management Failure Stories

February 3, 2010
Thumbnail image for Project Management Failure Stories

We oh so often write about ideal world. How things should look like. How projects should be managed. How teams should be led. And then we come back to our desk and things around still suck, projects fail and teams have clueless managers instead of leaders. How come?
When I hear all these stories about crappy [...]

Read the full article →

The Kanban Story: Kanban Board Revisited

February 1, 2010
Thumbnail image for The Kanban Story: Kanban Board Revisited

Kanban doesn’t prescribe much – if you follow The Kanban Story you already know that. Kanban Board which is a key tool in Kanban isn’t pre-designed or something. You need to tailor your own. That’s how we did with our Kanban Board.
We decided to start with something simple and then adjust things as we go. [...]

Read the full article →

Fighting with Status Quo

January 29, 2010
Thumbnail image for Fighting with Status Quo

Last time I wrote about status quo and how it becomes protected value within companies. I could tell you countless stories of people being (mentally) hurt by status quo. I could tell barely a few of these when status quo was defeated.
How to fight with status quo then?
A short answer is: change rules of the [...]

Read the full article →

Big Companies Are The Best… In Maintaining Status Quo

January 28, 2010
Thumbnail image for Big Companies Are The Best… In Maintaining Status Quo

What happens when company grows from 10 to 100 people?
Initially there’s a group of highly motivated and hard working people led by one or a couple of visionaries. Everyone knows each other well. Everyone knows what anyone else is doing at the moment. Then some success happens and organization grows. At the beginning it scales [...]

Read the full article →

How Would You React to Corruption?

January 25, 2010
Thumbnail image for How Would You React to Corruption?

Project managers stand in a specific place. Because of their role they know much about projects they run. They communicate a lot with folks all around: salespeople, product managers, technical staff, client representatives of all sorts etc. They get a lot documents which shouldn’t be shared with just anyone. They just know a lot.
Sometimes [...]

Read the full article →

What Makes You a Great Professional

January 21, 2010
Thumbnail image for What Makes You a Great Professional

I have a small task for you. Think about a few people you know and you consider them as great professionals. Don’t limit yourself to any single role – choose anyone who is great no matter if he’s a manager or a developer or a dustman. Got them? Fine.
Now a second step – try to [...]

Read the full article →

The Kanban Story: Pseudo Iterations

January 18, 2010
Thumbnail image for The Kanban Story: Pseudo Iterations

One of reasons why I like Kanban so much is because it doesn’t force you to formalize your process. You don’t need to set strict time-boxing for example. If you want to – fine do it, but if it doesn’t suit you fine no one forces you.
If you happen to work in environment where priorities [...]

Read the full article →

Interview with Steve Kass

January 15, 2010
Thumbnail image for Interview with Steve Kass

Today on Software Project Management an interview I’ve made with Steven Kass. Steven runs AskAboutProjects site which is probably the best PM forum around. The interview runs mainly around AskAboutProjects and Steven reveals some of his future plans.
Steven, you’re one of persons standing behind AskAboutProjects which I described recently here. Why did you do it? [...]

Read the full article →