You are currently viewing The Physics of Agile Methodologies…and how our vocabulary creates unnecessary entry barriers

The Physics of Agile Methodologies…and how our vocabulary creates unnecessary entry barriers

In the course of many consultancy gigs and trainings, I had the opportunity to work with people from many different cultural and professional backgrounds. While there are quite a few opportunities for little culture clashes (e.g. the perceived duration of 5 minutes), most of the people I work with share a common perception:

The terminology we use in Agile Methods is nerdy, and far from the language “normal people” would use. This might be a first clue that we might be using terminology to separate those in the know from laymen.

Agile is for the people who work with it, not for the consultants.

This is not what Agile methods are about, and there is no need to use awkward terms to come across scientific. Agile is for the people who work with it, not for the consultants…so, no need for it to come across as an actual science. Let’s de-science our vocabulary. Simpler words will help making Agile Methods more accessible, which in turn will allow for a more widespread adoption, even with non-techy teams.

Imagine a purely non-technical team. Not software engineering, no DevOps, just a normal crew trying to get things done, say…Office Management. Let’s call it the A-Team, and they are looking for some way to improve their daily work. The A-Team is also looking for ways to add transparency for their team and their internal customers.

Assuming a lucky coincidence, they arranged to meet with their friendly neighborhood Agile Coach. 

(brief pause for tension)

After the meeting, all team members and the coach have confused looks on their faces. The team is numbed by funny words like iteration and information radiator. They also wonder what their velocity might be, as they usually just sit at their desks? In this meeting, there was no actual communication going on, since the vocabulary was new.

Having said that, I’d like to give some example of Agile terms which could be expressed in non-techy ways.

Sprints, Iterations and Inspect&Adapt

I’ll start with that one, as the basic principle of “iterating” towards our ever-changing goals is the cornerstone of anything we might call Agile. However, the bus near my house is neither sprinting nor iterating, and kids don’t inspect&adapt their way towards being able to draw awesome pics of airplanes.

So how about using simpler terms like “Repetition” or “Schedule”?
Therefore, in the course of several repetitions, we use “Trial and Error” to achieve a result.

Increment

At the end of an iteration, we’re supposed to come up with a product increment. The underlying idea is that we do not just write code, but a healthy team will come up with a usable product increment. Tested. Documented. Integrated. Shipped. 

But then, have you ever heard your neighbors bragging about their latest increment to the house?

Here, a more accessible term would be “extension” or “addition”.
“At the end of each repetition, we are able to present an addition to our product.”

Velocity and Cadence

These terms are physics at its best (yes I am aware that cadence is also used in music). While the terms themselves are uber-precise, they immediately lead to an anaphylactic shock with everybody who is more Penny than Sheldon.

Therefore, we could just as well use the term “speed” and achieve the same semantics:
“At the current speed, we need 6 repetitions to be ready.”

Information Radiation

An Information Radiator is any kind of analogue or digital display, which is constantly showing project status information. You’ll find these in the team room or near the coffee maker, and they serve to keep the team focused and relieve them of unnecessary status meetings.

I suggest to stick with the analogy of “heating”, but use a simpler term: “The team room is hot with information”.

Value Streams, Information Flow and Theory of Constraints

These terms arent’t really from any Agile methodology. However, with higher maturity levels, I invite teams to address their information flow, its visualization and maybe all the jams or congestions.

Newton’s 3rd Law of Motion

You got me, I sneaked this one in – it’s not a term used anywhere in the Agile software development literature, so consequently it won’t appear in the overview table below.

However, I observed this in multiple change management projects…a behaviour which can be phrased as Newton’s Third Law of Motion: For every action, there is an equal and opposite reaction. In simpler terms, we are “pushing against a wall”.

These are just a few examples of technical terms being used in a field that is particularly about individuals working together.

This brief article serves as a conversation starter towards a better vocabulary. Once we un-nerded our vocabulary, there will be less friction (wink, wink) in the adoption of Agile methods by non-technical teams.

TermAlternative Term Suggestion
Sprint/IterationRepetition/Schedule
Inspect&AdaptTrial&Error
IncrementExtension/Addition
Velocity/CadenceSpeed
Information RadiationHot/Cold Environment
ConstraintJam/Congestion