Agile Appearances

Sometimes the best of intentions can ultimately lead to incorrect or undesired behaviour.

This unfortunate chain of events can also be seen in the adoption of agile.

Largely this is caused by concentrating too much of the mechanics of agile, such as Scrum or Kanban, coupled with an unwillingness to let go of past learnt behaviour.

What kind of behaviours or approaches to agile should we recognise as having an admirable goal but flawed execution?

Restricting Communication

A key aspect of agile should be encouraging communication between the people with the skill set and experience to solve problems.

Sometimes this communication will be structured and there is often a necessity for people to manage their time and workload.

But at no time should restrictions be put in place that prevents people who need and want to communicate from getting together and talking a problem through.

This may be seen in only allowing certain things to be discussed at certain times or by placing bureaucratic controls on who can talk to each other and when.

These kind of restrictions often ultimately waste more time than they are designed to save, the reason agile promotes communication is because that is at the heart of every solution.

Only the answers to the simplest of questions are derived by an individual in isolation, every other problem is solved via team work the currency of which is communication.

Ignoring MVP

The concept of a Minimum Viable Product (MVP) is often very easy to pay lip service too without realising its purpose and benefit.

Too often an MVP is seen as something we have to settle for, we want more but are being told its not possible.

This can lead to the definition and delivery of an MVP largely being ignored, either meaning no value is seen to be represented by it or in more scope being included then is strictly necessary to form a delivery.

Shipping software is the whole purpose of the process, shipping an MVP should excite everyone involved not because its the finished article of what we're hoping to achieve but because its our first opportunity to learn if we can deliver value.

Value doesn't scale with the amount of code written or scope delivered, increasing the amount of both these things can also increase the scale of any failure.

MVP should encourage early and frequent delivery it isn't something to define purely to satisfy the development team.

Long Term Integrated Planning

Agile could be seen as the religion of uncertainty, nearly all of its values are related to an acceptance that uncertainty cannot be ignored.

Once an agile approach has been put in place and effective scrum teams are seen to be delivering there is often a strong temptation to plan further and further in advance in more and more detail with the assumption of certainty in the status quo continuing.

This planning is very often undone by users failing to see the value in a release that we were confident about on in the ball of string that can unravel when too many interdependencies between scrum teams are required to deliver a release.

This is not to say that no-body should be thinking more than a few sprints ahead, but there should be an inverse relationship between the time span of the planning and concreteness of the plans being made.

Although it seems like an obvious statement we need to be agile, our planning needs to be fleet of foot with the ability to change when new information becomes available or an unexpected roadblock presents itself.

Agile is not a complicated science with many laws and rules of operation, it is a set of principles trying to promote the behaviours that have been proven to deliver.

Sometimes we can lose sight of this and build up a large amounts of process that ends up stopping us realising those benefits, presented here are three examples of that scenario but always be on the look out for others.