Here is a simple exercise for gaining a common understanding and consensus about what it means to you, the team, and the organization to be Agile.

Here is a simple exercise for gaining a common understanding and consensus about what it means to you, the team, and the organization to be Agile.

The Challenge

The modern world of Agile systems-software product development and delivery presupposes we work faster and better, do more with less, change continuously, and invent new ways of working. The modern formula for work appears to be:

Peoples beliefs, understanding and perspectives as well as their willingness and ability to change makes being Agile hard.

Contributing to this challenge is a proliferation of new vocabulary, new terms, old terms having new meaning, guidance, books and articles on the subject and ones interpretation of what it means to be Agile as depicted below.

Goal of the exercise

Minimize frustration and waste usually associated with gaining consensus on what it means to an individual, team and organization to "be Agile"; as they work through the forming, storming, norming and performing stages of team development.

Objective

Early adoption of what it means to the individual, team, and organization to be Agile; the results of which will minimize frustration and waste.

Instructions:

1. Break up into teams and if there are:

a. 2-3 people work independently

b. 4-5 people break into 2 teams

c. 6 or more people go for a maximum size of 3 people per team

d. Do not distribute any handouts yet

2. Have teams draw a tree that has at least 4 roots, a trunk, at least 6 branches and leaves on the branches. Let 5 minutes pass and then distribute Handout-1. Once there is a lull in drawing go to next step.

3. Have the team make a list of what they feel makes up being Agile; seed their list with: iterative and incremental development, scrum, Agile values, concurrent testing and continuous integration. Instruct the teams to document their compromises, negotiations and tradeoffs.

4. Have them put their list of elements aside for the time being. Give the teams the list of items contained in Handout-2 to match to one of the four parts of their tree. Once again instruct the teams to document their compromises, negotiations and tradeoffs. Do not show Handout-3 to teams yet.

5. Distribute Handout-3 and get back together as a group and have individuals share and discuss as an entire group the differences.

a. Place the trees the teams drew in plain site for all to see

b. Have a group discussion first about the differences between Handout-3 and their tree.

c. Next compare and discuss list of elements from Step 3 and the list of items on Handout-2 and depicted on Handout-3.

Handout-1

Significance of Roots

They provide a solid foundation that will nourish and support the tree. In the case of being Agile and creative Agile thinking they represent the key foundational elements of being Agile.

Significance of Trunk

The roots absorb water and nutrients from the soil, which are then transported up the tree trunk. Just like the trunk is the part of a tree that connects the leafy crown with its roots people with their depth of knowledge and specific skill levels connects the fundamentals of what it means to be Agile to the actual doing the work and delivering commercial or operational value.

Significance of Branches

The branches represent common approaches/practices or key building blocks for doing something with a specific purpose in mind. An ordered set of assembled practices is a practice pattern (dare I say process).

Significance of Leaves

The leaves obtain water and nutrients from the roots through the trunk that are necessary for the manufacture of food from light energy (photosynthesis). Food made in the leaves is then transported down to the roots and to other parts of the tree for growth. The leaves represent results and the symbiotic relation between practices, people and the key elements of being Agile.

Handout-2

Iterative and Incremental Development

Continuous Integration

Agile Manifesto: Values and Principles

Concurrent Testing

Test Driven Development

Leading Change

Scrum

Lean

People (Team/Individual)

Four Level Planning

Acceptance Test Driven Development

Visual Modeling

Daily Stand-Up

Sprint Review

Sprint Retrospective

User Story Empowered Development

Product Backlog

Inspect and Adapt

Requirements

Use Cases

Evolving Architecture s

Charts: Velocity, Burn-up, Burn-down

Evolving Architecture

Handout-3

About the AuthorRussell Pannone is the Founder of We Be Agile and the Agile Lean Phoenix User Group, as well as the Agile-Lean Adoption Lead. With almost 30 years of system-software development and delivery experience, my focus is on working side-by-side with folks on real projects helping them deliver valuable system-software to production early and often, giving those I collaborate with the best opportunity to beat the competition to market, realize revenue and discover insights that we can use to help us improve.

About the author

The opinions and positions expressed within these guest posts are those of the author alone and do not represent those of the TechWell Community Sites. Guest authors represent that they have the right to distribute this content and that such content is not violating the legal rights of others. If you would like to contribute content to a TechWell Community Site, email editors@techwell.com.