I’ve got bad news and good news.
Rule #1: write commit comments before coding
Rule #2: write what the software should be supposed to do, not what you did
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.
Concerto collects some ideas for a better and more effective board to be used in Agile projects.
For an unfortunate coincidence, I chose the same name of the famous Parasoft’s development management software, which I didn’t know before.
Concerto board has nothing to do with Parasoft.
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