Agile planning and the story points approach - Part 02

In the last post post of this series, we have discussed an Agile project management estimation technique, useful when planning in a context of high uncertainty.
The estimation of tasks' sizes using story points.

The concept at the core of the evaluation by story points technique is to estimate activities’ related efforts, instead of activities’ actual durations. Then, as the project progresses, we will be able to transform points into time, using performances achieved in previously accomplished activities.

In this post, we will talk about why this kind of approach works. We will go a little more in-depth, giving evidence of some common pitfalls and solving doubts that typically emerge when approaching this technique.

Why it does work

Relative estimations are easier than absolute ones

It is much easier estimate something comparing it to what we already know, instead of making up a precise quantification out of the blue. You can get evidence of this claim at almost any moment in your life, in which you have to explain something to someone. What would you rather say “Hey Jack, do you know that Tom is 1.76 meters high and weights 97 Kilograms?” or “Hey Jack, do you know that Tom is almost as high as me, and weights more or less the same as Pete?”

Velocity is the great equalizer
The team could estimate its velocity as the average of the number of story points achieved in the last N iterations. It would be pretty useless for the team committing to the implementation of 25 story points in the next iteration if the average velocity achieved in the last 5 iterations is 10. The velocity concept and the averaging operation will smooth out the effect of any unforeseen problem (or luck) that the team may have encountered in performing the job.

Agile teams are, by definition, multidisciplinary teams
The presence of people with many competencies and skills in the team helps in achieving meaningful and reliable estimations. The number of points for one story should not be decided just by an individual. It should come from negotiations and confrontations between all the team members. This approach leads us to the next principle.

The team, not the individuals, commits to a velocity
The work to do, in an Agile team, should be shared by many team members. It is all right to have a specialist in software testing, as long as he/she won’t take care of all the testing. The most skilled team member would probably take care of the more delicate tasks in its specialization domain, but he/she have not to exclude other team members from this kind of activities. Just, in this case, the team can commit to a common objective. Otherwise, you won’t have an Agile team; you will end up with a bunch of professionals, trying to deliver something in their specialization domain without getting in the way of other people.

To have it working

The team composition should be fixed
Team velocity is based on estimations of task’s size and execution performances. Usually, some iterations are necessary to reach convergence and give reliable evaluations. 

As you may imagine, if the team’s composition is frequently changed, there is no way to reach a condition of stability.

Agile teams must be made up of T-people
Since in an Agile teams, estimations are made collectively, and tasks of the same kind are shared among different resources, you need the so-called T-people. That is to say, people who are extremely proficient in a given area of the project, but sufficiently skilled to be helpful in many others.  

You need ants, not tigers
Agile teams must be made up of average performers, who care more about the team than themselves. Do not directly jump to conclusions; you do not need dumb people. You need a well-balanced set of smart people, with comparable performances. Believe me, you do not want to have lone rangers or superstars in an Agile team.

You have to make a transition from the standard project management paradigm
Obviously, if the team has to commit on an objective to be reached in an iteration, all the members should have a certain degree of freedom in selecting the target itself. This approach requires a particular shift in the project management paradigm.

In an Agile team, the project manager must delegate more than in a standard environment. The team must be free to select the tasks to perform in the iteration, balancing the stakeholders’ requirements with the team’s capabilities.

Common pitfalls

Story points have no meaning per se

Story points define the size of an activity related to the other ones; do not try to convert them to man/hours and to redefine activities’ durations. Story points conversion is a dangerous road to walk by. Work with story points and use velocity.

Do not change estimation of past stories
Sometimes you may be tempted to change the points size of some features; maybe because you become aware that a task is much more difficult (or easy) to perform than previously expected. In such a case resist the urge to change the task’s size. Remember, velocity is the great equalizer. The story points and velocity system will take care of such eventualities. If the task to perform is much more complicated (or simple) than expected, you will experience a physiological velocity increase (or decrease) in next iterations.

Different teams’ velocities are meant to be different
Once I hear a project manager saying “Team A is performing better than team B; in fact, team A achieved a velocity 5 points greater than the one obtained by team B.” Dead wrong. Different teams, with different tasks and different estimations probably will have different velocities, but this means nothing. Remember that story points have just a comparative meaning and are subjective from team to team. Do not compare teams’ performances basing on their velocities.

A last comment

If you think that an agile planning approach is not a silver bullet, you are perfectly right.

Agile planning is an extremely useful tool, that should be present in every project manager’s tool bag; nonetheless, you have to select carefully, which projects could benefit from it.

Furthermore, do not forget that also the business environment in which the project lives should be ready to adopt such an approach.

Quest' opera è distribuita con licenza Creative Commons Attribuzione - Non commerciale - Non opere derivate 3.0 Unported.

Project Data and Stakeholders Perception

A couple of days ago, a friend of mine told me he had bought a DVD, as a present for his son’s fourth birthday.

The movie plotted the story of a father, whose wife and children had been slaughtered, years before, by a mean serial killer. Years later, the only son that survived the massacre, who had in the meantime developed a severe motorial disability, was kidnapped during a school trip.

The father started a long journey to save his son, risking his life many times, helped just by a female character, affected by serious psychological disorders.

Obviously, I asked my friend if he had gone nut completely, since last time we met, a couple of weeks before.

He answered me “Why, The DVD’s title is ‘Finding Nemo’, a classic for kids”.

I started to laugh as hell. After some days, I discovered that this was a joke circulating on the internet, even if I am not able to report the source. Still, for some days, this simple joke had made me thought a lot about data and perception.

Data do not lie, or do they?

I am a project manager, but my background is engineering.
I strongly believe that analytical data cannot lie, still, I cannot find a single flaw in the opening joke. 

The presented data are genuine but, of course, something is terribly wrong. I have myself told the same joke to other people, and the result was almost always the same. Who did not already know the joke, did fall into the trap.

Data do not lie; presentations do it

Do you know the old saying “A good liar always mixes up lies with truth?” Well, I think that the best (even if the adjective “worst” would probably fit better) liars always say the truth, just they present it in such a disguise, that you are lead to misconception.

There are two faces of this problem

• Data analysis is hard and complex I have been a professional data analyst for a good part of my career, and I have personally touched the difficulty to understand, without any bias, what data are trying to tell us. It requires hard work, time, dedication, and the will to question your findings continually. Moreover, a strong mathematical background is sometimes necessary.
• Perception is always actively at work The temptation to take shortcuts, even unconsciously, is always present and strong. Why spend a lot of time crunching numbers, when it is crystal clear what we will find at the end? Why can’t we jump directly from A to D, without spend time in B and C? If I had had 1 Euro each time I have seen people failing at reaching right conclusions, out of this approach, I would be rich by now.

Take care of your message

Obviously, there will always be someone, who would try to leverage the two faces of this coin, to fraudulently achieve personal advantages. 

The problem is that, sometimes, even if you are armed with your best intentions, your messages could be, the same, misunderstood.   

When you are presenting data, in order to move people to action, as it is common in project management, you have the big responsibility to craft your message with care.

Because data, they do not lie. What deceives people are incomplete data representations, wrong analysis paths, exaggerated importance to peanuts and minimization of important concepts.

Do not let your audience connect the dots, take them by the hand, and honestly lead them through your analysis path.

Quest' opera è distribuita con licenza Creative Commons Attribuzione - Non commerciale - Non opere derivate 3.0 Unported.

Deliver soon and frequently - an Agile approach to planning

My family and I, live in a minuscule Italian country town. We are lucky enough to inhabit a house surrounded by a private garden, in which our kids can safely play. Our sons are seven and four years old. 

As a side effect, my house is often crowded with children from April to October. In some particular occasion, as birthdays, I have personally counted more than 20 children playing around.

The “Sandwich” project

So, let us imagine preparing sandwiches for 20 kids, following a waterfall approach

• Ask each child what kind of sandwich he/she would prefer (initiation - requirements gathering).
• Put all the needed ingredients on the kitchen table (planning).
• Lay on the table 20 slices of bread (executing).
• Cover the bread slices with the selected sausages (executing).
• Add the selected type of ham (executing).
• Add to each sandwich a cheese’s slice (executing).
• Complete the sandwiches with the upper slices of bread (executing).
• Deliver the sandwiches to your stakeholders (closing - delivery).

The kind of approach described in the previous paragraph is probably the most efficient and organized, to manage the “Sandwich” project.

What is wrong?

If you think that this could work, you probably have never had to deal with third-grade kids. At least not with 20 of them in a bunch. 

When you are ready to enter the executing phase, requirements will start to change. Kids will start thinking that they would prefer other types of sandwich, instead of the one they chose; this typically goes on to the delivery phase.

In addition, as soon as you start to deliver your outputs (the sandwiches) to your stakeholder (the kids), they will begin complaining about the sandwich they chose.

Probably a great part of them will begin asking for the same kind of sandwiches selected by their best friends.

It is a kind of nightmare. 

You will be bound to deal continuously with scraps, rework, out of specifications…and to eat yourself for dinner a good share of your products.

How can agile help?

The answer is easy. 

Start delivering soon, and deliver frequently. 

The fast delivery of finished outputs, at the end of short execution cycles, is a disruptive characteristic of agile project management, as we have seen in an old post. The fast and continuous delivery approach can easily cope with projects, or work packages, in which requirements are not clear or bound to change frequently.

The key here is not to plan recursively; the key is to plan recursively and to deliver, at the end of each cycle, completed outputs, or partial outputs with newly completed functionalities. The focus here is to have, at the end of each execution period, something ready to be immediately delivered to production.

The “Sandwich” project in an agile framework

As an example, let us add a little agility to the “Sandwich” project

• Ask each kid which kind of sandwich he/she would prefer (initiation - requirements gathering).
• Put all the needed ingredients on the kitchen table (planning).
• Start the first delivery cycle
• Lay on the table 1 slices of bread (executing).
• Cover the bread slice with the selected sausage (executing).
• Add the selected type of ham (executing).
• Add to the sandwich a cheese’s slice (executing).
• Complete the sandwich with the upper slices of bread (executing).
• Deliver the sandwich to your stakeholder (delivery).
• Listen to feedbacks (planning).
• Start a new delivery cycle. 

This approach may be a little more time consuming, but in an environment plagued by uncertainty and requirements changes, will deliver the maximum benefits, minimizing the wastes.

Quest' opera è distribuita con licenza Creative Commons Attribuzione - Non commerciale - Non opere derivate 3.0 Unported.

European Cooperation for Space Standardization (ECSS)

The European Cooperation for Space Standardization (ECSS) is an initiative established in 1993, to improve standardization within the European aerospace sector.

ECSS objective was the development of a set of unique, coherent, and Omni comprehensive standards, to be used in all European aerospace activities.

History

Figure 1 shows the main events in ECCS’s history on a timeline.

Figure 1. ECSS history timeline.

The initiative was constituted in 1993, thanks to a joint effort of the European Space Agency (ESA), national space agencies and a consortium of European aerospace industries. A comprehensive list can be found in Table 1.

In 1994, ESA confirmed its commitment to transfer parts of its internal software related standards (the so-called PSS system), to the initial set of ECSS standards.

The first documents were released 3 years later, in 1996.

In 1999, there has been the first tentative to apply ECSS standards on the Mars Express project. The standards were not yet completed and proved themselves to be not effective enough. Therefore, organizational changes at management level followed, and new implementation methods were adopted.

In 2005, a new set of standards was ready and in 2006 started the benchmarking phase, that ended in 2010. 

As today, ECSS standards are a complete, reliable and operative body of knowledge. 

ECSS standards are an evolving entities, so changes are implemented and recommendations incorporated, on a regular basis, as a part of the maintenance and operational phase. 

Table 1. ECSS members

ECSS environment

ECSS standards widely use recognized international norms, and aim at defining requirements rather than means; they describe the WHAT rather than the HOW (we will see soon that the HOW is typically contained in handbooks).

Figure 2. ECSS structure.

ECSS standards’ father is the European aerospace industry, and their mother a group of international space agencies. Therefore, ECSS standards are an extraordinary body of knowledge, which respects and implements high productive norms, from a pragmatic and operative point of view.

ECSS environment, as we can see in Figure 2, is composed of 4 main branches, each one containing standards related to a particular aspect.

• M series - Project Management The branch includes standards related to project management activities. The M branch is about project objectives, quality organization, timely and cost effective execution, communication…
• Q series – Quality The branch contains standards related to the implementation of the project’s product assurance. Standards here contained are divided into 2 main categories. Generic standard dedicated to quality assurance, dependability, and safety. Specific standards devoted to different products type (software, hardware, mechanical parts…). 
• E series – Engineering The branch contains standards dedicated to the definition of the project’s end products, verifying that technical requirements are achieved in conformance with specific industries best practices, regulation, and constraints. The branch is about the engineering of all the parts of an aerospace system (hardware, software, electric systems, electronic devices, mechanical parts…).
• U series – Sustainability The branch contains standard dedicated to the sustainability of the space environment, providing requirements and principles to ensure appropriate and safe space activities.

There is an additional S series of documents, not properly considered a branch. The S series defines the system of standardization documents, specifying how to use them correctly in aerospace projects.

There are 3 main categories of documents in ECSS environment

• Standards Framework containing information about WHAT to do to achieve standardization in a specific discipline (e.g. software) of a given domain (e.g. engineering). Standards are meant to be used in invitations to tender, bids, business agreements, project management, project engineering…
• Handbooks Non-normative documents providing background information, advices and recommendations about HOW to implement a standard. There exist 2 kinds of handbooks
• Best practices and collection of data.
• Guidelines.
• Technical Memoranda Non-normative documents providing information and data on a particular topic, not yet mature enough to be released as a standard or a handbook. 

Different handbooks and technical memoranda may integrate a standard.

ECSS standards

Each ECSS standard is organized into 5 levels

1. Scope contains information about the standard application scope and other applicable standards or documents.
2. Glossary contains definitions of terms and acronyms used in the standard.
3. Policies and Principles general statements of policies and principles to achieve standardization.
4. Requirements required characteristics to satisfy outlined policies and principles. 
5. Annexes Each annex can be normative or informative in nature. They provide guidelines to interpret and implement requirements.

Figure 3 and Figure 4 depicts the structures of branch M and branch Q, respectively, showing all contained standards.

Figure 3. M branch.

Take a look at Figure 3. Gaps in enumeration indicate the degree of evolution to which these standards are subjected. Initially, there were 10 standards, numbered from 00 to 90. Development and changes lead to standards fusion and elimination.

Figure 4. Q branch.

In future posts of this series, we will describe the most relevant standards contained in branch M and branch Q. We will not cover the E and U branches that, even if crucial, cover topics not pertinent to the management of projects.
To find all future posts related to this series, you can use the blog search instrument, looking for the keyword ECSS.

All ECSS standards can be found, read, and downloaded by anyone (European citizens or not) at the ECSS website. The access is open even if a free subscription is required.

Quest' opera è distribuita con licenza Creative Commons Attribuzione - Non commerciale - Non opere derivate 3.0 Unported.

Perception and project management processes value

Perception is a funny thing; this, if nothing, I have learned in my life.

It has never happened to you, to involuntary hurt someone else’s feelings, just by sending him/her one e-mail, which you thought was neutral? On the other hand, have you ever been upset by a friend’s humorous comment, that, in the author’s intentions, was meant to be no more than a joke?

If this is the case, as I guess it is, you know well, what I am talking about.

Different people perceive the same things in different ways. We have talked about that in an older post.

Sometimes this attitude has to do with one’s culture, sometimes with his/her educations, some other times, simply, with temporary circumstances. You just can say.

Therefore, there is no such a thing as an objectively perceived reality, but rather, we have to cope with many different recognized ones. Luckily, this bunch of perceived realities often overlap enough, to grant a sufficient interoperability margin. The only things that cannot be misinterpreted or disguised are objective data.

The same pattern applies also to project management processes.

The dichotomy, here, is about the value that project management processes ensure and the value that the project’s stakeholders perceive. Please, take a look at Figure 1.

Figure 1.

On the y-axis, there is the value that the project’s stakeholders perceive as granted by the project management processes. On the x-axis, we can find the value that the project management processes deliver.

The 45 degrees line is the place where the perceived value matches the delivered one. The line is the project manager’s Shangri-La, the place where he/she will have to place. 

Criticism zone

The criticism zone is the region under the 45 degrees line. In this zone, the value delivered by project management processes is greater than the perceived one.

The stakeholders see the project manager’s efforts as wastes, as expenses to be cut as soon as possible and, therefore, no effective project management is possible.

The project manager has to get out from this zone as quickly as possible, trying to reposition the stakeholders’ perceptions on the equity line. Such an objective is not an easy one. There are no ‘tricks of the trade’. 

The only possible way to reconcile the provided value with the stakeholders’ expectations, is a constant and well-crafted communication, based on sound and objective data.

Esteem zone

The esteem zone is the region above the 45 degrees line. In this zone, the value delivered by project management processes is less than the perceived one. The stakeholders tend to see the project manager as a kind of wizard, an almighty presence with the ability to fix almost everything. 

Even if the permanence in this zone is far more pleasant, than being stuck in the criticism zone, still, the project manager has the due to reposition the stakeholders’ perceptions on the equity line. 

Why? Well, because taking more credit than you deserve is not fair, in the first place; and because, in the long run, it is a dangerous game. 

My grandfather used to say, “A donkey can dress up like a horse but, sooner or later, it will bray”. 

If you regularly fool your stakeholders’ perceptions, what will you do when you will have to rely on those perceptions, and you will find them spoiled by your management style? 

Again, the only possible way out, is a constant and well-crafted communication, based on sound and objective data.

The line

As we have already suggested, the 45 degrees line is the place where the project manager should stay.

Here, the perceived and the delivered value match. 

As we can see in Figure 1, three different zones can be identified on the line.

The minimum zone

The project management processes in place do not deliver great value, but this is crystal clear to all the stakeholders. They know what the project manager is up to, and if they feel like, they can ask for processes that are more valuable. 

Remember that you do not have always to be number one. Maybe, the value you are providing is good enough, for the project at hand. 

The minimum zone is adequate for small projects, characterized by short schedule, low budget, few people and few uncertainties.

The standard zone

The project manager is providing a standard level of value, with the management processes in place. Everyone knows it. No one can argue that the project manager is wasting money or is underestimating the effort required.

The premium zone

The project manager is providing great value, using complex and articulated processes. Still, everyone knows it. If the stakeholders require less effort, they will do it on a real data basis, and not just relying on perceptions. They will know that they are going to trade money with control.

The premium zone is right for big projects, characterized by long schedule, very high budget, many people and many uncertainties.

If you want to be considered a "project management superstar", this is the place where you want to be, not the esteem zone.
Even if, sincerely, my advice is always to provide the value that is required for a good management style, without artificially raising the stake.

Bottom line

Do not pretend to be a horse if you are a donkey and do not pretend to be a sheep if you are a lion. Play fair. Align the stakeholders’ perceptions to the value you are providing. Let the stakeholders decide if you are providing the value they expect from you, on real data basis and not on perceptions. In the long run, this will pay, no doubt about it.

Maybe they will not clap their hands at you, but sure enough, they will remember you when the next project is in sight.

Quest' opera è distribuita con licenza Creative Commons Attribuzione - Non commerciale - Non opere derivate 3.0 Unported.

From Start-up to corporate - Why you still need some "crazy" project

Hi to everyone,

Some time ago, I was asked to give a short presentation during a kick-off meeting, showing to all the project's stakeholders, the reasons why the project had been chartered.

The result astonished me, because, apart the peculiarities of that project, the bottom line message was something more intense that I had expected.

In this post, I want to propose you that message, with a presentation derived from the one I delivered that day. 

From Start-up To Corporate from Emanuele Passera

9 lessons learned about why we need project management

Hi to everyone,

This post is derived from a keynote speech that I held during a conference on Agile project management. The object is 9 lessons that I learned in my career about the need for project management.

This time I prefer to give room to images and slides rather than writing my thoughts. 

9 lessons learned about introducing project management from Emanuele Passera

Which are the agile project management's disruptive features?

Some years ago, an expert program manager told me that agile project management was like sex seen by teenagers. Everybody keep saying that he does it, just a few really do it, and almost anyone does it properly.

I do not know if this was a sentence of her own, or if she had read it somewhere. I can recall that such a judgment, at the time, had seemed to me a little bit too harsh. This before I got involved more deeply in agile methodologies. Now I think that she had been far too indulgent. 

In my experience, what many professionals seem to identify with agile methodologies are just iterative planning, light (or evanescent) documentation, and no strict prescriptions.

These beliefs are wrong. The listed characteristics do not exhaustively describe nor define agile project management. What these so-called agile advocates preach is flexibility, not agility and believe me, flexibility is the wardrobe of hell.

Iterative planning is a part of agile project management, but it also used in many methodologies and frameworks that have nothing in common with agile.

Documentation is so important in agile project management that it is mentioned in the agile manifesto. At the same time, a too cumbersome quantity of documents could be to the detriment of any project managed in whatsoever way.    

Many agile project management methodologies are extremely prescriptive and rigid. As an example, Scrum, one of the most known agile methodology used in software projects, prescribes the team to perform a stand-up meeting each day, like first thing in the morning. Not exactly flexible, do not you agree?

So, what are the characteristics of agile project management, that are disruptive, if compared to standard project management methodologies and framework?

The iron triangle

A project is normally subject to multiple constraints, of which the most famous are Time, Cost, and Scope.

Time, Cost, and Scope make up the so-called “Iron Triangle” and are used, and sometimes abused, as indicators of a project’s success. 

Personally, I believe that more constraints should be included and taken into account, in evaluating a project’s performances. Maybe this argument will be the subject of a future post. Nonetheless, Times, Cost, and Scope are a well-known trilogy in project management and often the only three tools that a project manager can leverage to control a project. 

The Iron Triangle can be deformed to accommodate for project changes or execution deviations from the referenced baselines.

In traditional project management, it is usual to modify Time and Cost as a first choice. Contracts define Scope strictly, and a change in Scope may result in endless and painful negotiations and litigations. 

Therefore, the situation is “fixed” Scope and “variable” Time and Cost. 

Agile methodologies choose an opposite approach.

Therefore, the situation is “fixed” Time, “fixed” Cost, and “variable” Scope.

Commas remind us that this is just one possible approach, that fixed and variable are not strict, and that changes in certain situations can affect all the given constraints.

Let me push this a little further. Agile methodologies are based on the concept of a variable Scope.

Changes in scope are the way in which agile methodologies try to maximize value for the customers, in response to projects’ uncertainty and ever-changing environments.

Scope creep

Changes in scope are the way in which agile methodologies try to maximize value for the customers, in response to projects’ uncertainty and ever-changing environments.

So is Agile project management the glorification of the ever-despised Scope Creep?

No. It is not.  It is not because Agile project management implies a change in perspective.

The scope does not change. The Scope evolves. 

Of course, the scope cannot be left growing out of control; Scope evolution must be continuously monitored and controlled, to ensure that it will provide the greatest value to the customer’s needs. 

To achieve this objective, it is imperative that 

• Customers actively participate in feature prioritizations with the team. Customer must be continuously and extensively involved in the project.
• Planning is iterative and frequent (2/4 weeks).

Servant leader and team accountability

The figure of the project manager is a little bit different in agile methodologies. The project manager assumes the role of a servant leader, who protects the team from interrupts and distractions, always trying to ease the team’s efforts, removing obstacles and solving problems.

The project manager is not the key decision maker since decision are made at the team level, and the whole group shares accountability for them. Some Agile methodology even refuse the term “project manager”. 

The team, not the project manager, is accountable for success or failure.

Relationships building within team members and the team and the customers are at the very core of every agile methodology.

Self-organizing team

From the two previous sections, it follows that an agile team must be self-organized.  

No manager say what each member have to do, nor when he/she has to do it. The team shares any organizational decision, with the project manager as a supervisor.

Obviously, there is the need to have good processes and practices in place, to avoid that this great possibility could lead to anarchy.

People

Not everyone has the characteristics needed to fit in an Agile team, so the construction and the development of a proper Agile team are quite difficult tasks.

We do not need superstars, we do not need people that want to emerge above the others, we just need comparable performers, with real and authentic aptitude to team playing.

A project, in Agile methodologies, is seen as a whole effort made by the team. Any member of the team can participate in any work package (even if agile practitioners do not love this term) and work on any deliverable.

Consequently, so-called “T people” must compose an agile team. 

That is to say, we need people highly qualified in a particular area, but capable (and willing) to participate in work packages even outside their specialization zone.

Conclusions

In this post, we have presented the characteristics that, as far as I am concerned, characterize Agile project management. 

Agile project management is not a silver bullet; it is well suited just for some kind of projects. 

Agile methodologies, in my opinion, tend to perform well on projects with some of these characteristics

•    Small size (Cost and Time)

•    Small teams (no more than 8/10 people)

•    Initial scope not clear

•    High uncertainty

•    Many risks in different areas

Quest' opera è distribuita con licenza Creative Commons Attribuzione - Non commerciale - Non opere derivate 3.0 Unported.

Agile planning and the story points approach - Part 01

We begin with this post a series dedicated to the exploration of a well-known agile planning techniques. The story points estimation method.
In this post, we will introduce some fundamental concepts with the aid of a very simple example. In subsequent posts, we will dive a little more into depth, discussing why this approach works, exposing common pitfalls and, hopefully, answering some doubts.

Let us try a little experiment.

In the middle of a field, there are three swimming pools

• Swimming pool #1    2 meters long, 1 meter wide and 1 meter deep.
• Swimming pool #2    4 meters long, 1 meter wide and 1 meter deep.
• Swimming pool #3    3 meters long, 2 meters wide and 1 meter deep.

Imagine you have to empty all the three pools, one after the other, starting with the smaller pool and finishing with the bigger one, using just a bucket. Every time you pull a bucket of water out of a pool, you must pour it in a well, at one corner of the field. The bucket is known to bear a small defect that will slow down the tasks’ execution, without impeding it. You do not have any clue about what the defect is.

Could you give me an estimate of the time you will need to perform the three tasks?

No. You cannot.

You cannot, because I have not been fair to you. I deliberately have hidden some information that you would need, in order to construct a reliable estimation.

• You do not know how big the bucket is. It may be the size of a mug or as big as a gasoline tank.
• You do not know which the bucket’s defect is and how this will affect the tasks’ execution.
• You do not know how far the well is. You know that the well is at one corner of the field, but you ignore how big is the area. The field could be a 10x10 meters square, or it may be as big as a football court.

A guess about the tasks’ execution time would probably be so much erratic, or its standard deviation of such a magnitude, that the estimation itself would end up to be utterly useless.

Points instead of time

Let us work with what we have. 

We know that swimming pool #2 is twice the size of swimming pool #1, and that swimming pool #3 is three times the size of swimming pool #1. 

Defined X the time required to empty Swimming pool #1, we can state as 2X the time required to empty Swimming pool #2 and 3X the time required to empty Swimming pool #3.

Since we do not have any clue about the value of X, we drop it in our estimations. 

We define that 

• Emptying Swimming pool #1 (activity #1) is 1 a point activity.
• Emptying Swimming pool #2 (activity #2) is a 2 points activity.
• Emptying Swimming pool #3 (activity #3) is a 3 points activity.

Ok, but how much is a point? Velocity is the key

At this point, we can start emptying Swimming pool #1. I have decided to help you in the job. You do not have to thank me for this; I love emptying swimming pools with a broken bucket.

After a very hard work, we realize that the activity has taken us 1 day, or, that is equivalent, we have a velocity of 1 points/days. We can now estimate, using the concept of velocity, activity #1 to be a 2 days activity and activity #3 to be a 3 days activity.

Propagating and refining the estimation

The next day you start emptying Swimming pool #2. Yes, you. 

I feel a little sick and tired of buckets and water. After three days of hard work, you finish this activity too. It has taken longer than expected since I did not help you till the morning of the third day and that, probably, you felt a little tired from the previous days of hard work.

How long will take finish activity #3?
It had been initially estimated as a 3 days activity (3 points with a velocity of 1 points/days), but our velocity has changed. Using the last activity velocity (0.67 points/days), we can now re-estimate activity #3 as a 4.5 days activity. 

This approach may work, but I think it is not a good idea. I will help you in activity #3 and do not forget that tomorrow is Friday. We will have two days to rest. 

Let us estimate our velocity as the mean of the velocities achieved in the last two activities, obtaining a velocity of 0.83 points/days and an estimation of activity #3 ‘s duration of 3.5 days.

Conclusions

In a context of high uncertainty, estimate an activity’s duration could be a daunting task. We could do our best but sometimes, as Christopher Cross would say, it is not enough. An estimation would be so much erratic, or its standard deviation so wide, that the estimation itself would be completely useless.

Instead of guessing and correcting, we could rely on an agile project management concept. 

The concept is to estimate activities’ relative efforts, instead of activities’ absolute durations. 

Then, as the project progresses, we will be able to transform points into time, using performances achieved in previously accomplished activities.

The more we proceed in a project, the more the estimations of activities' durations become accurate, since averaging velocities smooth out particular events, which could have affected, positively or negatively, our performances.

Doubts

In this post, we have presented a widely used agile planning technique, the estimation of activities’ efforts by (story) points. We have introduced the approach by mean of a simple example, and we have investigated how it works.

In the next post of this series, we will talk about why this kind of approach works. We will go a little more in depth, removing some simplifications that I have introduced for the sake of simplicity. We will give evidence to some common pitfalls, and we will try to solve doubts that typically emerge when first approaching this technique.

Quest' opera è distribuita con licenza Creative Commons Attribuzione - Non commerciale - Non opere derivate 3.0 Unported.

What my sons taught me about conflicts management

I am a proud father of two kids.
The elder is six years old, and the younger is three.
They get along very well but sometimes, as you may imagine, they quarrel like two cheetah cubs.

Photo Credit: Smithsonian's National Zoo via Compfight cc

The reason is usually something insignificant, like a disagreement on who has to perform Captain America and Red Skull or the temporary possession of a toy car. Nonetheless, on these occasions, the temperature rises quite quickly, and the situation can easily degenerate into an open fight.

Once, I thought the best way to handle this kind of conflicts, were to stop them in the bud, imposing a pacification that would take into account the reasons of both the children.
I soon realized that this policy was highly ineffective.

The kids ceased quarrelling or fighting, but you could sense that the conflict was not solved at all. You could feel that the fire was hidden under the ashes, ready to burn out again.

Even worse, it seemed to me that my kids were not learning from these experiences and that the more I tried to solve conflicts, the more conflictual situations arose.

The sandbox
The family is a safe environment, a kind of sandbox where kids can learn how to relate to other people. It is inside the family that children make their first experiences managing conflicts, that can arise between them and their brothers or friends.

This kind of domestic workout is a kind of training to the challenges that children will face during their lives. In the family, they can learn how far they can push, in order to assert themselves without breaking relationships. They can exercise managing their rage without emotively hurting other people, to solve problems in efficient ways.
How can they sharpen up these skills, if parents stop these activities, imposing their idea of pacification?

Obviously, I don't mean that children should be left alone to solve their problems, or that quarrels should be let degenerate in open fights. I just believe that it's healthy to a relationship, that conflicts arise and be let flare up a little in a controlled environment. Parents' mediation still is essential but should not be too cumbersome or too stifling. Parents should try to lead the children towards an agreement, but should be the children to decide the terms.

A lesson in project management
I won't go as far to say that a project manager should behave like a father or a mother to the project team; it wouldn't be appropriate, nor there would be the need.

Still, conflicts management inside the project management team is paramount, especially in the forming and storming phases of the team's lifecycle. These are the moments in which team members learn to know each other and start confronting, walking out their comfort zone and stepping into other team members' ones.
These are the most critical circumstances, in which a project manager, with his/her conflict management strategy, can facilitate or impede the transition toward the norming and performing stages. These are situations, in which a project manager, with his/her actions or omissions, can prevent that the team becomes dysfunctional and ineffective.

I would advise adopting the sandbox approach I mentioned before.
Let's not suppress conflicts in the bud. Let's have them to flare up a little in a controlled environment, and let's help people involved to become the actual protagonists of the mediation phases.
This kind of conflict management strategy, based on the empowerment of the people involved, will minimize future conflictual situations and will also contribute to the professional growth of the team members.

Quest' opera è distribuita con licenza Creative Commons Attribuzione - Non commerciale - Non opere derivate 3.0 Unported.

Planning in a changing environment - Does it exist a perfect plan, and does it matter?

Which characteristics should a perfect project management plan possess?

Find an answer to the above question could be a very interesting intellectual exercise, but not very useful. Rather, I think that this activity would be a complete waste of time, not worth the effort. Do you know why?

Because I think it does not exist such a thing as a perfect plan, and even if it did, I won't be very much interested in it, because I would rather prefer a useful plan.

Project plans should be useful, not perfect.

So I believe that a far better question should be 

Which characteristics should a useful project management plan possess?

I mean, there are features that we all consider mandatory in a project management plan, but those features are there to make the plan useful, and not to make it perfect.

Precision vs. truthfulness

I think that we can all agree upon the fact that a plan should be precise to be useful. 

If a plan is too generic, it won't serve its primary purposes, which are planning, monitoring and controlling a project.

Unfortunately, the more a plan is precise, the less is probable; That is why a plan is a simplification of the reality and a single snapshot of many possible interactions within a changing environment.

So we come to a paradox. The more a plan is precise, the more it becomes useful, and the more it becomes false. The objective of a project manager is to find a good balance between accuracy and truth. Paraphrasing the famous statistician George E. P. Box about statistical models, we could say that all plans are false, but many are useful.

Figure 1.

Take a look at Figure 1.
The x-axis represents the plan’s accuracy (moving from the left to the right accuracy increases) and the y-axis the plan’s truthfulness (moving from the bottom to the top plausibility increases).
Each one of the 4 quadrants is divided into 3 zones. The green zones represent areas where the balance of accuracy and plausibility allows the creation of useful plans. The orange regions represent areas where the balance of precision and plausibility leads to the creation of not very useful plans or plans that are not worth the efforts. The red zones represent areas with impossible or absurd balances of accuracy and plausibility.
Let’s dive a little more in the graph and analyze in depth each one of the quadrants.

• (a) Plausibility is preferred to precision. This quadrant is the domain of agile project management methodologies. We have to be ready to integrate our plans frequently with new details and project insights. 
• (b) A plan that is accurate and plausible, this is the project management’s holy grail. 
• (c) Precision is preferred to plausibility. This quadrant is the domain of classic project management methodologies. We have to be ready to change our plans frequently. 
• (d) This is a very strange quadrant. Why should anyone create a project plan that is not accurate and, at the same time, not plausible? Let’s look with suspicion even the green zone.

A way to finding a reliable balance between precision and truthfulness is not to exceed a reasonable time horizon, beyond which planning is no more a process, but it becomes a gamble. This horizon is different from project to project, depending on organizational process assets, enterprise environmental factors, industry, technologies involved...
Fortunately, a project manager has many tools in his/her pocket to build useful and sound plans, like rolling wave planning, division into phases, Agile methodologies and so on.

Plans vs. Planning

In any case, even if we succeed in crafting a project management plan with a good balance between accuracy and truthfulness, we cannot forget that this is just a temporary win. Projects, as we remarked before, are living entities that try to survive in a hostile and imperfect world.
Helmuth von Moltke, chief of staff of the Prussian Army in the second part of the 19th century, known for his innovative methods, used to say that no plan survives contact with the enemy.

So we have to be prone to change our plans. Changes in project plans should never conflict with project charters or business cases. Nevertheless, in order to deliver great values as outcomes of our projects, we must be ready to change, to change quite often, and to change quick.
As a matter of fact, Helmuth von Moltke used also to say, probably as a compendium of the previous citation, that plans are nothing; planning is everything.
We need to shift our focus from the plan to the planning process. 

If it takes too long to adjust our planning documents, we cannot be as effective as we should. So it is not enough to plan accurately in a reasonable time horizon, we also need efficient planning processes running.

Conclusions

We definitively need plans for our projects, and we need to make them precise enough to be useful, but not so accurate to be remarkably unreal. We must be ready to go through well-suited change management's processes, whenever there is a need since planning is at least as important as plans themselves.

Quest' opera è distribuita con licenza Creative Commons Attribuzione - Non commerciale - Non opere derivate 3.0 Unported.

Project management: Do you really need to be No.1?

Some time ago, I attended a very crowded and unbelievable long meeting. It was a kind of mixture between a brainstorming session and a focus group. Suddenly, the discussion remained stuck around this point

"How can we be considered the No. 1 company in our industry?"

I felt quite uneasy about the direction the meeting had been taking, until one of the more experienced and seasoned participants (which I hold in high esteem), said something incredibly interesting. I am not able to report his exact words, so I will paraphrase them to give you just the bottom line. I will write them in cursive to remark the fact that they did not come from me.


Why struggle so hard to be considered No. 1?
Do you think our customers really care about that? Why should they?
People want to make business with other people they trust, not with people whose primary goal is to be considered No. 1.
Let us just focus on business, be proactive and supportive with our customers, create relationships based on trust, be consistent and put all of our energies into our products development.
If someone will consider us the No. 1...well...all the better…but that should not be our primary goal.

An example from industry

In the ‘60s, Hertz was the number one company in the US rental cart market. Avis was second but at a sensible distance. The market share was, more or less, 61% - 29%, and this was a well-known fact by all customers.
In 1962, Avis came out with a brand new advertising, which embraced and leveraged the Avis smaller market’s share and turned it into a point of strength.


The campaign’s bottom line was “When you are only No. 2, you try harder”.
This very simple message was attuned in many different ways in the next 50 years of advertising.
The tag lines changed, but the message remained the same
“Avis can’t afford not to be nice”, “Avis can’t afford to make you wait”, “Avis can’t afford dirty ashtrays” and the reason, they could not afford these things, was that they just were the No. 2 in the market.

The “Try harder” campaign had been incepted by William Bernbach of the Doyle Dan Bernbach agency and turned out to be an enormous success. By the end of 1966, the gap in the market share percentage of the two companies shrunk to 49% - 36%.

Naturally, not being the No. 1 will not automatically make a fighter out of anyone.
“Try harder” requires outstanding traits and attitudes, that one has to find inside himself/herself or to develop within his/her professionalism.
Nevertheless, I do like the “Try harder” message, and I can see a significant advice in the background, a warning to everyone.
If become No. 1 you reach a plateau, and if you are struggling to be No. 1, you are struggling to reach that plateau. What then? Settling down?

I believe that the correct attitude is to keep on running and always try to improve, without the false goal of an arrival point. The goal should be to offer a better service to anyone who trusts you.

Let us shift this approach from a company environment perspective and apply it to project management.
Do we really have to care about what other people think and say? Do we really have to fight against windmills, like modern Don Quixote?

We just need to stay focused on our stakeholders’ needs and expectations, taking care of our projects, keeping our promises, always be present and consistent. Then, if someone will consider us to the best project managers on earth…well…all the better.
We must go straight to the point and keep simple what is meant to be simple. There is no time to take care of what is just garnishment.
We may be not using the latest buzzwords or may be not implementing the last brand new indispensable and how-could-we-manage-projects-before process…but why should we, if there is no need to?

After all, a project manager is not a pure theoretical figure. He/she is an individual placed in the real world coping with an imperfect reality. Do you know what? I believe that the best project manager would be the one taking good care of my projects and showing that he/she does really care about my needs.







Quest' opera è distribuita con licenza Creative Commons Attribuzione - Non commerciale - Non opere derivate 3.0 Unported.