New YouTube video: (Part 2) Are you really doing agile software development?

The second video in our series of “Are you really being agile” is now online.

This bitesize video follows on from our successful first agile development video, in which Doug Michael analyses ways in which organisations may misconstrue the agility of their projects.

It also offers advice on how to make projects truly agile, and the benefits this brings.

If you’ve not seen the first in the series, please view this first as its better to watch them in order.

The video is now here…

If you’d like more information, please contact us – and do feel free to comment on the video and share your thoughts on this topic.


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

Agile thumb

Watch the content of this blog on YouTube

Welcome to part two in our series of blogs about whether organisations are REALLY following the agile methodology when they claim to be.  In the our first blog (read here first, if you’ve not already) we looked at two of the scenarios in which agile techniques are misapplied.  Remember, you can watch all this in our YouTube video available here.

In this post, we look at another two.  Next time, we’ll look at three more, but for now…

Misconception 3: Scrums and sprints define Agile

1Agile 2.2

A familiar diagram

One of the most well-known features of an Agile project is the daily scrum meeting.

We have encountered several organisations which claim to be ‘doing Agile’ solely on the basis of having implemented the scrum meeting technique into their process.  But of course Agile is about much more than this.  Scrum meetings can take different forms but in the most common we ask three key questions:

  • What have you done since yesterday?
  • What are you planning on doing today?
  • What  –  if anything – is stopping you from achieving that?

The purpose of these questions is of course to make sure that everyone knows what everyone else is doing and to ensure that blocking issues are dealt with.  This is essential for an agile application development project with a fixed timescale.  The scrum meeting is very useful, but it’s important to recognise that it is just one part of the Agile process.

Misconception 4: you can use it as an excuse

Often, Agile can be seen as an excuse NOT do a whole host of necessary processes – for example:

  • not writing a proper specification
  • not writing documentation
  • not using the appropriate tools
  • and not sticking to plans
Agile 2.2

Agile is not to be used as an excuse for not doing things properly. Watch the video for more.

It can be viewed as a bit of a free for all – but at Jumar, we believe that all the above are necessary. Just because the Agile methodology allows you to change the scope during a project doesn’t mean that you don’t need to know what you’re building when you start or that you don’t need close, formal control.

When you start an Agile project, we believe that you should have a clearly defined scope, a specification and a detailed plan.  The difference with Agile is that you EXPECT change during the project and the approach accommodates for it.

Next time: user demonstrations, testing and priorities

We’ll be publishing our next YouTube video very soon covering these very topics.  Watch out for the blog version too, coming over the coming weeks.

Like to know more?

Please contact us here.

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.

New YouTube video: Are you really doing agile software development?

Doug Michael - CTO, Jumar Solutions

Doug Michael – CTO, Jumar Solutions

Often the subject of intense debate, and also regularly misunderstood, the “agile” approach to software development is a subject upon which people get rather animated.  There are all sorts of misconceptions about agile – many fuelled by organisations which claim to be doing agile, when they’re not.

Jumar’s CTO, Doug Michael, is no stranger to agile – and has lived it for many years.

In the latest in our series of YouTube videos, Doug examines the differences between agile and other more ‘traditional’ methods of software development, such as waterfall for example.

He then goes on to look at the mistakes made by organisations who claim to ‘do agile’, specifically, their attitudes to

  • fixed timeboxes
  • sprints
  • scrums

…and how these should be carried out properly in order to conduct a truly agile process.

The video is the first in a series of two YouTube presentations focusing on Agile.  Part two will be made available later in the year.  For more information about Agile Software development, please contact us.  If you’d like to speak to Doug directly, please also drop us a line, and we’ll be in touch.