Skip to content
11 June 2010 / Chris Neal

Just doing a standup doesn’t make you agile

Have you ever been on a project that thinks it is agile but isn’t?



Me too. And it really hacks me off. Project agility is not something you can just switch on. You (as a team) have to want to do it and have to practice at it to get it right.

Here are some telltale signs for when things are not quite as they should be:

1. Ceremony without purpose.

Daily stand-ups are a hard thing to get right and some people just don’t get them. They are not there to have a chat about coffee, focus on about long complicated issues.They are not run for the benefit of the Project Manager (or ScrumMaster) – they are for the team.

They are there to:

  • Share commitment.  This is crucial. This is when you all commit to the goals you will achieve each day. It’s not a time for “I’m hoping to…”, it’s “I will…”! If that sense of team commitment is not there, or uneven across the team, things are likely to slip.
  • Give a real-time status update.  Where are you up to, did you achieve the goal you set yourself yesterday?
  • Identify potential blockages. Developing software is rarely plain sailing. Identify potential blockages early, and as a team work out the best way to overcome them.
  • Set direction and focus. What do we need to focus on next? If your lucky enough to have a small team, with your backlog on the wall nearby and your sponsor at hand – this should be easy. But it is surprising how often teams can lose focus, or get distracted away from the goals. If your Product Owner is not available this is where the PM or ScrumMaster should have a more prominent role, ensuring the team stay focussed on the immediate priorities.
  • Build a team – To me this is the second most important part of the meeting. It’s the team that needs to deliver the software, and it’s the team that needs to actively participate in the stand up. The best stand-ups I have been involved tend to have the following characteristics: everyone is involved, no one person dominates or leads, people come prepared, the team collaborate on issues/blockages, and they are over quickly!

All too often you can find the stand-ups becoming routine and mundane. When this happens look at how you are running the meeting and concentrate on why you are doing it and how you can keep the energy and commitment high.

For those who want a more information Jason Yip’s great blog post gives some really good information and advice.

2. Your Product Owner has gone missing.

This is probably one of the most common problems with Agile projects. Organisations start off with good intentions, but all too often the people who can contribute most to the project and drive the priorities, aren’t given the time to do it. They then turn to assigning Analysts or Project Managers to the project to fill in the gaps. This rarely gives a good outcome.

I’m not saying that you need someone on hand 24/7 but it is  essential that you have someone who deeply cares about the success of the project directly involved. This is crucial at the start, when defining the backlog, but throughout in setting and re-evaluating priorities, reviewing progress (demos or release walk-through) and in being the person the team negotiate with if and when things slip or priorities change.

There’s a lot of debate about what makes a good Product Owner. To me it’s simple. They are the person that cares, the person that is charged with making the initiative a success. If you don’t have good access to someone empowered to make priority calls, define what really matters, you are much less likely to succeed. From the outset you need to be realistic about how much time this may take, and this should be factored into the decision process to start the project.

3. I’m done is not good enough

When is a feature done? This might seem a stupid question but it still surprises me the frequency in which teams still try to set a feature as being “done” too early.

It’s not done when just the coding has been done.

It’s not done even if it is sat in the test environment and the tests have passed.

It is only done when the Product Owner or business sponsor or person that cares says it is done.

That means coded, unit tested, system tested, deployed, demoed and accepted.

OK we are all clear!

4. The magical self organising team

This is one of the hardest things to get right and sometimes this never happens. A true agile team works together to achieve the Sprint goal. They have a single purpose, they collaborate and resolve the issues they encounter as a team.

If it sounds like some sort of hippy utopia, then I’m sorry, but that’s what you should be striving for.

In my experience though, it rarely happens. The reason that it is usually so hard to achieve is simple. People are different. Teams are also different, and each team will have people of varying degrees of experience.

There is no magic solution here, but I think this is where some good people management skills come in. I’m not talking about command and control, I’m talking about trying to create a team environment where everyone feels valued and can contribute.

This takes time and effort to achieve, and on my projects, it is something I try to foster right from the start. It’s not easy, it’s never repeatable and it’s often time-consuming and demanding. But it is always worth the effort. If you have a team that works together to resolve issues and hit milestones, your project has a much greater chance of success.

5. I want it all (and I want it now)


Freddie with thanks to Orange_Beard (

Everyone wants to get the most of what they can. It’s understandable. Developing applications is expensive and you want to get the most bang for your buck.

Where this becomes a problem is when everything becomes a “must have”. If you have no room to manoeuvre then you are not really working in a truly agile fashion.

Good agile projects work with constant negotiation between the team and stakeholders. The team need to be realistic about what they can achieve, and allow themselves some headroom. If something comes in, something else may have to go out. Teams don’t have unlimited capacity and whilst we are an agile team and happy to accommodate change it may come at a price!

This is where the relationship between the PM (or ScrumMaster) and Product Owner is key. This is where the negotiation needs to happen. Be realistic about velocity and don’t overload the sprint with “must haves” (60-75% is my rule of thumb). Accept that change is inevitable and make dealing with it part of the process.

If your scope is fixed, or even worse expanding as you go, with no mandate to change it then you are not on an Agile project.

Make it count

Agile is not easy, as with all things in life it takes effort and commitment to perfect. Hopefully this blog highlights some of the issues many of you will have experienced (please add it if it isn’t). Next time you are on an agile project that isn’t really agile, don’t be afraid to say so. Figure out what you and your team need to  put in place to make the project run in a more agile way! If you can’t do that – you might have to face up to the fact that yours is not an agile project, and to continue pretending it is, isn’t really gong to help you deliver!



Leave a Comment
  1. Robin Rawson-Tetley / Jun 11 2010 4:21 pm

    Well said, Chris.I shall be taking your list to the current ScrumMaster for the project I’m working on 🙂

    • Chris Neal / Jun 11 2010 7:20 pm

      Cheers Rob. I hope they get the hint!

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: