When is Agile not Agile?

ImageI presented yesterday at the annual Australian Computer Society (ACS) conference in Canberra on strategies for implementation of new media. In the breaks, walking around and chatting to people, I discovered that many organisations are taking the leap and adopting Agile methods to help speed-up delivery of their own projects. But what I learned about how many projects are proceeding on this path made me quite sad as an agilist.

Design before development is not Agile

If the developers are doing agile (ie: using extreme programming) and the designers, BAs and user-experience guys are working (or have worked) up-front, the project is not Agile and neither are its developers. Agile demands a multi-disciplinary approach. Agile also requires a highly collaborative approach. It means everyone working together to complete smaller pieces of the project, delivered in an order that reflects its inherent business and user value.

Serial team work is not Agile

Serial work is just another name for Waterfall. Getting one BA to do a large requirements document, and then another BA to do the Use Cases afterwards is not Agile.
Agile, specifically Scrum, requires the team to work together on the same products at the same time. In essence, they work in parallel doing analysis, design, development and testing all together. They plan this work together, they declare what they can commit to as a team for the specified time of the Sprint. They spend time together refine the backlog. They demo their completed products together to the Product Owner. They have retrospectives together.

Three months is not a Sprint, its a marathon!

Sprints are short, highly focussed, time-boxed periods of collaborative work for the team. The sprint must be short enough in length for the team to adequately understand what they can commit to complete in that time period — too short a time and the team simply won’t have enough time to get things done, but too long a time and the team won’t be able to adapt to estimate what they can actually complete or adapt to changes in requirements or adequately estimate what they can complete within that timeframe.
If it’s important in the project to have significant timeframes for planning and reporting, use Prince2’s Stage Boundaries to help quantify the scope in terms of epics, plan architectural needs, and epics as the milestones. Then, use 2-4 week timeframes for the Sprints to plan and execute the needs of the Stage.

A team of 20 is not Agile

With larger teams comes the need for more communication to create a shared understanding of requirements. In large teams collaboration can suffer as a result. If you’ve got only a few team members there’s typically not sufficient enough different points of view for the team to be multidisciplinary and address all of the needs of each product in parallel work.
If you have a larger team population, try instead to operate using what is known as a ‘Scrum of Scrums‘:

  • Break the larger group down into smaller teams
  • Extend Sprints from 2 to 4 weeks to enable the smaller groups time to cross-collaborate in ‘virtual teams’
  • Increase the level of standardisation and baselining of the architecture and user-experience by adding crtieria to the Definition of Done so that the end products work seamlessly

Doing stand-ups alone is not Agile

Stand-ups are a great time for the team to meet and report to each other on what they’re up to and seems to be a common first step in adopting agile methods. It’s also an important time for the Scum Master to learn what’s going on, understand the progress of tasks based on what the team commited to during Sprint Planning, and see where they can step in to help the team achieve its goals, remove impediments to work, and assess upcoming risks in order to mitigate their effects before they hit the team.
Just because you are doing standups, however, doesn’t mean the team is agile. It just means good communication.

How to become Agile

1. Stick to the agile manifesto’s philosophies

The Agile Manifesto is the best guide to becomming agile and taking your first steps. While the origins of agile are not new, the manifesto represents a set of principles that articulates what agile is today. If you want guidance as to how to apply agility to business projects or products that are not software (and that’s something we’ve done a lot of lately) just assume that ‘working software’ = ‘high-value products’.

2. Get a (Scrum) Coach

There’s a great episode of the Big Bang Theory in which Sheldon Cooper notes that he knows everything there is about swimming — you see, he read a book. Swimming, though, requires you to jump into the water and learn by doing using a qualified teacher.Even great olypmic gold meadalist swimmers, like Ian Thorpe, have a coach to help them become better at swimming.
The analogy is fairly simple, but it suits agile methods. Agile methods are for many people new behaviours to learn. A Coach spends time with their teams, the Product Owner, and the Scrum Master to help them learn the right behaviours that will increase agility and identify and remove behaviours that adversely impact on agility. This independent observer often means the difference between success and failure for new teams learning Scrum for the first time.

3. Don’t just ‘do’ Agile, pick a methodology and stick to it

Scrum is by far the most popular and widespread of the Agile methodologies. It’s a fairly simple process, but that simplicity requires an immense amount of discipline in order to stick to its ‘rule of three’ and achieve results:

  • Three roles: Scrum Master, Product Owner and Team. There is no role of BA, or tester, or designer, but there certainly are tasks the whole team have to do in order to analyse, design, code and test their products
  • Three products: Sprint planning, daily scrum (stand-up meetings), and sprint review.
  • Three artefacts: Product backlog, sprint backlog and the burn-down chart.

If you want to become Agile by using Scrum, these are mandatory requirements. If you’re not using these then you’re not doing Scrum. Some would even suggest that as a result you’re not agile.

4. Be iterative, but not at the cost of delivery

I’ve seen many teams who iterate their concepts rather than deliver whole, completed and tested products at the end of the Sprint. The Agile Manifesto, though, reminds us to focus on working product at the end of each Sprint. Ensure that a product is delivered, in totality, and meets the Product Owners acceptance criteria (ie: Definition of Done), and then leave the Product Owner to decide on whether he wants something else in that Product before the next iteration occurs in the next Sprint.


Seems everyone is getting on the Agile bandwagon and for good reasons — Scrum in particular (my favourite methodology) can bring significant savings to an organisation, but it does come at a cost and that’s by unlearning old, traditional project management ways of working and adopting new approaches to work. Only by giving up what has been learned can you reap those rewards.

3 thoughts on “When is Agile not Agile?

  1. Good luck trying to field a MMORPG or Streaming Video network or other high availability SOA with no design up front.
    Thanks for sharing your opinions of what you think agile is, with it’s implicit caveat’s for those that need to deliver real world product 🙂

    1. Hi Jordan
      Thanks again for your comment.
      Having done some MMO work in the past, I can see your point. However, the ideation stage of the aesthetic and character design I would argue is not actually part of the project execution, but part of the strategy. This does occur upfront before the project begins. I’d never start a project without someone having setup the strategy which often includes some analysis and design work.
      My suggestion is only that, once the project initiation/setup phase is completed, having a designer work a sprint ahead of the developers in my experience is wrought with many problems and is counterintuitive to the agile manifesto’s philosophy of collaboration.

  2. A good point Jordan. I had completely forgotten to go back to the agile manifesto. I’ve now added that in.

Leave a Reply

Related Posts:

“Netiquette” for online meetings for remote and distributed teams

As with face-2-face meetings, online meetings also have an etiquette (“Netiquette”) to make them effective. One of the 12 principles of the agile manifesto suggests face-to-face is the best option but in today’s world of social distancing and WFH, it is no longer an option.

Here are the guidelines we have found useful for having for online meetings with distributed


22 Stances of a Scrum Master

The Scrum Master doesn’t remove impediments from the team. Their job encompasses 22 wider stances for supporting the team to self-organise to remove impediments themselves, coaching the Product Owner and coaching the wider organisation.


Does agility go out the window when we work remotely?

Many organisations are making guidance on what tools to use for remote teams in response to COVID-19. The situation isn’t a tools problem. This is a people problem – how can people, who are social creatures, successfully work remotely without physical interaction?


Copyright © Zen Ex Machina® and ™ (2019) All rights reserved. ABN 93 153 194 220

search previous next tag category expand menu location phone mail time cart zoom edit close