Last week I was attending the seminar on Agile SW Development Practices in Vantaa (Agenda in pdf).The seminar was very nice with a lot of speakers, talking about their own very practical experience in agile-related SW development. Most probably I'll highlight several seminar topics in the coming posts.
At the moment I can present my main impression: all the agile methods are about is truth and visibility. Don't lie to yourself; don't overplan, what you are not going to implement; don't pretend the project is 95% ready, if you are expecting endless bugfixes and don't hide the current situation from your customers. That's it. All the remaining details are about how to implement these principles in practice. I.e. how often and in which terms to report to customers so that they understood you and weren't overloaded with the unnecessary details, how to prevent yourself from overplanning, etc.
At the moment I can present my main impression: all the agile methods are about is truth and visibility. Don't lie to yourself; don't overplan, what you are not going to implement; don't pretend the project is 95% ready, if you are expecting endless bugfixes and don't hide the current situation from your customers. That's it. All the remaining details are about how to implement these principles in practice. I.e. how often and in which terms to report to customers so that they understood you and weren't overloaded with the unnecessary details, how to prevent yourself from overplanning, etc.
RSS feed
Comments
Overplanning?
I just started a project in the role of design lead. I fully believe in the agile methodology, every successful project i have ever been involved in uses the methodology. Its the natural way for good competent developers to work.
So back to the new project... I walked into this project and was given an "anatomy diagram" that defines 25 work packages and time estimates for each totalling 13000 man hours. This "anatomy diagram" was done by someone that will not be involved in the actual development of the software in any way (no software architecture, no coding...). I am expected to follow this diagram. I find it funny that agile says dont overplan your work. What about overplanning the work of 15 other people, and then running for the hills once your plan has been submitted?
Well that is certainly a
Well that is certainly a problem that is very prevalent. At our organization, we do have certain individuals who do effort estimation and may not actually be working on the project later on. However, each such individual usually has the role of reviewing the estimates done by the people who will work on the project instead of doing them by themselves.
These individuals are usually very experienced and so them reviewing or making estimates has helped us make very realistic proposals to customers.
Tough project
Of course, I don't really know your context, anonymous, but such amount of overplanning sounds like a set up for a failure. Unless, certainly, this plan will be silently ignored in the preference of common sense. It's not that rare case and sometimes it works well.
Heh, this amount of overplanning is close to driving a car with a GPS'ed plan instead of a driver.
Post new comment