After the intense and somewhat heroic efforts by the team, a retrospective is definitely apropos. The key lessons learnt are:
- Scrum definitely works when used in a chaordic context. What might appear as the ritualized trio of questions, what did you do yesterday, what do you plan to do today, what are the impediments to progress, focuses the development team on what needs to get done.
- Working software is the ultimate measure of progress on any software project. If it’s buggy you will have trouble gaining the trust and required acceptance and signoff.
- Short feedback loops via daily stakeholder meetings help focus the development team on what needs to get done
- Having a developer who also happens to be a subject matter expert will propel the team further.
- Don’t change the domain model if it’s not broken. A distinction has to be made between purely technical changes and changing the semantics of the model.
- Regression issues will undermine the team and erode user confidence
- Make your tech choices before hand and adhere to them
- Beware of feature envy - http://c2.com/cgi/wiki/Wiki?FeatureEnvy
- Keep the testers close and the customers closer
- Retrospective testing of code is much harder than TDD.
No comments:
Post a Comment