Main things that I got out of the discussion:
- PM meets with the Customer (Business Sponser) and gather requirements. May not be able to gather all the requirements. Will be constantantly revisiting until all the requirements have been identified.
- Prioritise requirements the way the customer wants
- Scrum the determination of the solutions and only do what you can during the sprint time.
- Complete docs and create sprints– should never be more that 4 weeks
- PM identifies any new requirement and reprioritizes the remaining tasks
- Document next prioritized items and create next scrums.
Summary: We are enabling the teams to say YES when changes are introduced. The customer is willing to wait until the next iteration because the period of time that they must is very short. For example, if the customer knows that they only have to wait three weeks to get a change, they are much more willing to wait. Additionally, the development team can accommodate the customer because the requirements are always reprioritize by the customer.
Basically, the PM can only control three things: Scope, time and resources. You can’t control all three. At most you can control on two at a time.
Bugs are to be considered work and the customer decides if they get fixed. This means that we may have to chance one of our variables. Scope, time or resources.
Reference: "The Pragmatic Programmer" – not really an Agile book, but it is really about good practices.
This was the best session that I have attended so far because the speaker conducted the session using the Agile approach.
1 comment:
I think it would be interesting for the group to hear more about this at some point so we can steal shamelessly the things that you think would work for us. Did he use the canned TFS Agile process template? ;)
- Janus
Post a Comment