Posted on

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
Posted on

Project Management Basics

In this and my next blog post I will be talking  about rules of agile planning, based on my experience in agile development and project management. But before I get there, I will need to introduce some fundamental concepts of project management first:

  • “Iron Triangle” (a model of the constraints : time, money, scope)
  • “Cone of Uncertainty” (accuracy of effort estimation vs. time)

At very begging of a release, it is  important to decide which project lever — time, cost, OR functionality—cannot be compromised to launch a successful product.  These three levers are also referred to as the “Iron Triangle.” Fixing time, budget, and functionality is not possible; at least one has to act as a release valve. Decision which dimension is less critical is not the choice of a project manager, but failing to ask PO and stakeholders before the start of the project this question is either sign of lack of maturity or courage. As a project manager, you must have both.


“Iron triangle” and “Cone of Uncertainty” 


Some project management cynics would point out that there is always one dimension more you can “play with” if you get in trouble – and that is quality. Therefore, the best way to evaluate teams and project managers is by checking the quality of the consecutive releases of the same project. (that is also the reason why one-ff CDE projects lack trust in relations –  such projects are always full of SLAs and metrics).

Even with a shared product vision in place, the product’s exact functionality is not always well known up front due to:

  • Technical challenges
  • Customer feedback (which might impact design choices or add extra functionality)
  • Sometimes we need to dig into the surface to learn the true nature of things
  • Sudden change in “market requirements” – which often means new development in the current release (that largely depends on the release lifecycle)

Three main project management practices differ only in how they see a change of the functionality during the project lifecycle.

  • The waterfall model (“mechanical view”, no changes allowed)
  • Spiral development (can cope with change, via prototypes and risk analysis)
  • Agile development (“designed” to allow changes, higher value on adaptability than on predictability)

In agile, it is recommended to fix the time and “flex” the functionality.
Identifying the launch date is facilitated by the product vision – a roadmap, which is something that PO needs to bring to the table. It sketches the future product and describes its target customers. Vision allows us to determine the window of opportunity, the time frame in which the product must be launched to achieve the desired benefits.

Note that choosing the launch date based on the work in the product backlog is difficult, as it forces the team to freeze requirements at an early stage. If that is done too early, it  results in extremely poor estimates. The accuracy of the software estimate depends on the level of refinement of the software’s definition. The more refined the definition over time, the more accurate the estimate – which is a definition of the “Cone of Uncertainty”.

“Walking on water and developing software from a specification are easy if both are frozen.” Edward V Berard

This is exactly where the waterfall guys got this problem wrong, as they have tried to reduce the uncertainty by insisting on detailed requirements too early in process – which resulted in lack of willingness to adopt to later changes, poor estimates and huge waste at the begging of the projects. One more problem which came with waterfall, which I particular dislike was covered in one of my previous posts.

Fixing functionality is a good strategy only when the product lacks some of the key features that competitors already have or if you want to bring something new and really cool on the market.

For instance, the best way to describe two different release planning strategies is to imagine yourself trying to bring a new smartphone on the market:
Either you have to have the phone in the shops before Christmas, as this is the time when kids get new gadgets, or you need to build a new phone with two antennas, as the phone with only one is not good enough.

When it comes to the cost, using stable scrum teams makes determining a budget straightforward—assuming that labor is the decisive cost factor. If you have to scale your project, accurately forecasting the budget is more difficult, particularly for new-product development projects.

If the budget is in danger of getting overrun, the product owner has to make a choice: Either ship with less functionality, or increase the cost by asking more people to join the project—as long as there is enough time for the new project members to increase productivity. But beware of Brooks’ Law: “Adding manpower to a late software project makes it later.”

OK, now that this is covered, let’s get to the real thing, here is my post on agile planning.