How To Find Your Rhythm

What is Agile Anyway? — Part 5

In part one of this series of articles, I introduced the concept that an agile mindset and the tools are not an either-or relationship, but rather a continuous cycle, with the one necessary for the other to exist, the one transitioning into the other.

The dance of agile

Agile, in it’s essence, is a dance between mindset and tools. The one flowing into the other, like the yin-yang symbol symbolizes so perfectly. This same inter-dependency, or rhythm, is one of the essential foundations of agile.

Everything within agile has a rhythm, and the goal of agile is to find a state of homeostasis, or balance.

In Chinese medicine, the top part of the yin-yang symbol, where the black meets the white, marks the summer solstice —the longest day with the most daylight in the year. From this point, the days get short and shorter, until it reaches the bottom, where the black meets the white again. This point marks the winter solstice, or the shortest day of the year, after which everything starts all over again.

The right side, or masculine side, is a time for action and hard work, and the left side, or feminine side, is for recharging your batteries and building up reserves in preparation for the next cycle of action. When these cycles get out of balance in a human body, disease occurs.

Similarly, agile is a series of cycles between action and rest or reflection. It’s a steady rhythm, like the continuous beating of a heart. When these rhythms get out of balance, dysfunction occurs. The results include a decline in quality, unreliable estimates, and a steady — sometimes rapid — decline in productivity.

The more balance in the rhythm, the healthier the team and the more productive they are.

It’s when the rhythms of agile are not adhered to that the teams risk burn-out, rendering them inactive for extended, unplanned periods of time. The impact of not taking time for reflection and rest might look enticing for short-term gains, but results in huge long-term losses.

The common misunderstanding

The reason why most companies choose to transition to agile, is because of the promise of faster value delivery. A lot of people believe that they have to work faster and do more in order to be agile. The emphasis is on the fast, mostly at the expense of the value. And that’s not at all what agile is about.

Agile is not about working faster, or working harder. Agile is about finding a sustainable rhythm that will enable the team to continue indefinitely.

An athlete that competes in a sprint can run very fast for a short distance, but is totally exhausted and needs to rest after a few hundred meters. A marathon runner, on the other hand, goes at a much slower pace, but they cover much more ground, able to continue for distances of 42km in a day. No sprinter will be able to do 420 100m sprints in a single day.

Agile is the same — either you push the team hard for a short period, or you support them from the side for an extended period of time.

Do you want to go fast? Or do you want to go far?

The one is not better than the other, but the one needs more rest sooner, the other can go for longer, but at a slower pace. Sometimes you need the one, other times the other. But you can’t run an entire marathon at the pace of a short distance runner.

When you have a big dream, or a big system to build, it’s better to go at the more sustainable, but slower, marathon speed. They do go slower, but they cover more ground faster.

The rhythms of agile

When you go at a slower pace, the heart continues to beat healthily and the team continues to deliver predictably. It’s possible to give more accurate estimates to customers and the quality level is maintained or increased sprint by sprint.

Even if you don’t run sprints, following Kanban with it’s continuous flow, there are some rhythms that remain the same.

1. Iterative and incremental product delivery

A goal of agile is to fail fast. The faster you can deliver something to a customer, the faster you can receive feedback and adapt and the faster you can give them what they actually need.

But it’s not about the speed, it’s about the size.

Looking back at waterfall development, gathering requirements sometimes took years for a single project, only to find out years later that what was delivered, wasn’t valid or wanted anymore. The losses was huge and the customers were unhappy.

In an attempt to solve this problem, agile introduced slicing requirements into smaller, more manageable chunks in an attempt to align with the customer on a regular basis, rather than diverge in different directions until the gap is too big to cross.

Agile is thus rather about delivering smaller parts to gain feedback fast, than doing the work fast. You can be as busy as a bee, but if you don’t take time to listen and reflect — integrating the feedback you receive— you might end up working on the wrong solution without noticing, which is nothing different than following a waterfall approach.

What you are looking for is a consistent, smooth, repeatable rhythm, much like the beat of a heart or the beat of a drum.

Doing. Listening. Doing. Listening…Release. Reflect. Release. Reflect…

2. Plan, Do, Reflect, Adapt

Another inherently built-in cycle, or rhythm, in agile is the Deming P-D-C-A cycle, which is a continuous process of small improvements. The intention is to react and respond to the changes in your environment as a habit, rather than waiting for the problem to become so big that it can’t be ignored anymore.

In Scrum the planning and estimation meetings are usually the ‘Plan’. The goal is to think about what is the most important task, and how best can we achieve this task. Who and what do we need to make this valuable?

The actual sprint forms the ‘Do’, where the teams deliver on what was planned. It’s analyzing the requirements, designing the screens, building the infrastructure, developing the front-end, verifying and validating. It’s all about getting things done.

Next it’s presented to the customer in the review as the ‘Check’ phase to find out whether what was delivered meets expectations.

Finally, the retrospective aims to satisfy the ‘Act’. Notice that the word associated with this phase is action, it’s not simply talking about what went wrong, but you’re actually doing something about it. Now. You adapt the plan, or you change the tool or the process. You spend time making the changes and taking the time to prepare better for the following cycle to prevent you from making the same mistakes again.

Not spending time to reflect and learn after a cycle of delivering, is as dangerous and harmful as not taking action to respond to the lessons learned.

Like a rat inside a spinning wheel, going faster and doing more is only going to make you go around the same circle faster, making the same mistakes quicker. In order to get off the spinning wheel, you need to first stop and reflect to get out of the vicious cycle.

You need to slow down in order to speed up.

Common causes of out of balance rhythms

1. Metric madness

Metrics are super important. It helps you make better decisions and it takes away a lot of guesswork. It’s valuable. And I love analyzing an insightful report or spreadsheet.

But too much of a good thing is bad. What was supposed to be medicine, is the cause of a different disease. The same is true with metrics.

Less is more. Measure what you want to get done. No more, no less.

2. A strong focus on velocity

Velocity is intended to be an indicator of the capacity of the team, and how much they can deliver in a single sprint. It’s a tool to help be more predictable and reliable.

Velocity is not a reflection on the ‘agility’ of a team, or their performance. Speed without quality does not result in value.

Many teams attempt to increase their velocity sprint after sprint. This is good when starting off with agile or Scrum, but sooner or later, a team reaches an optimal velocity, and then, it just doesn’t make any sense increasing the velocity anymore. Change it when it makes sense, not as a rule.

3. Underestimating the importance of retrospectives

While I was on a personal sabbatical, I taught English in Thailand as part of my research into education and gamifying the learning experience. As a result, I invested a lot of time and effort in researching how to effectively teach, and what learners need to use the knowledge, rather than simply pass an exam.

One of the influencers I follow, Jordan Shapiro, advises that for teaching to be effective, there needs to be three things present — a goal, exploration, and reflection. Leaving out any of these, reduces the learning experience.

In agile teams, the retrospective is meant to look back and reflect on your successes and failures in an attempt to adapt. Leaving out, or neglecting the retrospective, essentially keeps you back from achieving higher goals and more successes.

4. Not following through on decisions

But a retrospective is worth little if it isn’t followed by action. Deciding on changes but then not making the necessary changes or following through, is like spending a lot of time studying for an exam but not using the knowledge.

It renders the time invested in gaining the knowledge useless.

5. Too many changes

Contrary, some teams make too many changes. This causes as much disruption and chaos, with sometimes worse results than not making any changes.

Like the butterfly effect, when even only one small change is made, there are many unintended reactions and results. To effectively implement change and breed a culture of continuous improvement, it’s best to make one, small change regularly.

Conclusion

An agile team is one that is in balance, with a steady rhythm. They are an optimized team working at a sustainable pace, investing time in action as well as reflection.