What is Planning in Agile development?

In classical projects, the primary focus is generally scope – what we are making.  There is a target to achieve.  The project is created to achieve that target.  A team is then built around the project.  The team and the goal are then used to derive a timeline or schedule. 

There is some level of trade-off between the three elements of scope, team and schedule.  Sometimes this is referred to as the “iron triangle”.  The name relates to the interrelatedness of the three parameters.  Increase the team size for a fixed scope and the schedule will generally reduce.  Typically in a classical environment, the scope is fairly tightly defined. We set up the project to achieve a specific goal. As a result the other two are free to vary to some degree.

If a classical project can be split into milestones these will similarly be built around a specific scope.  The environment is complicated, not complex.  Therefore it is viable to deconstruct the problem to find all of the tasks and activities required to achieve the goal.  These define the scope for each milestone and the total project.  By assigning a team and estimating the work in the tasks, we can predict a timeline.  With a classical project we then schedule each individual task on the timeline and predict when each task will start and finish.

If we are to work in an Agile way, we need to approach planning and tracking differently.  Development is seen as a continuous process.  It is not split into projects which start and stop.  As part of its continuous nature, the teams are expected to be fixed and stable, not created for individual projects.

We bring the work to the team,
not the team to the work.

Timeboxes

Agile development tends to work best in fixed timeframes or “timeboxes”.  Typically there will be a release point for which the date is communicated well in advance.  This is often a requirement for customer expectations and is part of building a roadmap for the product.  The steps on the way are not milestones with fixed functionality, they are reference points with fixed schedule. They can include stages in delivery such as customer releases.  And at a finer grained level they are part of the development process, as iterations.

As the team and the schedule are fixed, your flexibility comes from scope.  As we are working in a complex environment, our planning has high uncertainty which cannot be reduced.  Therefore we need enough flexibility using scope as our primary degree of freedom. We cannot fix all of the parameters and still expect to deliver.

Communicating planning

Our scope is represented primarily using backlog.  This contains all of the work which we wish to do, in an ordered backlog.  We use this approach deliberately to manage and support a high level of change.  As the priorities change, we use backlog refinement to respond.

We need to balance the flexibility from backlog with the need to communicate.  This sets up a natural tension within the organization.  Development groups need to maintain flexibility and manage the complex environment.  External stakeholders value predictability and knowing what will be available at what date.  This can drive the two groups apart.  Open communication is key to the interaction between the parts of the business.

Engineering groups are surprisingly opaque from the outside.  Often those on the “inside” are unaware of how hard it can be for stakeholders to understand what is happening.  The communication gap between the developers and the wider business is a common source of tension.  Typically as a leader you will be aware of who is working on what.  You will be clear about how each is progressing.  And you will have a good picture of level of predictability, including the risks and mitigations you have in place.

As a leader in an Agile organization, you will need to ensure open communication around the business.  A specific challenge here is to explain your plan and progress.  This is made more complex when your audience is unware of the details involved in development.  Generally they will have at best little understanding of Agile.  At worst this will be a misunderstanding of Agile – there is a lot of confusion around the topic. 

Any reporting which they have met in the past is likely rooted in more traditional project management.  You will need to develop a language and approach for planning and tracking which is standardised and understood outside the development group. 

Many Agile leaders don’t focus on that external interface.  Sometimes instead they respond by resisting this pressure.  They may feel that it is too difficult to get an accurate representation of status.  I have often heard the argument that because Agile development is aimed at complex environments it is fundamentally non-predictive.  The message from many teams is then “it will be done when it is done”.

Engaging the organisation

As we have discussed it is true that complex environments are not fully predictive.  However, this message increases the tension between different parts of the organization.  It is a counterproductive approach to resist this external pressure.  You want to encourage people to become stakeholders in your development work.  You do have a choice about how you interact with the wider business. 

• On the one hand you can have an active, engaged organization which supports your developers. 
• On the other, you could have one which ignores what you create, except perhaps selling it when it appears.

Given that choice, I know I would prefer engagement.  We can create a method of planning, tracking and reporting which is based on Agile principles and has value.  It is true that open communication has consequences.  The engaged organization will inevitably be difficult to manage.  They will argue about priorities.  This includes being dissatisfied with progress.  And yes, I would expect they will have unrealistic expectations. 

These all show they care about the work.  This is far more valuable than an organization which is disengaged.  A disengaged business will typically result in less pressure during development.  However, it will inevitably lead to far more dissatisfaction with the outcomes.

In a successful technology company, the technology is at the heart of the business.  That’s not to say that everyone has a technology background.  Many of the successful technology companies do have chosen leaders with technology backgrounds.  It can certainly help many situations.  I have been at a company where every senior manager had been a hands on developer.  I know that makes it much easier to explain some complex situations.  More critical however is that everyone understands the product or products and knows their role in developing, promoting or selling it.  If stakeholders are excluded from this, they will integrate poorly with developers.

Plans and Gantt charts

We have looked elsewhere at the importance of a common language for how we communicate within and outside the group.  A common language is equally valuable when we are discussing planning and tracking.  We need to find a way to understand plans and progress and communicate these.  And whatever approach we use, we need that approach to work for those doing the development as much as for stakeholders.

As part of the language, we should consider what a plan “looks like”.  In a classical project environment, the standard “language” often used for a plan is a Gantt chart.  This widespread tool shows work items laid out on a timeline with start and end dates.  Strictly in classical terms this would be referred to not as a plan but a “schedule”. 

However, Gantt charts are poor representations of Agile work.  Gantt charts are built for the idea of fixed scope.  They work best when the work is strongly sequenced, with the date when an individual task occurs being important.  In construction, for example, you may book up a team to lay flooring.  And that team is assigned a specific calendar week to lay that floor.  In Agile development however, there is rarely an impact from which specific date a task is executed.  As a result, assigning dates to tasks and checking if they occur at those dates is an unnecessary overhead.

Good practices

Firstly we need to ensure the organisation understands good practices around timeboxes. Development should be planned with fixed timeboxes. This then means that there will be variable scope.

To understand scope and priorities, we should focus on the backlog. As we have discussed, this needs to be clear and public. Change should be managed through backlog refinement to ensure everyone has the same clear understanding of the priority and sequencing.

As an Agile leader you should focus on how to communicate status to the external organisation. This will allow you to build involvement and engagement.