Find here the follow-up of this post.
I find it vaguely irritating when the abused image in which software is described as an intangible product is used.
Software is, of course, intangible as of dictionary definition (“Incapable of being perceived by the senses, Incorporeal“) since it’s made of bits and bits obviously cannot be touched.
But this is not the abuse I’m talking about. The annoying cliché used in tons of posts and articles speciously refers to another meaning, and it’s very often used by-end.
This the second part of How I Was Able To Be Successful Even When Forced To Use Waterfall
Rule #1: take your time
Luckily, your estimation meeting will be much more fortunate than mine (see Part I).
In my previous Scrummerfall experience, since I was forced to produce a big-planning-up-front phase, I was used to always plan 2 or 3 days for it. I was asking for an estimation when my ignorance of the problem was at the maximum level, hence I needed a lot of analysis.
Waterfall can work
No it cannot.
I mean: actually, it does, but adopting new and modern methodologies, you can dramatically improve your team productivity.
Yet, I believe most teams are using a mix of Agile and Waterfall. The reason is Waterfall is the sole methodology able to give the only information your manager needs to know: how much the project will cost and what’s the delivery date. About this, read the excellent post by Christopher Goldsbury Why Agile Adoption Fails in Some Organizations
I once worked as a team leader in a startup. I was in love with XP, studying Scrum and looking forward to be able to put into practice what I was reading.
Unfortunately, my boss explicitly told me to use Waterfall. I never blamed him: before him, the company had no process at all, and was governed by anarchy; no documentation, no requirements, no clear roles. Actually, introducing a Waterfall process, he made a great revolution, and let the company succeed.
Perché è così difficile essere meritocratici? Continue reading