Follow Us on Twitter

When to add plan-driven components to agile projects?

by Peter Paul Van de Beek on November 17, 2011 · 0 comments

In this blog post we will answer the question:

When should agile software project management methods be completed with plan-driven components to result in a better software project outcome.

To find the answer we turned to the master thesis of Sjors de Koning (LinkedIn profile). Sjors has performed the research for his master thesis at Whitehorses. This qualitative research he performed is based on a careful study of four cases.

Position in the planning spectrum


The framework that was used to evaluate the cases was the planning spectrum made by Boehm in Get ready for agile methods, with care [2002]. Agile methods like XP and Scrum are positioned on the left while plan-driven methods are positioned on the right. Between these extremes, there are possibly a lot of projects that need a software project management method that is positioned somewhere in the middle.

Boehm and Turner showed that the position in the planning spectrum can be derived from the following five dimensions:

  1. Size of team and project – Boehm and Turner state that smaller teams and projects are the home ground for agile methods. Larger teams and projects are the home ground for plan-driven methods;
  2. Critically – The critically factor is about the impact of the failure of project. The assumption is that when the stakes are higher the need for plan-driven components increases. We’ll see what this research shows;
  3. Culture – Boehm and Turner are among those stating that agile methods are suited in environments that thrive on chaos. Plan-driven methods have a natural habitat in cultures that thrive on order and structure;
  4. Dynamism – Dynamism is the rate of change in a project. Agile methods are believed to be better suited in every rate of change environments whereas plan-driven ones are suited just for low rates of changes;
  5. Personnel – Common sense says that the quality of your staffing is crucial for project success. Boehm and Turner state that agile methods require higher skill levels.

Size of team and project

In the study Sjors tried to validate the following proposition:

When a software project increases in size, the necessity to complement agile software project management methods with plan-driven components increases.

To determine the influence size of teams and project on the need for plan-driven components in agile environments the case were evaluated on the following five factors:

  1. Application size – Source lines of code;
  2. Man-hours;
  3. Project type – A new product, expansion of an existing product, integration of existing products or a repair of an existing product;
  4. Team size;
  5. Complexity – Based on the complexity scale discussed by Ken Schwaber in Agile Project Management with Scrum.

In the study just two out of five of these factors have been judged significant. Both the team size and complexity have a significant impact on the level of plan-driven components needed. Contrary to literature the study couldn’t find a significant and influential impact of man-hours and application size. This leads to thinking that size has less impact on the need for plan-driven components as suggested in literature. We think that current agile methods are more suitable for larger projects than suggested.

Critically

Validating the proposition:

When the stakes are higher in a software project (criticality), the necessity to complement agile software project management methods with plan-driven components increases.

On the dimension of critically the study was looking into the factors:

  1. Loss scale – Four categories: Loss of comfort, Loss of discretionary monies, Loss of essential monies, and Loss of life;
  2. Time constraint – Estimated on a scale of five ranging from Very low to Very high.

Time constraint is not considered significant for adding or removing plan-driven components. However the seriousness of possible loss influences the experienced need to add plan-driven components. This can be attributed to the desire to avoid risk with a high loss.

Culture

The proposition on the culture aspect is:

When the culture is more order and control oriented, the necessity to complement agile software project management methods with plan-driven components increases.

For this part the study looks into the factors:

  1. Organization type – Based on Collins Good-to-great matrix;
  2. Company growth stage – Based on Greiner’s growth stage;
  3. Trust – A six point scale ranging from Distrust to Complete;
  4. Organizational culture – Based on Moore we use the categories: Cultivation, Competence, Collaboration, and Control.

The factors Organization type, Trust, and Organizational culture were found to be significant. The significance of the fourth factor company growth stage could not be determined. These findings correspond with literature. It became clear that the dimension Culture is one of the most important influencing the amount of plan-driven components used. This was confirmed by several of the interviewees.

Dynamism

Dynamism is about the rate of change in a project. In order to rate the change in a project the Cockburn dynamism scale was used to test the proposition:

When there are high rates of change (high dynamism) in a software project, the necessity to complement agile software project management methods with plan-driven components decreases.

The dimension was measured on just one factor – the Cockburn dynamism scale (Wildly fluctuating, Varying and Relatively stable). It was found significant. The agile approach is a good answer to wildly fluctuating requirements. In other words high rates of change decreases the necessity to add plan-driven components.

Personnel

The proposition on the personnel aspect:

When project personnel has low/medium skill levels, the necessity to complement agile software project management methods with plan-driven components increases.

To test this proposition the study looks into the following six factors:

  1. Extended Cockburn method skill rating scale
  2. Experience
  3. Education
  4. Project manager type – Here we distinguish four basic leadership types: Autocratic, Bureaucratic, Laissez-faire and Democratic;
  5. CRACK customer – Well score the customer on the aspects: Collaborative, Representative, Authorized, Committed, or Knowledgeable;
  6. Project personnel turnover – Change rate and role changes in the project team;
  7. Familiarity with the technology.

The factors Skill level and Project manager type were the ones that significantly influenced the amount of plan-driven components. The study didn’t find significance for the other factors to determine the usage of plan-driven components.

Five recommendations

Based on the finding in this research we recommend:

  • If there is high uncertainty (high dynamism) about the requirements, the software project manager should try to make the software project management method as agile as possible;
  • If the skill level of the project members is low, the project manager should add plan-driven components to ensure quality and structure. If possible however, the project manager could also replace the lower skilled members with higher skilled project members in order to be able to work more agile which should be beneficial for the project;
  • Complexity can not always be reduced with plan-driven components. An agile approach is useful to tackle the complex problems with small steps;
  • In case of a high possible loss if the project fails the amount of plan-driven components should be increased to provide more security;
  • In case of a control culture at the client, consider using an agile approach like Scrum internally for the development and communicate (externally) using a more formal plan-driven method like Prince2.
When to add plan-driven components to agile projects?, 4.5 out of 5 based on 2 ratings
Ratings:
VN:F [1.9.22_1171]
Rating: 4.5/5 (2 votes cast)

Leave a Reply

Your email address will not be published. Required fields are marked *

*

* Copy This Password *

* Type Or Paste Password Here *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

 

Previous post:

Next post:

About Whitehorses
Company profile
Services
Technology

Whitehorses website

Home page
Whitebooks
Jobs

Follow us
Blog post RSS
Comment RSS
Twitter