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.

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.

Is it time to go Agile?

“Is it time to go Agile ?”.

This is a very tough question.

Still I think that is not the right question, or more precisely, I think that there are better questions a project manager should ask himself, like “What time is it ?” or “What my project really needs ?”

More or less every project management framework/procedure is based on the old plain Plan-Do-Check-Act model.

There are planning phases in which decisions on project scope and actions are taken, there are moments in which work is performed and checked against what has been previously established and there are control processes to get the project back on track, whatever “on track” may mean for you.

The mode in which these four elements (Plan, Do, Check and Act) are mixed up and sequenced breeds all the differents project management methodologies we know and use in our day to day work.

The selection of the most suitable project management methodology for a given project is not an easy task. It requires great expertise and project insight, a deep knowledge of different project management frameworks and the freedom to choose which road to walk down.

An opinion that I have and that I would like to share with you and submit to your judgment is that the choice of the project management procedure/framework should not be based on the project deliverables type or specific industry (communications, construction, oil, food, software,...) but on intrinsic project characteristics.

Imagine to identify some project indicators and to assess their values for the project you are planning. It would then be possible to place the project in a multidimensional space and select a particular project management approach accordingly.

Figure 1 shows a qualitative representation of a bidimensional project space whose cartesian coordinates are Innovation, intended as the degree of innovation apported by the project and Complexity, intended as the difficulty to accomplish the project overall objectives.

Figure 1

Projects with a great degree of Complexity and Innovation (as those in the red circle marked B) could greatly benefit of an agile approach. These projects are not uncommon to have unclear scope, undetailed requirements, hidden stakeholders and tough and complex planning phases.

Conversely project with a low degree of Complexity and Innovation (as those in the green circle marked C) could be easily managed with more traditional techniques. Maybe even with a plain old waterfall approach.

Projects with great Complexity and low Innovation or great Innovation and low Complexity or other intermediate situations would benefit of division in phases (where each phase may become a project in itself and different phases can be managed with different methodologies), iterative planning, rolling-wave planning and other advanced techniques.

Figure 2 shows a qualitative spider chart of three fictional projects in a tridimensional space that adds Uncertainty as a third cartesian coordinate. Uncertainty is intended as the project overall degree of risk and is reported here to stress its importance to place projects in the proposed space. Uncertainty could be absorbed in Complexity and Innovation and as a matter of fact we can even say that it is a bidimensional function of these 2 variables.

Figure 2

Colors are chosen accordingly to Figure 1. Project 2 should belong to the red circle B, project 1 should belong to Circle C and so on.

Spider chart is an effective tool to display data in the form of a bidimensional chart of three or more variables and this make it an exceptional tool to analyze projects in a multidimensional space.

So if a project manager got stuck leading a construction industry project with a traditional management approach, maybe are the methodology selection process and the subsequent choice to blame and not the methodology in itself. Maybe the placement of the project in the suggested space would have indicated another methodology as more reliable to achieve the given goals.

Conversely I do not find absurd manage a software project with a waterfall approach if the given project has a very low degree of Innovation, Uncertainty and Complexity.

Of course there are also other aspects of the issue to be considered.

Some management options may not be viable because of project management team poor training in certain areas, executives decisions, stakeholders or sponsor explicit requirements and so on. For example it would be absurd for the project manager to select an Agile approach if nobody in his team has not even heard about it.  

Sometimes various options may be clearly unsuitable. Sometimes the use of some process or some instrument is imposed.

Since the choice could be tricky a project manager should maintain an open minded approach, without preconceptions and prejudices. He must understand the peculiarity of the project, the environment in which it has been conceived and in which it will have to be developed. He must understand his team members capabilities and their degree of engagement in the project. He has to adapt to the environment.

So my opinion is that the right question a wise project manager should ask himself is not “Is it time to go Agile ?” but “What time is it ?” or “what my project really needs ?”.

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