Blog #5

Are you Agile or Fragile?

 3 Jul 2017

Are you Agile or fragile?

Agile is the buzz phrase of the moment and having worked in both Agile and non-Agile development teams, I’ve seen many mistakes made in the transition from an iterative approach to an agile approach. Whilst I will never claim to be an expert in the field, I know a lot about what isn’t an Agile approach to development. So how do so many people get it so wrong?

The Agile Dream

You can understand the appeal. Deliver software faster, with added business benefit, business involvement, and clearer goals. Sounds great, right? And all of it is true. Business users are more involved, they help shape development, they’re kept informed, and at the end of a sprint an application will be ready to release. Documentation is kept to a minimum, and the ability to forecast delivery schedules  more accurately means you can keep your stakeholders happy.

These are the fundamentals of the Agile working practice. And this is where the problem lies. This development methodology is such a cultural shift from the normal iterative approaches that have been engrained within big institutions for so long that they simply aren’t able to commit to it.

The Agile Reality

The reality is that you need to dedicate resource to a project. You need to embrace the cultural shift within the organisation. You need to understand that Agile doesn’t just mean lots of small iterative cycles. You need to allow capacity from business representatives to get involved and own their system.

But ultimately, you need to be realistic. The gains in an Agile project are not found up front – they’re found at the end when you’re delivering high business value software that is fully tested and has had end user buy in from the beginning.


The key mantra within any Agile team I have worked in is “Are we delivering business value?”. This applies at any level from the high level ideas to the work going on within a sprint. Setting sprint goals is key to ensuring that the bigger picture isn’t lost, but also allows the project team to solely focus on one aspect of the bigger picture without interruption. By planning a work story to ensure that you deliver small beneficial change regularly, you'll easily get buy in from the end users.

It’s not done until it’s done

One big mistake I’ve witnessed time and time again is that the focus is all on the development. For example, if a development team needs to create a log in portal for an application, then once the code has been written the piece of work is “done”. However, the work is not done until it’s done. Before this is added to the completed pile, there are questions that need to be asked:

  • Does it meet the acceptance criteria set?
  • Has it been tested both by the project team and by end users?
  • Has the product owner seen this working in a stable environment?
  • Can it be released in its current state?
  • etc.

If the answer to any of these types of questions is no, then the job isn’t done yet.

Other key aspects of Agile delivery are to ensure that you are point scoring deliverable backlog items. And that you only score those that return business value. That way you can accurately plan just how much change you’re delivering to the business.

There will be more work that needs doing, certainly up front, that won’t deliver any business value. Things like Architectural set up, initial skeleton and design work that need to be done but ultimately don’t get you further along the road to delivering your users a better application.

As long as you can deliver some business value within the available capacity of the team, you have a release schedule of what will be included in each release, and the team is focussed solely on achieving this goal then you’re on to a winner.

It’s all in the lack of detail

Another mistake I’ve seen time and time again is trying to figure out the details of everything up front. This really isn’t needed for everything as the whole idea is to maintain some form of fluidity to be able to adapt to the changes that are necessary to meet the end goal.

An idea that sounds great now may not be applicable four months down the line when you eventually get to develop this part of the application and you know more about the end goal. So don’t waste too much time in the specification of that. Focus your time on the things you do know and you need to deliver first in order to provide a user with an MVP – Minimal Viable Product.

Is Agile right for you?

Ultimately if a business wants to make a success of an Agile implementation, they need to be willing to invest in to it. Not just from a business resource point of view, but in embracing the true Agile culture that comes along with it. Things will change, and change is good as long as ultimately you are delivering something that users can and want to use.

If you think of it from a user’s point of view, if they can get their hands on something that although isn’t complete, is workable and can be applied to daily business practice to solve a problem, then that can only get you more buy in for later on as the software matures and becomes more feature rich.


Currently there are no comments. Be the first to post one!

Post Comment