Tag Archives: agility

Agility vs Momentum

[ This post is aimed at readers with at least basic understanding of agile product development. It doesn’t explain some of the concepts discussed.]

We often talk of software development as movement across a difficult terrain, to a destination. Organisational change projects are seen as a lightening attack on an organisation, though in reality, have historically proved much slower than the speed of light. Large projects often force through regime change for ‘a leader’. Conventionally, this leader has been unlikely to travel with the team. Someone needs to “hold the fort”. There may be casualties due to friendly firings.

Project Managers make ‘plans’ of a proposed ‘change journey’ from one system state to another, between points in ‘change space’, via the straightest line possible, whilst ignoring the passage of time which makes change possible. Time is seen as distance and its corollary, cost. The language of projects is “setting-off”, “pushing on past obstacles” and “blockers” such as “difficult customers”, along a fixed route, “applying pressure” to “overcome resistance”. A project team is an army on the march, smashing their way through to a target, hoping it hasn’t been moved. Someone must pay for the “boots on the ground” and their travel costs. This mind-set leads to managers who perceives a need to “build momentum” to avoid “getting bogged down”.

Now let us think about the physics:

  •  momentum = mass x velocity, conventionally abbreviated to p = mv.
    At this point it may also be worth pointing out Newton’s Second Law of Motion:
  • force = mass x acceleration, or F = ma
    (Interpretted by Project Managers as “if it gets stuck, whack it hard with something heavy.”)

What about “agile software developments”? There is a broad range of opinion on precisely what those words mean but there is much greater consensus on what agility isn’t.

People outside the field are frequently bemused by the words chosen as Agile jargon, particularly in the Scrum framework:
A Scrum is not held only when a product development is stuck in the mud.
A Scrum Master doesn’t tell people what to do.
Sprints are conducted at a sustainable pace.
Agility is not the same as speed. Arguably, in agile environments, speed isn’t the same thing as velocity either.

Many teams measure velocity, a crude metric of progress, only useful to enable estimation of how much work should be scheduled for the next iteration, often guessed in ‘story-points’, representing relative ‘size’ but in agile environments, everything is optional and subject to change, including the length of the journey.

If agility isn’t speed, what is it? It is lots of things but the one that concerns us here is the ability to change direction quickly, when necessary. Agile teams set off in a direction, possibly with a destination in mind but aware that it might change. If the journey throws up unexpected new knowledge, the customer may wish to use the travelling time to reach a destination now considered more valuable. The route is not one straight line but a sequence of lines. It could end anywhere in change-space, including where it started (either through failing fast or the value of the journey being exploration rather than transportation.) Velocity is therefore current progress along a potentially windy road of variable length, not average speed through change-space to a destination. An agile development is really an experiment to test a series of hypotheses about an organisational value proposition, not a journey. Agile’s greatest cost savings come from ‘wrong work not done’.

Agility is lightweight, particularly on up-front planning. Agile teams are small and aim to carry everything they need to get the job done. This enables them to set off sooner, at a sensible pace and, if they are going to fail, to fail fast, at low cost. Agility delivers value as soon as possible and it front-loads value. If we measured velocity in terms of value instead of distance, agile projects would be seen to decelerate until they stop. If you are light, immovable objects can be avoided rather than smashed through. Agile teams neither need nor want momentum, in case they decide to turn fast.

Is this Important or Urgent?

This post refers to a technique often used in Agile software development, including within the Scrum framework. It is not an introductory text so not recommended for non-agilists.

‘user-stories’ are classified as: Must (do), Should (do), Could (do) and Won’t (do), known as: MoSCoW. User-stories are then usually prioritised by an integer representing value, which represents a calculation of return on investment, or benefit:cost.

Paul Oldfield, Chief Referee at LinkedIn ‘Agile & Lean Software Development’ group said:

I find a bit of a problem with MoSCoW – distinguishing between “Must have eventually” and “Must have in release 1”. Get beyond release 1 and a high value “should have” can be prioritized in front of a low value “must have”.

And then, a lot of the “must have in release 1” turn out not to be, if we look closely.

“If you want all these in release 1 you get nothing for 6 months.
Or you can get these in 2 weeks, those in 4 weeks… would you like that?”

I gave (a slightly worse version of) this reply:

I think MoSCoW is about ‘importance’ not ‘urgency’.
Urgency comes into the prioritisation choices when the benefit of the story is time sensitive.

Delivering benefit early starts summing value for longer, so total value delivered in the life-time of the product or service will be higher but now we’re talking about delivering a different absolute ‘spot value’. Putting it another way, value can be a function of time.
e.g. “If this isn’t ready in 2 weeks then we’ll be fined by the regulator” or
“We need this before the Summer Sale starts. If you miss that, it’s useless until Christmas.”

I didn’t know this before today. I’m sharing the idea in case it helps someone else or they can improve it and give me a copy. It’s how things worked before science had to make a profit.


The Anti Agile Manifesto – a Robust Response

I saw this on LinkedIn today: http://antiagilemanifesto.com/

My first thought was “Why would anyone developing software ever be against agility?”, so I read it:
“Agile is simply the obfuscation of common sense – the bewitchment of the mind through language”.

Bad Agilists! It is very unfair to use linguistic wizardry against the poorly tuned literacy skills of we simple IT folk. Yet, when I read about Agile, I thought I’d tripped headlong into the soft, welcoming caress of a fluffy, newly laundered quilt of common-sense that I’d always dreamed of through my years of methodological rough sleeping. Clearly, we need to consider this new evidence carefully: “epics are really just projects”. Well, no, they’re not are they? Projects have a known, fixed scope and known finite length and almost by definition, Agile methods don’t. So, in fact, you haven’t really understood, have you? If you’d said “epics are really just big lumps of work”, then fair enough. But you didn’t.

What about“velocity is really just output”. Again, no. I accept that it isn’t a distinction you’re used to making but it’s “…just useful output”. You know, output with business value? No, of course you don’t. Why would you?

What about the rest?:

  • stories are really just use cases
  • sprints are really just work
  • stand-ups are really just meetings
  • iterations are really just versions
  • backlogs are really just to do lists
  • backlog grooming is really just planning
  • burn-down charts are really just earned value charts
  • and that tasks, in fact, are really just tasks.

Yes, I’m fine with all of those but let’s face it, you’ve had enough difficulty grasping that some features of Agile methods are COMPLETELY, FUNDAMENTALLY DIFFERENT that I think the new words were just there to get you a bit excited about trying out something new but you don’t really want to, do you? You’d rather carry on not getting useful things done the way you always have.

Your ‘Stay slow and inflexible’ manifesto ends:

“That is, while the concepts on the left are often presented as groundbreaking or unique, they are merely weakly defined versions of those on the right.”

Were they, really? It sounds like you make bad choices generally. You may wish to try training providers who understand what the ground-breaking Agile concepts actually are. When you understand that “weakly defined” is “lean and flexible”, get back to us – if you aren’t too embarrassed. Agile isn’t perfect and there was plenty you could have legitimately criticised. But you didn’t.