In my previous post I introduced some basic principles of project management, so if you skipped that part, please read it first 🙂 ). Here are my rules of Agile planning:
- Rule1: Ask PO to present the vision of the new release to the complete team. This is milestone M1. Everyone in the team deserves to know what is the ultimate goal of that release.
- Rule2: Define “rules of the engagement” for the complete team, including PO. That includes iteration span (heartbeat of the project), kick off dates (day in a week and the exact hour), standup meetings, scrum of the scrum meetings, format of the kick offs and demos etc (link to my previous post on agile meetings). This needs to be presented by project manager at very first iteration to the complete team. There might be some suggestions and arguments – that is good as we need to work as a team, but once that is all cleared – no more discussion on that. Important part of a project manager role is to show consistency by example, and insist other people follow the same. I am true believer in self organized teams as long as the rules of game are known to everyone.
- Rule 3: Don’t wait longer that 20-30% of the full release cycle on scoping and effort estimation. More than this is a waste – less than this is a chaos. The most important part of the work within first few weeks is to run workshops and understand underlying complexity. Use whiteboards and avoid any UML tools or ppt slides. This is also the time you can tests new frameworks. Do iterations and coding(spikes) from day1, more you wait, longer the uncertainty (“Cone of Uncertainty” is not shrinking).
- Rule4: Once you reached high level of understanding of the project functionality, create the project plan (something like a skeleton planning discussed before). Skeleton plan should be a joined effort and known to everyone. Once that is ready, you have your next milestone – M2
- Rule 5: After every iteration, re-adjust one of the parameters of “The Iron Triangle”: your release valves – functionality vs. effort. This is done after every iteration (between PO, scrum master and some key developers). During the project lifecycle these two items will become more and more accurate.
Presentation of the project organization to the complete team – real example
Once all features are implemented – you have your “beta” release. How long it takes you from “beta” till GA date, depends on various things. Typically, agile folks hate to talk about the “hardening” of beta releases and preach GA quality at every iteration. In on of my future blog posts, I will spend more time on this topic.
Project milestones
What does this mean, and what not?
- In Agile, you still need a good overall planning, and you need to have a product backlog
- Not ALL functionality needs to be known upfront, but R&D has to have a good understanding of all use cases. Agile saves time by having detailed discussion as part of iteration planning, and you are making discussions more efficient, simply because you have accumulated knowledge (through the previous iterations) which you did not have at M1
- PO can ask for a feature to be extended/changed during a project – but he always needs to take into account “Iron Triangle Principle” (hence PO/R&D collaboration is important throughout the project lifecycle)
- Later requirements can be added to the release, but be careful – closer to “beta” date, bigger the risk of adding new things.
- PO defines the ‘What’, The Scrum Team define the ‘How’ and they work together to agree on ‘When’.
- Testers can’t know upfront all detail requirements, but should know all use cases. They need to be on board from day1.
- Any methodology that invites people to collaborate and motivates people to excel must work.
- Frequent inspection and adaptation is the most effective concept in any complex and high risk activity
- R&D and PO in agile context will eventually collaborate, because they are forced to play TIT for TAT with fast feedback cycle. Another phenomena – longer they work together, more they are willing to collaborate. This is well known fact from gaming theory.
- R&D folks gets motivated by feeling truly in charge of things they know the best
- “Control” is achieved by clear accountability for everyone’s work
- Openness allows constructive peer pressure and unbiased norm for the complete team