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.

 

Fighter jet, toothbrushing and agile rituals

When I am in position to talk about the topic that is so “obvious” to me while struggling to find the right words to explain it to the others, I often escape in metaphors, looking for inspiration in nature, other people quotes or anecdotes. Agile philosophy is one of these topics, as it has truly become part of my nature – or it probably always was. When I start talking about it, I very often find myself in kind of schizophrenic mood: saying that agile is a flexible but strict discipline at the same time.  At first, it looks as agile methodology is full of controversy, probably because it insists on practices that look conflicting at first sight:

  • It requires strong discipline of all members while it claims that it is a flexible methodology
  • It requires empowered teams and strong leadership
  • Some people (who actually don’t do agile) compare it to a cowboy coding although agile movement has brought so many novel testing practices

So, the real question is: How to find the right balance between stability and agility? 

Let’s start with my first metaphor for tonight:

The new generation of fighter jets have one design feature in common. They are designed unstable, which is intended to increase agility.

High stability and highly effective flight controls are therefore incompatible requirements. In stable aircraft a compromise has to be made. However, no concessions need to be made in unstable aircraft.

Any pilot will find it very hard to control an aircraft like this without assistance. A computer (“fly by wire system”) is needed to provide necessary stability.

Practices such as standup meetings, iterative development, continuous integration, pair programing, TDD, serve as “fly by wire” system in agile. Although most of these practices should be applied to any methodology, there are crucial to agile, without them agile can’t fly. 

Great, it is all good and settled, so let’s check how it goes with one typical agile team during retrospective meeting:

What was I thinking first time my mother asked me to brush my teeth? I can’t remember, but I don’t think I really enjoyed it. Toothpaste doesn’t taste that great and rubbing your mouth with a toothbrush is not that exciting. While I still do it, I don’t think about it any more (unless I try to write some silly blogs) and that is why we call such activities “ritual” behavior: you do some things not really thinking about how and why you do them.

When you start working, no matter where, on no matter what, there will be things you like to do – aaaaand other things. The same is true for other people around you, sure about it. You may say: hey, hold on a second, how about motivation? Isn’t it all about autonomy, accountability and stuff like that? People will just do it, give them some space, right conditions  and things will happen, no? Well, noooo. Doesn’t really work like that – always. You see, some people confuse motivation and toothbrushing, and this is not the same thing. Your job as agile manager is to do both things, keep people motivated and engaged, and at the same time, sometimes, annoy people by asking them to be consistent. That is most of the time hard with things that they don’t like, part of the job that is not natural to their nature. In that case, motivation really doesn’t help, you need to use some other tricks, or like I put it here: “If you want to keep the ball rolling, make sure it is ticking.” In order to create a ritual behavior in the group, you need to do two things: make the outcome of the activity clear to everyone and fix the frequency when this activity is performed. So, let’s see how to do it:

  • Make the goals clear to everyone
  • Make sure everyone understand his/her part in the big picture
  • Give people space, autonomy and accountability (don’t ask folks to play piano with handcuffs around their wrists)
  • Make the checkpoints visible to everyone – such as percentage of the code tested, the number of bugs found in time, logging of activities in tools (in case you have multi site)
  • For each checkpoint define the activity and fix the frequency at which you want to review the results
  • Check the outcomes
  • GOTO 1

 

Tip: you can use the same methodology if you wish to loose some weight or prepare for the next year marathon.