The Rhythmic Dance of Agile with Cadence

 

Odissi (pronounced o-dee-shee) is one of the classical dances of India from the coastal state of Odisha. Based on archeological evidence, it’s possibly the oldest living classical Indian dance. The Massachusetts Institute of Technology (MIT), US, notes in its web-archives that Odissi is two to three thousand years old. In recent decades, it’s been popularized by well-known artists—one being singer, Michael Jackson. In his famous 1991 song, Black or White, Jackson danced a fusion of Odissi and pop-rock, with his companion dancer, on the highways of the United States.

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.

Working with Event-Based Cadence

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)

 

Earned Value Management (EVM) in Agile Development

In this article, we are going to explore Earned Value Management (EVM), a widely used traditional management technique, but we are going to look at it within the context of an Agile domain.

Let’s consider an example scenario. A product manager, who works for a large aircraft manufacturing organization in the United States, follows a hybrid model of development and, with his team, releases a new version of aircraft handling software every couple of weeks. At the start of each iteration, he may be unsure about the applicability of earned value analysis, measurement, and management within Agile. His main questions may be:

• How can we apply EVM while following an Agile approach? Is it natural?
• With frequent scope changes, how does one determine what to measure against?
• Scope change is also frequent on the iteration level! How can we incorporate EVM metrics in such cases?

To understand EVM, one needs to understand the concept of baseline, first and foremost. In EVM terminology, baseline is further defined as the performance measurement baseline (PMB). Let’s first define PMB, because, as I’ve seen, the lack of clarity regarding EVM is typically due to lack of PMB understanding. 

Performance Measurement Baseline (PMB)

The PMB is a virtual (not physical) baseline integrating scope, schedule, and cost baselines. In other words, PMB is the time-phased budget of authorized work for a project or program.

EVM is fundamentally based on this baseline–irrespective of chosen life cycle, be it predictive (Traditional), adaptive (Agile), or any other. It doesn’t matter how many iterations (or sprints, if in Scrum) you have or how frequently the scope changes. For EVM, it matters where and how you are setting your baseline. We will see shortly where the baseline is an Agile context. As EVM integrates scope, schedule, and cost, it’s quite a powerful technique. This is shown in the below figure.

 

Another issue occurs when management practitioners incorrectly interpret earned value as being business value. Earned value is not business value, rather it’s the value that you have earned in terms of money after completing the work. Hence, it’s actually a measure of work performance or performance against the set baseline or PMB.

With these fundamentals in mind, let’s now consider the foundational metrics in EVM. 

Foundational Metrics in EVM

The foundational metrics in traditional EVM are noted in the below table. I call them the foundational (or basic) metrics, because, based on these metrics, current and future performance metrics are derived.

As you go through the metrics in EVM, one key thing is to remember is this: everything is in terms of money. The budget, of course, will be in terms of money, and the work planned and work performed or executed, will also be in terms of money in this case.

We will look at the usage of these foundational metrics for Agile development shortly. Note that with these foundational metrics in place, we derive performance metrics of EVM.  

Current Performance Metrics in EVM

The current performance metrics used to calculate EVM are noted in the below table for a Traditional environment. I call these metrics current performance metrics, because the measurement happens on the status date, data date, or record date. The good news is, that these foundational metrics remain the same for Agile projects and/or programs.  Keep reading, as we are going to reuse these performance metrics in the next section.

It’s pertinent to note the behavior of SV and CV. If they are positive or negative, then the project or program is ahead of or behind schedule and cost, respectively. Similarly, if SPI and CPI are above or below 1.0, then the project or program is ahead of or behind schedule and cost, respectively. 

Using EVM in Agile Approaches

When using EVM in an Agile approach or environment, we circle back to the concept of baseline. In Agile projects, the baseline at the release level, not at an iteration level must be considered.

You may be wondering why. In Agile approaches, work is considered “done” at the end of each iteration (or sprint). While it’s true that story points are used to relatively estimate work items being taken-up, work is not considered to be fully “done” until the end of the iteration. If an item is not done, then it’s usually pushed into the next iteration. Hence, measurement during an iteration adds no value. This is because the work can’t be complete/done (or incomplete/not-done) mid- iteration.

If a story is complete, only then is it considered “done.” If a story is partially complete, (say only transition testing is remaining, then it’s not considered to be “done” at all). As you can see, it’s futile to have a baseline at an iteration level.

Are you wondering now how to calculate the performance measurement baseline (PMB) at a release level?

Simply add up the number of story points that you have planned for the release. While the PMB is at the level of the release, we do the measurement at the end of every iteration. In other words, our status date or data date is set for the end of the iteration. This is because, at the end of the iteration, we know the amount of work completed or “done.” And, this work counts towards velocity. Velocity, as explained in this article, also can inform the number of iterations in a release. You can decide to have measurement at the end of any iteration – iteration 1, iteration 2, and/or iteration-N.

A (product) backlog-based representation with earned value related calculations is depicted in the figure below.

As shown, the EV, PV, and AC values are calculated on the status/data date, which occurs at the completion of the iteration. The PMB is set for the release, and this also informs the budget at completion (BAC) for the release.

Next, we will consider the metrics associated with EVM in an Agile environment. 

EVM Metrics in Agile Approaches

The foundational EVM metrics used in Agile are noted in the below table with explanations. As you can see, the traditional metrics of EV, PV, AC, and BAC are also taken-up in Agile development; however, the explanation and understanding with respect to Agile contexts are different.

The values for PV, EV, and AC are calculated at the end of every iteration (you can set the status date as of the end of the concerned or considered iteration), whereas the BAC is determined at the release level. This is in sync with the backlog-based representation that we saw earlier.

The budget at completion (BAC) at the release level will be calculated as follows:

Budget at Completion (BAC)

= Total budget for the release

= Number of Items in the Release * Cost per backlog items (or cost per PBI)

For every item in the backlog (PBIs), cost is usually considered, which is one of the key product prioritization factors.

Now that we have the BAC, we can easily calculate the EV and PV, respectively with the below formulas:

First taking PV, the formula will be:

Planned Value (PV)

= Percentage of planned complete * BAC

= % of planned complete * BAC.

Earlier I said, PV, EV, and AC, etc. are calculated as of the status/data date or the iteration completion date. Considering an scenario where you have five iterations in a release and you are measuring at the end of the 2nd iteration, we’d see the following: case:

Percentage (%) of planned complete

= Iteration number / Number of iterations

= 2/5

= 40%

The formula for earned value (EV) will come out as shown below.

Earned Value (EV)

= Percentage of actual complete * BAC

= % of actual complete * BAC.

Why are we considering percentage of percentage of actual complete for EV? It’s because earned value is the value that you have earned by completing the work or having “done” the work.

To determine the percentage of actual completed work, you have to consider the stories that have been completed at the end of an iteration. Let’s say you have completed 40 story points worth of work out of 200 in a release, and you’re at the end of 2nd iteration. The percentage is calculated as follows:

Percentage (%) of actual complete

= Story points completed (or done) / Total story points

= 40/200

= 20%

I’ve summarized the calculations in the below table. 

So far, we have shown small examples with respect to BAC, PV, EV, and AC. Based on these metrics, we can easily calculate the current performance metrics of SV, CV, SPI, and CPI using the formulas mentioned in Table – 2.

For this purpose, let’s take an example from the course, ACP Live Lessons, Guaranteed Pass, to compute the associated metrics. A dedicated set of videos are available in the Live Lessons course.

An Example – EVM In Agile

A project is being released in an Agile mode. Below are the details for the project:

• Product Backlog = 500 story points
• In the first release = 200 story points
• Velocity = 25 points per iteration
• Cost per point = $1600
• At the end of 1st iteration, actual cost incurred was $30,000.
• At the end of 1st iteration, story points completed were 20 story points.

With this, we can determine the following.

• Budget at Completion (BAC)
• Number of Iterations
• Planned value per iteration (PV) and Earned Value (EV) for the first iteration
• Schedule Variance (SV) and Cost Variance (CV)
• Schedule Performance Index (SPI) and Cost Performance Index (CPI)

If you have understood so far, you can try it on your own and determine the values being asked in the above questions.

To confirm your understanding and reaffirm your answer, the solution is noted below.

Budget at Completion (BAC)

= Cost per point * Number of story points

= $1600 * 200

= $320,000

Total number of Iterations

= Story points in a release / Velocity

= 200 / 25

= 8

Percentage (%) of planned complete at the end of first iteration

= Iteration number / Total number of iterations 

= 1 / 8

= 12.5%

Percentage (%) of actual complete at the end of first iteration

= Total number of story points completed / Total number story points planned

= 20 / 200

= 10%

Now that we have the needed values, let’s calculate the other associated metrics of PV, EV, and AC.

Planned Value (PV) for the iteration

= % of planned complete * BAC

= 12.5% * $320,000

= $40,000

Earned Value (EV) for the iteration

= % of actual complete * BAC  

= 10% * $320,000

= $32,000

The actual cost (AC), as mentioned in the question

= $30,000.

With these calculations, we can now determine the current performance metrics of the project at the end of the first iteration.

Schedule Variance (SV)

= EV – PV

= $32,000 – $40,000

= – $8,000

Cost Variance (CV)

= EV – AC

= $32,000 – $30,000

= + $2,000

Look at Table – 2. One could say the release is behind schedule and under budget by looking at the performance metrics of SV and CV, respectively. This is because SV is negative (bad), whereas CV is positive (good).

Next, let’s determine the values for SPI and CPI.

Schedule Performance Index (SPI)

= EV / PV

= $32,000 / $40,000

= 0.8 

Cost Performance Index (CPI)

= EV / AC

= $32,000 / $30,000

= 1.07

Again, referring to Table – 2, you could say the release is behind schedule and under budget by looking at the performance metrics of SPI and CPI, respectively. This is because SPI is below one (bad), whereas CPI is above one (good). 

Representation in S-Curve

Like a traditional EVM, in Agile context, you can also depict the various EVM metrics in an S-curve. These curves are frequently used in many projects to depict the progress and status reporting. However, your perspective has to change/adapt for the Agile context.

An S-curve showing BAC, EV, PV, AC, SV, and CV is shown in the below figure. 

The BAC is at the release level. The PMB line is along the EV curve. Our status date or data date is at the completion of Iteration – 3, and, on this date, we are measuring the foundational metrics of PV, EV and AC, as well as the current performance metrics of SV, SV, and hence, associated SPI and CPI. When you combine this representation with estimated story points in the product backlog, you can have the release burn-up chart. 

Video – EVM in Agile

As we close, I want to summarize the foundations of EVM in Agile in the below video, taken from the course, ACP Live Lessons [duration: 13m:06s]. This video notes certain key points you should keep in mind when calculating earned value in an Agile domain. It also further explains the above S-curve. For the best experience, you may want to go full-screen in HD mode and plug-in your earphones.

With this, I believe, I leave you with the fundamentals of earned value management executed in Agile environments.

If you have comments, suggestions, or new ideas, please do share them below.

--

This article was first published by MPUG.com on 22nd September, 2020. This is a refined version.

References

[1] Course: ACP Live Lessons, Guaranteed Pass or Your Money Back, by Satya Narayan Dash

[2] Book: I Want To Be A PMI-ACP: The Plain and Simple Way, 2nd Edition, by Satya Narayan Dash

[3] Course: ACP 21 Contact Hours, with Money Back Guarantee, by Satya Narayan Dash

Retrospectives and Intraspectives for Agile Practitioners

Two woodcutters were assigned to chop wood in a forest. Both formed a team and started early and earnestly. Although working a distance from each other, they felt the competition to produce the best results.

On that first day, the first woodcutter heard his counterpart stop cutting before the day was really finished. He was surprised, but continued none-the-less. In the next few days, a similar thing happened. A couple of weeks passed. The first woodcutter paid a visit to the second one, confidently thinking that he has cut more wood since he had been working such full, long days. He was taken aback seeing that his counterpart has almost completed twice as much work. He asked, “How is that possible? I never stopped or took a rest, whereas you stopped many times!” The second woodcutter replied, “Yes, but I didn’t actually stop. Rather, I sharpened my axe, so that I could continue cutting better for the next day, the next week, and the weeks ahead.”

Perhaps many of us know this story of the two woodcutters and the key takeaway: “sharpen the axe once in a while and you get better results.” Stephen R. Covey slightly reworded the moral of the story eloquently in his book “The 7 Habits of Highly Effective People” by saying, “Sharpen the saw.”

Let’s apply this by thinking of a team of Agile practitioners working on a software product. The team has a number of generalizing specialists, who have skills spanning across coding, testing, integration, and deployment among others. They are cutting code instead of cutting wood, are testing the soundness of code instead of the solidness of wood, and so on.

Would you ask them to continue working week after week or month after month without ever sharpening their tools? I guess not.

Retrospectives and intraspectives in Agile development do exactly that. They sharpen the saw, or ask us to reflect, rethink, and act with renewed vigor. They provide a better understanding and also help us to work sustainably over a long period. 

Retrospectives

The importance of taking the time for retrospection comes from one of the 12 core principles of the Agile Manifesto.

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

In Agile, frequent retrospection is done in order to continually improve the effectiveness of the team, project, and organization. The retrospective process consists of two words:

• Retro – meaning recent past, and
• Perspective – meaning the way of looking at things.

Hence, you can say that the retrospective is about looking back or dealing with past events or situations for the purpose of improving in the future. You can define the retrospective process as:

A recurring workshop in which the team looks back on their work over a period, reflects upon it, and learns. The team applies this learning in future work to improve people, processes, and products.

One of the widely used iteration-based Agile frameworks is Scrum where every iteration is known as a Sprint. There is a Sprint Retrospective at the end of every Sprint, and it’s an opportunity for the team to inspect itself and create a plan for further improvements. The plan is preferably acted-upon in the next Sprint. Retrospectives are also applicable in flow based Lean-Agile frameworks, e.g., Kanban, where you can have retrospectives on-demand. 

Types of Retrospectives

In iteration-based Agile development, a project is usually divided into releases and each release into various iterations. Hence, for Agile practitioners, there are three types of retrospectives:

• An Iteration Retrospective: Usually focused on the team involved in the iteration.
• A Release Retrospective: A wider perspective because it may involve other people in the organization who have contributed to the release, but are not part of the core team.
• A Project Retrospective: Also has a wider perspective, and is usually from an organizational point of view.

Retrospectives can happen in the following cases:

• When the team ships something. In a flow-based Agile (like the Kanban method), a release doesn’t happen during a specific time period. It can happen at any time.
• When more than a few weeks have passed since the last retrospective. Again, in a flow-based Agile process, there is no specific time a retrospective can happen. You can decide in such cases.
• When the team is stuck (i.e., the work items are not flowing through the team).
• When the team reaches a milestone. 

Conducting Retrospectives

A retrospective is not a post-mortem meeting, nor should it be a dissection on what events happened wrongly or why. A retrospective should also not be a witch-hunt meeting to put blame on someone or some group. The key to a constructive successful retrospective is for all participants to adhere to the Retrospective Prime Directive, as noted by Norman Kerth, which says:

“Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.”

Four Key Questions

Considering the prime directive, there are four key questions in a retrospective, which can also be used when creating your meeting agenda:

• What did we do well, that if we don’t discuss we might forget?
  (or what is going well?)
• What did we learn?
• What should we do differently next time?
• What still puzzles us?

Look at the wording closely. We aren’t asking what went wrong, rather as the third question goes, we are asking what should be done differently next time.

Five Steps in a Retrospective

A retrospective, as noted, can happen as part of both iteration-based and flow-based Agile frameworks. A retrospective is a process, and it goes through a series of steps. See the figure below. It’s depicts a two-hour (120 minute) retrospective with time spread across the five steps of:

• Step 1 – Set the Stage
• Step 2 – Gather the Data
• Step 3 – Generate the Insights
• Step 4 – Decide What To Do
• Step 5 – Close the Retrospective

Let’s understand these steps.

Step 1: Set the Stage

Here the time box (how much time), goal (what you are going to do), approach (how you are going to do it), and work agreements or ground rules are set. If any particular Agile method is used, then the values of that method are announced. The principle of “Every voice and early” is followed, i.e., everyone should speak, and they should speak early. If they don’t speak early, then they may not speak at all!

Step 2: Gather Data

Once the stage has been set, the next step is to gather data. Start with hard data such as metrics, events that’ve happened, or stories completed. Create a visual record having events, story completion, date, etc. The visual is very powerful. Data doesn’t have emotions; therefore, ensure that you bring feelings into the data by asking questions such as, “When were the participants excited to come to work?”

Step 3: Generate Insights

After you have gathered the data, it’s time to evaluate, analyze the data, and provide insights. This step tells the “why” i.e., we generate meaningful insights from the data collected in the previous step. These insights help the team to work more effectively and efficiently – the main goal in any retrospective.

Step 4: Decide What to Do

This step reveals the “what to do” part or the planning part. If you have a long list of decision action items, choose a few, which the team can commit to doing – preferably in the next one or two iterations. A good way to have the action items implemented is to create story cards or backlog items and have them available in the product backlog. Ensure that you assign action items because it drives commitment.

Step 5: Close the Retrospective

In this step, you close the retrospective. When you close the retrospective, don’t forget to appreciate your team for the hard work done during the iteration (or release or project) and during the retrospective.

Retrospective Techniques

In each of these above steps, a number of techniques can be used. We will discuss a few of them. 

Techniques to “Set the Stage”

1) Check in: In this technique, we hope that people put aside their concerns and participate in the retrospective articulating what they want from it. The retrospective leader asks only one question and each person answers in round robin fashion. The answers are usually in one or two words or a short phrase. Example questions can be:

“In a word or two, what you expect from the retrospective?” Or “What is one thing in your mind as we begin the retrospective?”

2) Explorer, Shopper, Vacationers, Prisoners (ESVP) Quiz: Let’s first understand what the letters in ESVP stand for.

• Explorers: Someone who is eager to know new ideas and insights.
• Shopper: The participant looks over all information, but is happy to go home with one useful new idea.
• Vacationers: The participant is not interested and happy to be left out.
• Prisoners: Someone who thinks that he or she has been forced to attend the meeting and should be doing something else.

In this exercise, each retrospective participant anonymously writes sown his or her position and puts it on a slip of paper or index card. Next, the leader takes the responses and put them into a histogram or a check sheet.

After the results have been collected, you should tear up the cards so that no one is worried about being tracked with handwriting analysis! With this information, you will have a good idea of how your audience feels about the retrospective. This exercise informs about the participants’ attitudes in particular.

Other techniques that can be used in the step of setting the stage are: Focus on/focus off, working agreements, or ground rules. 

Techniques to “Gather Data”

1) Timeline: A timeline is used to stimulate memories of what happened in the time period that just passed. The retrospective participants write down memorable and meaningful events on sticky notes and paste them in chronological order on a board. A sample example is shown below, which in this case, is for an iteration.

 

2) Mad Sad Glad: Here you have three posters labeled – “Mad,” “Sad,” and “Glad.” You can also have color-coded cards or sticky notes. For example: red for mad, yellow for sad, and green for glad.

The team members then put the color-coded cards on the labelled posters and describe times during the project when they felt mad, sad, or glad. This exercise gets the “feeling facts” out on the table.

Other techniques that can be used in this step are: triple nickels, color coded dots, locate strengths, team radar, or like to like. 

Techniques to “Generate Insights”

1) Force Field Analysis: This technique was originally used in a change management context (and also in risk management), but it can be adapted for retrospectives. Here, the team defines a desired state they want to achieve. Then, identifies the following:

• Driving forces (“forces of change”), which affects the desired state positively.
• Restraining forces (“forces against change”), which affect the desired state negatively.
• Factors that can influence reaching the desired state—either by increasing the strength of a supporting factor or by reducing the strength of an inhibiting one.

Utilize a white board and markers with this analytical technique. 

2) Learning Matrix: In this case, participants look at the data generated from four perspectives by brainstorming on them quickly. This is a good technique to use if you are pressed for time. The four perspectives can be put on a flip-chart or white board, each in a quadrant, as depicted in the figure below. 

Brainstorming, Ishikawa diagram, patterns and shifts, and the five whys are some of the other techniques that can be used in this step. 

Techniques to “Decide What to Do”

1) Short Objects: This technique helps to discover differing perspectives on what the team members should or should not do, or should do more or less of. The team brainstorms and put their perspectives on three or two posters or flip charts. The titles of each could be:

• Same as/More of/Less of (SAMOLO)
• Stop Doing/Start Doing/Keep Doing (StoStaKee)
• Keep/Drop/Add
• What Worked Well/Do Differently Next Time (WWWDD)
• Smiley/Frowny 

2) Prioritize with Dots: This technique is used to check how the team prioritizes a long list of changes, ideas, issues, or proposals. Here each participant is given 10 dots to be used across the issues. A scale, such as shown in the following bullet points, can be applied.

• Priority 1 issues receive four dots.
• Priority 2 issues receive three dots.
• Priority 3 issues receives two dots.
• Priority 4 issues received one dot.

The issues that have the most dots are chosen, and those should be focused on.

Other techniques that can be used in this step are: retrospective planning game, SMART (specific, measurable, attainable, relevant, and timely) goals, and circle of questions. 

Techniques to “Close the Retrospective”

1) +/Delta (Plus/Delta): This technique is used to retrospect on the ongoing retrospective and identify areas of strength and areas needing improvement. It starts with drawing a “T” on a flipchart or white board, divided the space into two parts: “+” and “delta.” The items that the team should do more of should be listed under “+” and ones that can be changed by the next retrospective are put under “delta,” which is the Greek alphabet meaning “change.”

 

2) Return On Time Invested (ROTI):

This technique generates feedback on the retrospective process itself and determines the effectiveness of the retrospective session from team members’ perspectives, by asking if the participants believe their time was spent well. You can use a scale rating system (“0” representing a lost cause and “5” indicating a very high return or the highest ROTI).

Other techniques that can be used in this step are: appreciation, temperature reading, helped, hindered, hypothesis (HHH), etc.

 

Intraspectives

The term, intraspective, consists of two words – intra meaning within (or insider) and perspective meaning the way of looking at things. Hence, intraspective is defined as an inspection or reflection for the team, within an iteration. Like a retrospective, an intraspective is a reflecting practice; however, unlike retrospective, it’s often preceded by an event that didn’t go well. Unlike the retrospective process, which can happen at points throughout the project, at the time of a release, or at the project level, the intraspective process happens within an iteration.

Let’s take an example with Scrum to understand. Post daily scrum, the Scrum Master noticed or heard something about consistent failure in release builds due to frequent configuration changes in the build scripts. The Scrum Master calls for an intraspective meeting on it to figure out if change is needed on the way team is modifying build scripts.

In iteration-based Agile methodology, the introspection meeting is, in essence, a retrospective within an iteration. The need for such can also occur in a flow-based Agile project. The purpose of an intraspective is to discuss a particular issue, event, or activity in order to determine if any change(s) are needed in the team’s practices.

The main goals of an intraspective is to inspect and adapt – the two key foundations of empiricism. Intraspectives happens on an ad-hoc or on-demand basis. It also helps in building a self-organizing team. 

Key Points about Retrospectives

Irrespective of the type of retrospective or techniques used in a retrospective, below are a few key points to note while conducting one.

Item #1: Everyone should participate: If you remember the “setting the stage” step, we first discussed a check-in, which asked for everyone’s participation. When there is buy-in from the team as a whole, it is easier to proceed with further actions and improvements.

Item #2: Choose two techniques for each step (one short and one long). There can be many techniques or activities in the five steps of a retrospective. Preferably have one short and one long for each step, and you may altogether skip the shorter one, if you lack time.

Item #3: The Product Owner (PO) should be present: The PO is a core part of the team and should be present at retrospective meetings. As I interact with Agile practitioners, lack of the PO’s involvement has been noted by many as the most pressing issue. It’s important that the owner is a part of reflection discussions.

Item #4: For a longer retrospective, consider breaks. If the retrospective is more than two hours, ensure you have break on your agenda, even if it is just 10 minutes. Schedule breaks when there is a logical breaking point, when the energy level of the team drops, or when team members ask for one.

Item #5: Retrospective is not a post-mortem session. Any meeting that turns into dissecting issues or finger-pointing is futile. The retrospective should never be a whining session, rather an opportunity to contribute, reflect, and plan actions. Remember the story of the woodcutters and the retrospective prime directive, noted earlier.

--

This article was first published by MPUG.com on 15th October, 2019.

 

References

[1] I Want To Be An ACP – The Plain and Simple Way, by Satya Narayan Dash

[2] Agile Retrospectives – Making Good Teams Great by Esther Derby, Diana Larsen, and Ken Schwaber

[3] Agile Practice Guide, by Project Management Institute (PMI)

PMI-ACP Success Story: Agile is Essential for Delivering Customer Value and ROI – Early and Continuously

By John P S Oliver, ACP, PMP, PBA, RMP

Introduction

Being in the financial services industry which is highly regulated, my organization started to increasingly embrace the agile way of approach in its projects to achieve customer satisfaction and realize benefits early. Being a functional owner with a high focus on improving process efficiencies and effectiveness, we started following the agile approach for the implementation of various improvement initiatives like automation of manual processes, improving compliance etc.

While I had touched upon agile practices during my preparation for PMP® certification, with the continued emphasis on agile approach for our projects, I believed that gaining a deeper knowledge and practice of the agile values, principles and approaches will help me in my quest to become a successful agile practitioner and hence I decided to pursue the PMI-ACP® certification.

First Preparation

Once I decided to pursue the PMI-ACP certification, I reached out to Satya Sir for his inputs on getting the mandatory 21 hours of training in agile practices. Satya Sir advised me to go through the PMI®’s Agile Practice Guide which was one of the primary reference books for the PMI-ACP certification exam. I also came to know about his recently updated book: I Want To Be An ACP, Second Edition.

I started my preparation for the PMI-ACP certification with reading PMI’s Agile Practice Guide. I completed reading the Agile Practice Guide and enrolled with a service provider for an online course of PMI-ACP training. 

Once I completed the online course and received the mandatory PDUs, I submitted my application for PMI-ACP certification.

Upon receiving approval from PMI, I reached out to Satya Sir and decided to use his book “I Want To Be An ACP, Second Edition” for my certification exam preparation.

Own Study

I started my preparation for the exam with creating a plan to complete one chapter with the corresponding chapter end questions from Satya Sir’s book: I Want To Be An ACP, Second Edition.

I had applied for 2 weeks of leave and dedicated 8 hours a day for preparation.

The only books I referred were Satya Sir’s book, I Want To Be An ACP, Second Edition, PMI’s Agile Practice Guide and PMI-ACP exam content outline.

For the sample questions, Satya Sir’s book has 3 complete full set questions in addition to the chapter end questions. I also used the sample questions that came with the online training course that I enrolled for the mandatory PDUs.

I completed the chapters of Satya Sir’s book twice (Initial reading and Revision) and completed the 3 complete full set of questions once.

Book Review - I Want To Be An ACP

The reason for going with Satya Sir’s book - I Want To Be An ACP, Second Edition as the primary reference book was the confidence due to the fact that I had already used his books and study materials in my preparation for PMP® and RMP® certifications and they were instrumental in passing the exams.

My PMP exam experience:
PMP Live Lessons Was Instrumental in Getting My PMP Credential

My RMP exam experience:
Risk Management - Essential for Professional and Personal Success 

The book encompasses knowledge from all the reference books listed by PMI for ACP certification. In fact, in my opinion, this book is a one stop reference book for the PMI-ACP certification exam.

The book follows the pattern of the PMI-ACP exam content outline (ECO), aligned with PMI's Agile Practice Guide and so is easy to follow and cross reference. 

The vision and revision tips in the book helped me to immediately refer relevant topics for revision. The chapter end questions helped me to gauge my understanding of the topics. I used them to revise the portions in relation to the questions where I went wrong.

The 3 complete full set of questions were of high quality and the explanations for the answers helped me immensely in understanding the reasoning behind the correct choice. I was able to improve my performance with each mock exam.

ACP Exam Experience

I completed the initial reading of Satya Sir’s book completely with the chapter end questions and scheduled my exam for 7-January-2021, 8:00 AM slot at the Pearson Vue centre, Chennai. I used the remaining days to complete the revision and the mock exams.

I reached the centre by 7:30 AM on the exam date and completed the formalities. I started my exam at around 8 AM. As I progressed through the exam, I noticed that I was taking more time for each question compared to the time taken in mock exams and hence kept a track of the remaining time. I completed the exam without any break and with 6 minutes to spare. I submitted my responses and competed the survey. I was happy to see the congratulatory message on successfully obtaining the PMI-ACP certification.

Types of Questions Faced

• The majority of the questions were situational in nature.
• Very few graphical questions.
• Very few mathematical questions. 
• More questions on Value Driven Delivery, Agile Principles and Mindset and Stakeholder Engagement domains.

Suggestions for ACP Aspirants

Dos

• Plan and schedule the exam well in advance.
• Prepare a realistic schedule and follow it.
• Prepare a short list of reference books and use them for your preparation.
  (Ideally not more than 2 if you go for Satya Sir’s book)
• Schedule enough time for taking up mock questions and revision.

Don’ts

• Do not use more than 2 or 3 study resources as you can spend the extra time available on attempting more mock questions.
• Do not attempt questions before you completely study the resources at least once.
• Don’t panic during the exam if you do not know the answer for a particular question, Mark it for review and proceed with the next one – You can always come back to the marked question later.

Conclusion

I would like to thank the Almighty for his blessings, my reporting manager for approving my leaves for preparation and Satya Sir for his book: I Want To Be An ACP, Second Edition.

Brief Profile:

Name: John P S Oliver

Current Role: Supply Chain Manager

Experience: 23+ years of experience in ITES operations and project management across BFSI, Healthcare, Telecom and Retail verticals.

Book Available for ACP Exam Prep:

• New Book for ACP Exam Prep: "I Want To Be An ACP"

Sample Questions:

• 30 NEW PMI-ACP Free Questions with Answers (Part - 1)
• 30 NEW PMI-ACP Free Questions with Answers (Part - 2)

Book Excerpts:

• Book Excerpts: "I Want To Be An ACP" - Agile Principles and Mindset
• Book Excerpts: "I Want To Be An ACP" - Problem Detection and Resolution
• Book Excerpts: "I Want To Be An ACP" - Fundamentals of Value-Driven Delivery
• Book Excerpts: "I Want To Be An ACP" - Four Values of The Agile Manifesto

PMI-ACP Success Stories:

• PMI-ACP Live Lessons Success Story: ACP Live Lessons is the Best Way to Earn Your PMI-ACP Credential
• PMI-ACP Success Story: Learning By Doing Will Make You Successful 
• PMI-ACP Success Story: Learn Agile Concepts in Greater Depth To Earn This Credential
• PMI-ACP Success Story: Innovation Games Make The Difference!
• PMI-ACP Success Story: Agile is Transforming The IT Industry and ACP Credential Equips You to Lead this Transformation
• PMI-ACP Success Story: Being Agile and Thinking In Agile Way Help To Crack The Exam
• I Want To Be A PMI-ACP Book: One Stop To Crack The ACP Exam
• I Want To Be A PMI-ACP Book: Important Not Only for The Exam, but also a Treasure of Knowledge to Apply in The Real-World