Agile software development – it’s more than just sprinting and scrumming (Part 1)


Agile – is there REALLY a lot of it about?

If you Google “Agile Methodology” you’ll get just short of three million results.  There’s clearly a lot of it about.

Well, actually, there’s a lot LESS than first impressions would have you believe – and there are a lot of people who think Agile is something that it simply isn’t.

And that’s the problem.  Lots of organisations claim to be ‘doing agile’ when, in reality, very few are.  Many are doing something they consider to be agile software development, but which could not be further from the truth.

Agile thumb

Watch our YouTube video for more on this subject

This blog post covers some of the points raised in our recent YouTube video “Are you really being agile?” (which you can watch here) – and is the first in a series of blogs covering common misconceptions about Agile.

We regularly hear people saying that agile doesn’t work – or it’s not appropriate for a particular situation – when in fact it’s just not being used effectively.

And that could mean missing out on the many benefits that a truly agile project can bring.

Before we look at the misconceptions – a recap

First – a small trip back to the drawing board, and a look at the biggest differences between agile and ‘traditional’ methods of software development (waterfall seems to be the most commonly quoted).

The three key elements of a project are:

  • time
  • resources
  • scope

In the ‘traditional’ model, it is the scope and resources which tend to be fixed.

Agile 1.1

Traditional methods mean scope and resources tend to be fixed – with time as a variable

Any change in the project which increases the scope means it’ll take more time.  Quite understandable then, that change is feared in this scenario, as it will add delay.

In the Agile model, however, we have exactly the same parameters, but it is the TIME and resources that are now fixed.

Agile 1.2

Agile approach: Resources and time is fixed, so high-priority items are included, and lower priority items form the next project.

Scope is, therefore, the variable – and it makes provision for the fact that change is EXPECTED. This methodology, therefore, allows for change – and in fact, encourages change.

Misconception 1: Agile automatically works for everyone

So – back to the plot.  How does this relate to misconceptions made by organisations claiming to ‘do agile’?

Agile 1.3

Manage expectations: ensure all stakeholders buy in to the agile concept

The first issue, surrounds ‘people’ – and by this we mean the entire team of stakeholders involved in the agile process.  We know that the time is fixed – as are the resources.

So, when feedback leads to new features being introduced, it is inevitable that lower priority items will no longer fit into the timescale, and will go onto a wish-list for a future release.   Everyone involved has to accept this – and unless there is buy-in for this concept, it could be viewed as a negative.  And this regularly happens, as users who are familiar with the traditional approach, expect the new features AND the old, and are unwilling to let anything drop out of scope.  If one gives into this pressure, the project is no longer agile.

We combat this by always holding detailed upfront sessions with users to make sure they are familiar with the benefits of agile – especially the fact that it allows a predictable timely delivery based on prioritisation of features.

Misconception 2: It takes all sorts

It’s vital that the correct personalities are involved in an agile project.  This includes not just the techies, but also the non-IT stakeholders.  For agile projects to be really effective, they need to be staffed with individuals who want to prove something, and who thrive on the challenge of working to produce the best possible result to well defined timescales.

It’s simply not for everybody.

Next time: Misconceptions 3 and 4

In the follow-up to this blog post, we look at scrums, sprints an excuses.  Following that, we’ll go on to discuss failures to manage user demonstrations, and ways to get quality feedback.  We’ll examine problems with prioritisation and failure to build testing into the process.

Want more?

In the meantime, if you’d like more information about any aspect of Agile, please contact Jumar.


Legacy modernization software has a new look – Project Phoenix gets a makeover

Phoenix box device small

Project Phoenix’s new look

Always keen to practice what we preach, we have modernised our modernisation software, with a brand new look.

Project Phoenix (Jumar’s legacy modernisation and re-platforming suite of software) is a collection of automated tools and services which enable legacy applications to be re-used if the business rules are still valid.

Project Phoenix itself is constantly evolving to meet new and more complex challenges, so as part of this, we have given it an all new look and brand image.

For more information on  how Project Phoenix…

  • Automates modernisation of systems
  • Supports new application styles , interface and architectures
  • Reduces time, cost and effort
  • Reduces testing cycles through increased accuracy
  • Allows accurate project planning and estimating
  • Harvests existing knowledge and functionality

…please contact us.