Agile SW Development Practices Seminar
March 5, 2006 by Artem
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.
Bookmark/Search this post with:
Permalink
- 8675 reads
Best of AgileSoftwareDevelopment.com
7 software development wastes
adoption
Agile
Agile 2008
bugs
change
communication
conference
contract
contracts
Daily stand-up
Development
done
efficiency
estimating
estimation
kanban
Kano
knowledge
lean
link
management
news
pair programming
people
photo
planning
planning poker
practice
presentation
principles
product backlog
product owner
project management
project planning
quality
requirements
retrospective
roles
Scrum
Self Organization
site
software
sprint
story points
Tampere
task board
TDD
team
testing
tool
user stories
user story
value
velocity
video
waste
weekly
XP
xp2007
- Scrum backlog templates and examples
- Simple Product Backlog Example
- Simple Sprint Backlog Example
- Our Story Board is Better Than Yours
- 10 Contracts for your next Agile Software Project
- Get Forum Nokia Support and Development Tools for Cheap
- Six Features of a Good User Story - INVEST Model
- Video tutorial: functional testing with Selenium IDE
- Top 20 Best Agile Development Books, Ever
- Video tutorial: Test Driven Development in practice
- 7 Tips for Improving the Daily Scrum
- Your Unit Tests Lie to You
- Top 10 Activities of the Product Owner
- Product backlog
- 10 Principles of Agile Project Time Management
- Video tutorial: Managing your Scrum Product Backlog with the help of a simple Excel sheet
- Five risks of solo programming
- Extreme Programming
- Video tutorial: Test Driven Development in practice
- 10 Signs That You're Not Agile
- Five steps for starting the Scrum project
- 10 Principles of Agile Project Time Management
- Destructive bonuses
Subscribe to updates
RSS feed
Subscribe on Kindle
Navigation
User login
Private blogs of the regular contributors
Comments
Overplanning?
October 24, 2007 by Anonymous (not verified), 4 years 30 weeks ago
Comment id: 1374
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
October 24, 2007 by Vaibhav, 4 years 30 weeks ago
Comment id: 1375
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
October 24, 2007 by Artem, 4 years 30 weeks ago
Comment id: 1376
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