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.

Advertisement

Popular Scrum tweaks

Contentious, I know, but the Scrum framework for agile software development may not be completely perfect yet. That’s fine because because we can improve on it, like science.
A few problems that often come to light are:

• Very few people agree what Agile is. I’m one of them.
• Few people agree exactly what Scrum is (despite it being defined by a very short document, The Scrum Guide.) “Like chess, Scrum is very simple.”
• There is a lot of common agile practice that is used by Scrummers and taught on courses but isn’t part of Scrum.
• Many people think they are ‘doing’ agile and/or Scrum but may not be. Who knows? The rules are: there are no rules.

In my last post I mentioned pragmatic changes to Scrum. Below are some that seem common and I’m not sure are always wrong. I think they come from the fact that Scrum makes assumptions about the mere humans who fill the Scrum roles that are, to be polite, idealistic:

• The use of Business Analysts to supplement the Product Owner’s knowledge and skills and the developers ability to listen and ask the right questions. Developers are not all good at dealing with people or at business analysis. The people who are, are not all good at development. Part-people who add up to a whole role may be the best a team can realistically achieve.
• The use of stakeholders who know areas of business better than the Product Owner (PO.) Product Owners need to be super-human: trusted by whoever is paying, knowledgeable, decisive, able to write good stories and constantly available. The PO is there to make dangerous business decisions, so the Team don’t have to. If they make bad decisions, it isn’t the Team’s fault. They are allowed to have help. By this logic, any BA who helps the BA should be outside the Development Team because business process is not “IT”. I have not yet seen any organisation with a business process department. I think we will soon. Process design is often considered a management responsibility but very few managers have appropriate experience.
• The use of technical/engineering/architecture specialists to supplement the skills of the Development Team. One small team is assumed to consist of generalising specialists with knowledge of everything that will be necessary to complete the project, though you don’t know what that is yet, so ‘be lucky’
• Network communicators/organisational specialists. Scrum assumes autonomous teams but at scale, organisational efficiency considerations start to apply pressure to centralise scarce and expensive skills. Co-ordination of networked teams becomes necessary. Traditionally, managers are likely to have filled similar roles but in future there may be more collaboration than typical managers have experienced while fighting for influence and resources inside a hierarchical organisation.

Agile as something you do

I have spent the last 2 evenings in Birmingham listening to talks by @diaryofscrum at @ScrumUK and @stevejpitchford at @bcsbrum about management and ‘Agile’ software development, which brought some of my own concerns into sharper focus, particularly about the Scrum framework. In many discussions with practitioners over the last couple of years, I’ve heard the following phrases:

“Agile is an adjective not a verb”
“Agile isn’t something you do, it’s something you are”
“Agile is a philosophy not a method”
“Agile isn’t a process”

Someone who ISN’T agile has to start somewhere. They typically need to DO something, to write software. Would we claim,”Scientific” is an adjective not a method? We wouldn’t, because it is both. The scientific method is a function which delivers what we call “scientific knowledge” as its value. If it didn’t, it would be pointless.

Managers are generally trying to get things done. Each team must agree its own Agile Operating Model (thanks to BCS’s ‘Agile Foundations’ book for that useful phrase.) What came out of the last couple of evenings was pragmatic application of philosophy. Many organisations take Scrum as a starting point, without realizing that “framework” is to be taken very literally. Scrum doesn’t paint the complete picture. It is (part of) a process to organize work. It says almost nothing about how to do that work. It is an alternative to writing a project plan “up-front”, when you know least.

An Agile Operating Model is a process which delivers a value, so it is a function. My scientific hypothesis is that it delivers valuable business function change, sometimes in the form of software. It is itself a business function. Agility has business functions as first class citizens. It doesn’t meet general expectations of a process because it can recursively self-modify. That doesn’t mean it isn’t one. As the kids say, “get you an agile function that can do both”.

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.

Lean and Agile, Kanban and Scrum

For some weeks now I’ve been putting off a task I had set myself to get the difference between Agile & Lean sorted out in my head, then in writing. The very first link brought up by Google means I don’t need to do that now. It’s also on a blog that I’m already following which suggests I’ve spotted gold here before:

http://www.hackerchick.com/2012/01/agile-vs-lean-yeah-yeah-whats-the-difference.html

and she then went on to explain in Part 2 why Scrum is just a (probably necessary) stepping stone from ‘traditional project planning’ to Kanban scheduling.

http://www.hackerchick.com/2012/01/kanban-is-the-new-scrum.html

I should just stop, read everything she’s ever written and save myself a lot of time.

http://www.hackerchick.com/2010/02/are-we-agile-yet.html ?

The Consultant’s Dilema

In this recent post http://wp.me/p3YvTZ-cj I concluded that within a Scrum development sprint you should do the highest value stories first.

I’ve since got more pragmatic. “Highest value” should be interpreted as “most valued”. The Agile team’s job is to deliver the stories that our Product Owner(PO) values highest. In an ideal world this would be the same stories that deliver the highest finanicial benefit:cost ratio for the organisation but this isn’t realistic. The PO and other stakeholders are human beings. They will take into consideration: automating away jobs they don’t like, making a name for themselves to help with their own career progression and popularity with their colleagues. Any value-justification hoop they are forced to jump through will result in figures that make what they personally value highest look like the best financial value. Don’t waste their or your own time, exchanging spreadsheet lies.

This is “The Consultant’s Dilema”: you have been employed by a client who works for an organisation. Whose interests are you being paid to represent, your client’s or the organisation’s? If the client’s interests are not totally at odds with those of the organisation or your professional reputation, is it immoral to return the result that is required? Are you in a better position to maximise the value to the organisation by doing only this job or to have the opportunity to deliver greater total value by making your client happy, faster and possibly getting him/her promoted where s/he has wider influence? Who wouldn’t want support from high places?

Ordering Scrum sprint-backlog by user-story ‘benefit:cost ratio’ of equal sized jobs, to deliver better business value

WARNING: this entry is in the ‘really quite geeky / technical specialist’ category. It assumes knowledge of an Agile software development framework called Scrum. If that isn’t you then you’ve probably got better things to do with your life. Maybe I need a new blog for things THIS weird?

[ The title of this article has been changed but it needs to be revised further to explain that ‘smallest job first’ is assumed in the examples before ordering of equal size jobs by user-story benefit:cost ratio. 29/4/2014 ]

I was recently introduced to a management fashion for calculating the http://en.wikipedia.org/wiki/Net_present_value of projects. It appears to offer an excellent mechanism for demonstrating the greater value delivered by Agile, if we knew the business value of each requirement.

I started to think about how we might estimate the approximate benefit that would delivered by each user-story and whether, within a Scrum sprint, the order that user-stories were tackled would change the total benefit delivered. In the LinkedIn Agile group I proposed the following thought experiment:

3 user-stories, worth 2, 1 & 1 units of business value and estimated at 20, 10 & 10 story-points respectively. Assuming no dependencies, the same priority and 1 developer, what order do you tackle them in?

“Working in the lab, late one night” these were the results of that experiment.

SprintByValueOrder (only 3 pages, including 2 diagrams)

I would welcome any feedback. Was that obvious? Has it been said before or is it new? Should I develop a mathematical proof and publish in a technical journal? Please don’t make me do a literature. I read REALLY slowly.