Tag Archives: Agile software development

Agile Principles Constellation – A Retrospective

Have you ever wondered if what you are doing is “agile?” Sometimes the work you’re doing doesn’t feel like it has much “agile” to it, especially if you are being asked to do a specific set of work in a specific time frame. Damn you, iron triangle!

Agile Principle of the ManifestoYour workplace isn’t “agile” or “not agile.” Certainly there are parts of your organization that will be aligned with agile principles, and there are some aspects that are likely not. This retrospective is designed to explore your organization’s alignment as it relates to agile.

Here is the outline of the retrospective. Feel free to adapt it as you see fit. If you do adapt it, please let me know what changes you made.  If you use this retrospective, I would like to hear how it went. You will note that the general flow for this retrospective matches the outline in the book Agile Retrospectives – Making Good Teams Great by Esther Derby and Diana Larsen.

Set the Stage With One Word Check In

One word check-in. Consider something like “how did the last sprint feel?” This gets everybody to talk at least once.

Gather Data Using a Constellation

The constellation exercise is a way to visualize the degree to which people feel a principle is present or absent from their work. Here is how to conduct this activity:

The facilitator reads one principle out loud, and then places it on the floor near the center of the room.

People then position themselves relative closer or farther from the statement based on how much they feel the principle is present in their environment (e.g., team, organization, company, whichever you chose). If somebody feels it is strongly present they would stand close to the principle you placed on the ground. If somebody feels it is not present or “anti-present”,  they would stand very far away.

Give people a moment to observe the pattern and perhaps jot down anything they noticed.

Pick up the principle you just used, and move on to the next one. After all twelve principles have been read, move on to generating insights.

Generate Insights

Ask people what they noticed about the constellations that took place during the Gather Data activity. Some question you might consider include:

Which of the principles were strongly present? Which were strongly absent?
What similarities or differences did you notice about those principles?
Which had the most disagreement amongst the group?
Which had disagreement by role?
Which had some individuals who felt differently than the majority of the group? What unique perspective might those individuals have?

Decide What to Do and Closing

I would encourage you to determine what kind of activity makes sense for your team to use for the “Decide What to Do” and “Close”. If you want to get more options for these phases, jump on over to the Retromat and give it a spin.

Retromat Screenshot

Background on some of the decisions

Why did I choose to do all twelve principles before generating insights?

I didn’t want to do a deep dive on each of the principles. I was more interested in having the team see the constellation that formed for each principle, and then generate insights on a subset of the twelve.

Why did I choose not to do a constellation based on the “left side versus the right side” of the Agile Manifesto itself?

Certainly, you could create an activity around the values in the Agile Manifesto. However, I have found that the values of the manifesto are a little too vague for this type of conversation. While the principles are more specific, they are still general enough to generate deep conversation.

Preparation and Supplies

Plan to use a room that is fairly open, leaving enough room for people to move about freely.

In preparation for this retrospective, print out each Manifesto principle on its own sheet of paper.

Have a note-card for each individual participating, so they can make notes about their observations. Maybe pre-print each Manifesto principles on a separate 3×5 or 4×6 card for each person.


It is very important for individuals, teams, and organizations to explore the principles behind how they operate, and not simply follow the rules of the framework-du-jour. The goal of this framework is to explore those principles. Please feel free to add your thoughts.

Is Kanban really Agile?

Short Answer

Honestly, it doesn’t matters. If it helps an organization create value for its customers in a way that allows employees to experience freedom while solving challenging problems, it doesn’t matter what label the method carries! But, that would be too short a response.

Longer Answer

One way to decide if something should wear the label “agile” is to look at how it reflects the values stated in the Agile Manifesto. Of the Agile Manifesto statements, this is how Kanban values the “items on the left” over those on the right.

Individuals and Interactions over Processes and Tools

The visibility that Kanban provides to teams is a key contributor to facilitating interaction amongst individuals. The kanban board gives visibility to impediments that individuals are encountering makes resolving the impediment of prime importance.

Unlike Scrum, Kanban does not explicitly encourage generalization of skill sets. While Kanban does not force you to have a role for every queue, it is often easy to start by mapping the roles to queues and then inspect the bottlenecks and address those by helping the team develop more generalized skills.

Kanban is not a tool or a process that supersedes the importance of the individuals and their interactions. Yes, Kanban provides a lot of metrics that can be used to inform planning. However, the metrics are to facilitate interaction among team members, between team and stakeholders, and between team and customers.

Working Software over Comprehensive Documentation

When using Kanban to produce software, there are specific characteristics of Kanban that allow you to value working software over comprehensive documentation; small batches, WIP limits, measuring and managing flow. Perhaps your workflow will have a step or steps related to creating documentation.

Kanban does not prescribe working software, other than through mapping your value stream. If the last step in the value stream is working software, you can use Kanban as a tool to make sure you do that.

Customer Collaboration over Contract Negotiation

Kanban encourages customer collaboration through the prioritization of the backlog. Prioritization of the backlog is an ongoing process. Agile Kanban practitioners often use user stories or minimal marketable features (MMF). Use of either of these approaches supports customer collaboration in creating those items. The person who provides the detail on the stories or MMF is also available to the team to respond to questions.

As in Agile, daily standups are also present in Kanban. Unlike Agile, only people with issues speak in the daily standup. The standup meeting is an opportunity to speak up, whereas in Agile the traditional “three questions” are often present. This gives the team an opportunity to elevate issues to the Product Management representative’s attention, allowing them to be a partner in the process.

Silver Bullet Policy (see slide 20 for a brief overview) allows the customer to swap out an extremely high priority item for the current work in progress. There needs to be a swap so that WIP limits are not exceeded. Silver Bullet Policy may never be used, but can give the business the feeling that if there is an emergency, they can use this policy.

Responding to Change over Following a Plan

Agile teams often plan on a regular cadence. In Kanban, planning events can be triggered on an event. For example, your team may have a rule as follows: When the backlog backlog has dwindled to ten stories, a planning event will be held.

Unlike Scrum or XP, where the teams try to identify a piece of stability to work on for a period of time, Kanban allows the team to re-prioritize the backlog at any time and take something new off the backlog. This allows the team to respond to change sooner than if they were locked into a set sprint duration.


While Agile is primarily focused on software, Kanban is more focused on developing a lean organization . In fact, the business-oriented language that surrounds Kanban may make it an easier Agile model to embrace than Scrum.

While an organization or team can claim to be using Kanban and use it in non-agile ways, that will not be the case when done well. If the team and management use visualization, set WIP limits, and iterate on the value stream, Kanban is an excellent option for Agile teams.

Find More Information

There are lots of excellent resources on Kanban. My favorite reference is a book called Kanban – Successful Evolutionary Change for Your Technology Business. Thank you, Eric Landes, for loaning me your copy for a while. For further reading, check out the InfoQ version of the Kanban and Scrum Book.

A special thank you to Eric and Susan for co-authoring this blog.

Susan DiFabio, Agile Coach

Eric Landes, Agile Coach

Michiana Agile Practitioners – December Meeting

I just posted a new notice for the Michiana Agile Practitioners gathering at Hacienda (4650 Miami St, South Bend). The meeting will be on December 6th at 5:30 PM, and we are typically done by 6:30 or 7:00. We meet in the patio area, which is closed in and comfortable, even in December. Topics for discussion range from process to engineering practices, and are not limited to one particularly technology stack or another. It’s more of a community than a “meeting, ” so please join and don’t feel any pressure. There is a posting on LinkedIn, so feel free to join the group and participate in the discussion.