Be agile not Agile™

In 2014, Dave Thomas, one of the seventeen who met at Snowbird ski resort in Utah and came up with the Agile Manifesto, wrote a blog post with a wonderfully clickbait title: “Agile is dead (long live agility)”.

In the article he laments that too many people focus on ‘Agile’ with a capital ‘a’ as though it was a brand: Agile™. Agile isn’t a noun (a naming word, my primary school teacher would drill into us), agile is an adjective (a describing word). Thomas urges us to think about agility not Agile.

“The word “agile” has been subverted to the point where it is effectively meaningless, and what passes for an agile community seems to be largely an arena for consultants and vendors to hawk services and products.” — Dave Thomas

Agile principles

I’ve been thinking a lot recently about agile principles. What are the fundamental truths that serve as the foundations of agile development—sorry, of development that shows agility?

Agile manifesto

Of course we have the Agile manifesto:

“We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

“That is, while there is value in the items on the right, we value the items on the left more.”

Scrum values and pillars

Scrum has five core values:

  • Commitment
  • Courage
  • Focus
  • Openness
  • Respect

and three pillars

  • Transparency
  • Inspection
  • Adaptation

AgilePM (DSDM) principles

I’m fond, too, of the eight principles on which AgilePM (formerly DSDM Atern) is built:

  1. Focus on business need
  2. Deliver on time
  3. Collaborate
  4. Never compromise quality
  5. Build incrementally from firm foundations
  6. Develop iteratively
  7. Communicate continuously and clearly
  8. Demonstrate control

Bertrand Meyer

Bertrand Meyer in Agile!: The Good, the Hype and the Ugly (Springer, 2014) argues for the following principles that promote agility:

  1. Put the customer at the centre
  2. Let the team self-organise
  3. Work at a sustainable pace
  4. Develop miniminal software i. Produce minimal functionality ii. Produce only the code requested iii. Develop only code and tests
  5. Accept change
  6. Develop iteratively i. Produce frequent working interactions ii. Freeze requirements during iterations
  7. Treat tests as a key resource i. Do not start any new development until all tests are passed. ii. Test first
  8. Express requirements through scenarios

Back to basics

Dave Thomas finishes his blog post by showing us how to do something in an agile fashion:

  1. Find out where you are.
  2. Take a small step towards your goal.
  3. Adjust your understanding based on what you learned.
  4. Repeat.

And “when faced with two or more alternatives that deliver roughly the same value, take the path that makes future change easier.”

That’s it.

Orientate, plan, do, check, adjust, repeat.

Where do we need to focus?

I’ve often found these lists of principles useful to focus the mind on what’s important about working with agility.

Which principles stand out as those we need to focus on

  • as a company?
  • as a team?
  • as an individual?

What is the next small step we need to take?

Originally posted on Vision internal blog.

Using a process map to help create definitions of ready and done

Last week, I ran a couple of workshops with the Vision Tasks team to help us better understand our processes.

As the Vision Tasks team in its current guise is a relatively new team, I thought it might be a useful exercise to map our development and testing process, starting from the point of adding a user story to the backlog to that requirement being ready for deployment.

Business process models such as these are helpful for newer members of a team who perhaps don’t yet have a full picture of the team’s processes and how their role relates to others on the team. This ‘as is’ or ‘current state’ visualisation can also draw out inconsistencies, promote a consistency of approach and identify areas where improvements can be made.

Continue reading Using a process map to help create definitions of ready and done

Agile is about culture not processes

At the Cegedim UK conference in Dundee on Wednesday 23 January 2019, Steve Bradley introduced us to the company goals around which the agenda was organised. The third goal was about people and culture:

To develop our talents and to promote an open, empowered, collaborative and energised working culture that embraces change, nurtures innovation and makes us a truly amazing and rewarding company to work for.

This excited me.

The Oxford English Dictionary defines culture as ‘the ideas, customs and social behaviour of a particular people or society’. While I’ve not found the word ‘culture’ in any of the books I have on agile or any of its particular flavours (DSDM, Lean, Scrum, XP) this is something I came to realise very early on: agile development is not a process, it’s not a methodology, it is a culture.

This makes sense. The first statement in the agile manifesto reads, “Individuals and interactions over processes and tools”.

Agile development is not a process, it’s not a tool, it is a culture. It is about the ideas, customs and social behaviours of a particular team or company that uses experimentation and validated learning to rapidly release quality software and that learns from its serious use with real users.

Continue reading Agile is about culture not processes