Agile Planning

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.
Why and when is agile so successful? – my philosophical view
  • 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

2 Replies to “Agile Planning”

  1. Nice post Veselin — I’ve enjoyed reading your experiences and advice on Agile.

    How long is a typical iteration? If you spend 20-30% of the full release cycle on scoping and effort estimation with spikes and etc, does this span multiple iterations?

    1. Hi Jim,
      great to hear from you! Our release cycles are about 8-9 months, which is something typical for b2b environment. If nothing else, if you release your software more frequent, and you have customers that expect fixes for 3 years at least, you would end up with huge maintenance cost after a while. So, what I typically do is to allocate about 6-8 weeks for project preparation, and this is the time to run workshops and think/brainstorm about new big features. This is also the time we try out some new frameworks or do some major refactorings if needed. Spikes can span multiple iterations indeed, and they are not necessarily tight to planning of any release in particular. It is more like scouting … You pick up one or two guys and ask them to come back with some facts before you make any decision.
      What is also important to note is that we never stop with iterations, the only difference is that the convergence or dynamics change over time. The good practice is to always use the same iteration span over the complete release, and that you always insist on people being prepared for discussions.
      So, in first iterations people would get some big features to work on, but already at the next iteration they would show drawings (we capture with the phone camera stuff from the whiteboards), present wiki page etc…Typically, I would assign few guys for some big features during preparation time.
      You don’t need to do this for all features before M2, and this is a trick, only for the ones that you really find complex and risky. I see too often new teams doing crazy stuff, splitting and estimating stories for weeks not doing anything else. By the time they are done, you end up with like hundreds of stories where people don’t know where to start. That is the reason I like story mapping blog from Jeff Patton. i do exactly the same.
      When it comes to the question of how long iteration should be, I prefer short ones of 1 week, but 2 weeks is fine too. I see iterations as your correction points in time, inertia of your system if you like. Bigger the projects. more people you have, longer it takes to align everyone and to make a proper preparations and planning. Shorter cycles have one drawback though, it can lead to too many meetings and discussions. That is the reason I coach teams to come with good agendas prior to the meeting, otherwise it is huge waste.
      hope it helps,

Leave a Reply