A unique dance position in Odissi is “tri-bhangi” (‘tri’ meaning three and “bhangi” meaning stance or position). Together, loosely translated, it means “thrice deflected stance,” and is quite difficult to master. In this position, there is a three- or tri-fold shape in the body forming an S-curve. To get into this stance, the upper part of the body such as head and hands are rhythmically moving in one direction, while the middle and lower parts of the body move in other directions with different rhythms. The joy of the dance for the viewer and performer alike comes through, in that parts of the dancer’s body are moving in rhythm, as well as the entire body moving, at large.
Now, you might be thinking what exactly a dance has to do with cadence in Agile?
Let’s start first with the definition of cadence.
Cadence – Definition and Basics *** UPDATED ***
One can define cadence in Agile as follows:
Cadence is a regular, predictable pattern of development work in Agile. It’s timeboxed and comes with consistent duration to help scheduling.
Simply put, cadence is a rhythm of execution. The concept of cadence in Agile is suitably explained with a dance. With dance, art meets science, and in the same way, management meets life.
Like dance, cadence creates a predictable pattern of work or rhythm of execution.
Also, like dance, which can come with different rhythms for the different parts of the dancer’s body, cadence can be different for the different practices of Agile development. For example, you can have one cadence for Agile planning events, a separate cadence for Agile demonstrations or reviews, and a completely different cadence for Agile retrospectives. You can also have a single cadence for all events, for example, every two weeks, you may have planning, demonstrations, and retrospectives. We will explore a number of such situations shortly.
Taking another example from our own human bodies, many organs function in various cadences. For example, our heart beats on a cadence, our breathing or respiratory organ works on another, and so on. In fact, if these vital organs of the body don’t operate on their respective cadences, life won’t exist!
That said, let’s explore how cadence can be applied in various Agile frameworks.
Working with Single Cadence
We have learned before, there can be two Lean-Agile frameworks at a high-level: iteration-based and flow-based. Irrespective of the type, cadence can be applied to development effort.
In iteration-based Agile, such as Extreme Programming (XP) or Scrum, an iteration length is prescribed. For example, in Scrum, where an iteration is called Sprint, the iteration length is usually less than a month (four weeks) as per my article on the latest Scrum Guide, 2020, and it’s always timeboxed.
When you keep the length of the iteration fixed over a period (and it is a good practice to do so), you develop a cadence. As we saw in our initial definition, it’s a predictable, regular pattern or rhythm of execution. When the iterations are repeated consistently over a period, a cadence is formed. In other words, in an iteration-based Agile, cadence is created with iterations, as depicted in the below figure.
Considering Scrum framework, the cadence is timeboxed, usually from two to four weeks and is created by a Sprint. Within the Sprint, you have a cadence, and it is a single one. When we modify it for Scrum, the figure will change to what is shown below.
Working with Multiple Cadences
Whereas in iteration-based Agile, the cadence is formed by iterations; in flow-based approaches such as Kanban, timeboxing is not prescribed. However, you can apply cadence here, too. You can choose when you do planning, when to release, and when to do a retrospective. You can decide on a set basis, such as a release every Friday, or you may choose an on-demand basis. It can also be based on when there is something valuable to release.
Below is an example of a team working with three cadences.
As shown above, we have:
- Every week the team releases whatever is ready for release,
- Every second week they have planning, and
- Every third week, they have a retrospective.
A project manager could develop cadence based on events, as well. This approach is employed in flow-based Agile or, if the stakeholders decide to do so, in an iteration-based Agile. Below is a case depicting that. A planning meeting is started when the team runs out of items to complete. A release is triggered whenever the team has a set of features ready. A retrospective is done every two to four weeks.
Looking at the above figure, one could say that these are the event-based cadences:
- Planning Cadence: A planning meeting is started when the team runs out of items to complete.
- Retrospective Cadence: A retrospective is done every two to four weeks.
- Release Cadence: A release is triggered whenever the team has a minimally marketable feature (MMF) and/or subsequently, a set of releases.
Cadence and Project Life Cycle *** NEW ***
The cadence is quite important because along with development approach, it determines the project life cycle! In this case, I’m considering the delivery cadence. This is shown in the below figure.
The delivery cadence informs how frequently the project deliverables are given. The deliverables can be given one-time (single delivery), multiple times (multiple deliveries), or periodically (periodic deliveries), among others.
Also remember that, development approaches can be many such as predictive (waterfall), adaptive (Agile) or incremental. A project life cycle can also be many types based on the development approaches. A project life cycle can be predictive, adaptive, hybrid (combination of predictive and adaptive) etc. You can learn more on development life cycle and project life cycle in this article.
Consider having a single delivery cadence, where the delivery will happen only at the end of the project. In such a case, one would go with a predictive life cycle. Similarly, considering multiple deliveries during development of software component for a car project can result in a hybrid life cycle.
Cadence and Intensity of Work
We know that an alert and healthy staff will always be more productive than if folks are tired or burnt out. For that, a sustainable pace is needed. However, in sequential/waterfall development model, this is not always the case.
Many times, it has been found that teams really can’t or don’t work with full productivity at the beginning of a project, especially, and it’s likely that they will start spending long hours and sleepless nights towards the end. In other words, the intensity of work goes-up towards the end of the project. Note the depiction of this in the below figure.
This late work towards the end of a project is known as death march, and it refers to the burnout and exhaustion of the team members. Obviously, this type of late work can lead to high attrition and the loss of talented resources. The Agile framework intentionally tries to put a stop to this risk. Hence, one of the principles of Agile Manifesto reads as:
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
With short iterations, intense work doesn’t peak towards the middle or end of the project, but remains steady throughout the project’s life cycle. This is because a project consisting of multiple iterations, will have similar intensity densities.
Cadence – Advantages
There are many advantages of cadence, some of which are:
- It is easier for project managers to manage with an understanding of cadence in place. Imagine having twenty planning meetings for twenty iterations; with iterations operating at one-cadence, scheduling becomes less challenging.
- It builds muscle memory. When you have a rhythmic set of activities, it builds familiarity, and keeps the mind free of trivial (but, needed) details. When the mind is free of such, time is better spent on value-added work.
- There is a big reduction in coordination, which is an offshoot of the first advantage. Some critics of Agile say there is a large overhead involved, due to the need for coordination with short iterations. With cadence, this overhead is guaranteed to be less.
- Scaling the effort of Agile becomes easier. In scaled approaches, it’s usual to see multiple teams operating at the same cadence. Even if an iteration is cancelled or abnormally terminated, recovery is possible by going back to the cadence.
- As we saw earlier, with right cadence, the intensity of work remains even throughout a project.
More on the Topic of Cadence
As we reach closure of this article, I want to summarize the concept of Cadence used in flow- or iteration-based Agile with a video. It’s taken from ACP Live Lessons course. [Duration: 4m:26s]. This video uses a real-world example to explain the concepts I’ve written about above. For a better audio-visual experience, you may want to go full-screen with HD mode and plug-in your earphones.
Conclusion
The classical dance of Odissi starts with a solo form of pure-dance, where the performer emphasizes the execution aspect. It’s about knowledge, skills, dance patterns, and execution. The dancer, at this stage, excels with pure technical performance. In Agile methodology with daily cadence, the emphasis is also on execution–a bit of planning, a bit of design, a bit of development, a bit of testing, a bit of integration–daily. The individual developer is primarily involved in this technical work.
After the start, highlighting technical skills, we see the Odissi performer dancing with emotion, communicating feelings, and expressing nuance. Multiple dancers often come together at this point in the performance. In the context of Agile, within iteration (or flow) cadence, individuals come together to decide which items will be taken-up as they interact and communicate.
Next in the Odissi dance, it’s about group performance, or a team delivering together (i.e. they work on the whole drama part of the dance with a story). Similarly, in Agile, as the team comes together, delivery is made in release cadence. This can be after multiple iterations, every iteration, or on-demand. In most cases, these releases are given to the customer.
Finally, when pure-dance and dance with emotions combine with group-dance and delivery happens frequently, the Odissi dance becomes something else entirely. It is climatic, liberating, and often even stunning when this occurs. This stage is known as Mokshya in Odissi, meaning liberation or freedom.
In Agile parlance, this stage will be called a hyper-performing team, and it delivers highest-valued deliverables frequently, without interruptions. The team performs as a single, immutable unit, giving hyper-performances. While doing so, a constant pace can be maintained indefinitely. This is the essence of cadence.
* The opening photo of Odissi dance is by Bijay Biswal, who graciously agreed to share his ball-pen painting for this article and informed to be an honor that his painting is featured in the article.
—
This article is dedicated to the memory of my father, the late Harendra Nath Dash, who passed away two years ago on June 11. He, along with my mother, introduced me to Odissi dance, taught me the importance of dance and music in our daily lives. It’s a tribute to them and their teachings. Men and women around the world have kept alive various forms of dance, which calms our minds and nourishes our souls. I take a bow.
--
This article was first published by MPUG.com on 29th June, 2021.
References:
[1] Online Course: PMI-ACP Live Lessons – Guaranteed Pass, by Satya Narayan Dash
[2] Online Course: PMI-ACP 21 Online Contact Hours, by Satya Narayan Dash
[3] Book: Kanban and Scrum, Making the most of both, by Henrik Kniberg and Mattias Skarin
[4] Book: I Want To Be An ACP, the Plain and Simple Way to be a PMI-ACP, 2nd Edition, by Satya Narayan Dash
[5] A Guide to Project Management Body of Knowledge (PMBOK), 7th edition, by Project Management Institute (PMI)
No comments:
Post a Comment
Sign- or Log-in and put your name while asking queries in comments. Any comment is welcome - comments, review or criticism. But off-topic, abusive, defamatory comments will be moderated or may be removed.