by Pawel Brodzinski on February 8, 2010
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.
by Pawel Brodzinski on February 3, 2010
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.
Subscribe RSS feed
Follow on Twitter
Subscribe by email
