Agile Principle 2: Embrace Change

Let's take a look at the second underlying principle of the agile manifesto:

"Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage."

What does that really mean? What are the implications for our daily business? Let's analyze this principle and see where this gets us.

• "Welcome" - creates a positive and open feeling/invitation.
  Values: Openness, Respect
  Principles: Opportunity, Humanity
  Practices: Sprint Planning, Planning Game
• "changing requirements" - do not take any requirement granted as reality is not a static system. People, markets, demands, all things in general are in a constant flow and change. We have to accept this in every aspect of our work.
  Values: Openness, Courage
  Principles: See the whole, Reversible changes during development, Adaption
  Practices: Real Customer Involvement, Product Backlog, Sprint Review
• "even late in development" - there is no valid time to fix a set of requirements even if the project's end is a few weeks in the future. Things may change at any time.
  Values: Openness, Courage
  Principles: Decide as late as possible, Opportunity
  Practices: Real Customer Involvement, Product Backlog, Sprint Review, Planning Game
• "Agile processes harness change for the customer's competitive advantage" - As in the first principle (Satisfy the Customer) our goal is to help and serve the customer/user. Let the customer always be the center of everything we do.
  Values: Openness, Commitment, Focus
  Principles: Mutual Benefit, Opportunity, Economics
  Practices: Frequent Delivery, Sprint Review, Product Backlog, Real Customer Involvement

In summary we have to be open to any changes and need the courage to help the customer adopting to these changes. To say it in two words, the second principle is about Embrace Change.


Also read in this blog post series:

• Agile Principle 1: Satisfy the Customer
• Agile Principle 2: Embrace Change
• Agile Principle 3: Frequent Delivery
• Agile Principle 4: Cross-Functional Collaboration
• Agile Principle 5: Support and Trust
• Agile Principle 6: Face-to-Face Conversation
• Agile Principle 7: Working Software
• Agile Principle 8: Sustainable Pace
• Agile Principle 9: Technical Excellence
• Agile Principle 10: Keep it Simple
• Agile Principle 11: Self-Organization
• Agile Principle 12: Inspect and Adapt

Agile Principle 1: Satisfy the Customer

Let's take a look at the first underlying principle of the agile manifesto:

"Our highest priority is to satisfy the customer through early and continuous delivery of valuable software."

What does that really mean? What are the implications for our daily business? Let's analyze this principle and see where this gets us.

• "Our" - who is us? At least a bunch of people forming some kind of team. We can't define this in more detail, so let's skip the answer for now and analyze some more first.
  Values: Communication
  Principles: Diversity, Accepted Responsibility, Empower the Team
  Practices: Whole Team
• "highest priority" - the team should not be distracted and keep its focus on the most important things. To help the team not to be distracted, it should be guarded in a secure environment so that no external influences are able to grab its attention.
  Values: Commitment, Focus
  Principles: Limit work in progress, Economics
  Practices: Product Backlog
• "satisfy" - how can the team know if its results are satisfying? A definition of "done" and passing acceptance tests of every requirement of the software are necessary for the team.
  Values: Commitment, FocusPrinciples: Active User Involvement, Business Value, Quality, Failure
  Practices: Definition of Done, Real Customer Involvement, Acceptance Tests, Sprint Review
• "the customer" - who is this? In an ideal world this customer is all different kinds of users of the resulting software. As it is not always possible to have all these personas on board, the customer could also be represented by a Product Owner.
  Values: Communication, Respect
  Principles: Active User Involvement
  Practices: Real Customer Involvement
• "early delivery" - the first results of the wanted software have to be given to the users as soon as possible so that they can give their feedback and generate more insights about what they really need and want.
  Values: Feedback
  Principles: Frequent Delivery, Incremental
  Practices: Incremental Deployment, Small Releases
• "continuous delivery" - it is not enough to show the first result of the software but it is necessary to show intermediate results on a short regular basis.
  Values: Commitment, Feedback
  Principles: Flow, Iterative
  Practices: Product Demonstration, Iteration
• "valuable software" - who can define the value of the software? It is the "customer" again who is able to prioritize requirements by their business value.
  Values: Commitment, Focus
  Principles: Economics, Business Value
  Practices: Product Backlog

Now let's get back to the first part of this principle: who is the team? The team contains all people required to create working software out of requirements, to test the software, to prioritize the requirements and to define their values, and to concentrate on focus and commitment. If these people all work together, the first principle can be realized.

If we summarize all roles and practices this first principle reveals, we find a fully functional team working with an incremental-iterative approach on the most important things for the user. Sounds like heaven.

To say it in three words, the first principle is about Satisfy the Customer.


Also read in this blog post series:

• Agile Principle 1: Satisfy the Customer
• Agile Principle 2: Embrace Change
• Agile Principle 3: Frequent Delivery
• Agile Principle 4: Cross-Functional Collaboration
• Agile Principle 5: Support and Trust
• Agile Principle 6: Face-to-Face Conversation
• Agile Principle 7: Working Software
• Agile Principle 8: Sustainable Pace
• Agile Principle 9: Technical Excellence
• Agile Principle 10: Keep it Simple
• Agile Principle 11: Self-Organization
• Agile Principle 12: Inspect and Adapt

Principles behind the Agile Manifesto

All people working in an agile environment should reflect on the principles behind the agile manifesto from time to time. What do these principles really mean? What impact do they have for my daily business? Do my habit follow these principles?

There's a nice exercise for agile teams to summarize each of the principles down to 3 or 4 words. An agile team needs to have a shared understanding of the principles and what they imply for the team's behavior.

I'm going to start a blog series on all twelve of the agile principles. Following goals I'd like to achieve:

• Extracting the essence of the principle
• Determining values, practices, and other principles as sources of the principle

For cross-referencing I'll focus on the values, principles, and practices of Scrum, XP, and Lean just to cover the current mainstream methods.

If you find more or better of values, principles, and practices please drop me a line or a comment so we can add your input accordingly.

Table of content:

• Agile Principle 1: Satisfy the Customer
• Agile Principle 2: Embrace Change
• Agile Principle 3: Frequent Delivery
• Agile Principle 4: Cross-Functional Collaboration
• Agile Principle 5: Support and Trust
• Agile Principle 6: Face-to-Face Conversation
• Agile Principle 7: Working Software
• Agile Principle 8: Sustainable Pace
• Agile Principle 9: Technical Excellence
• Agile Principle 10: Keep it Simple
• Agile Principle 11: Self-Organization
• Agile Principle 12: Inspect and Adapt

[German Version of this article: http://agilecoach.de/2011-09-26/prinzipien-hinter-dem-agilen-manifest/]

Book: The Five Dysfunctions of a Team

The definitive must-read for everyone having anything to do with teams!

Author: Patrick Lencioni
Title: The Five Dysfunctions of a Team

Rating: highest recommendation!

Have you ever wondered why weekly team meetings become meaningless rituals without any results? Have you ever had the feeling that important topics were not discussed and severe conflicts not surfaced?

This book offers a very simple model of five dysfunctions of a team. The model explains typical anti-patterns of behavior you can recognize in many teams:

1. Absence of Trust
2. Fear of Conflict
3. Lack of Commitment
4. Avoidance of Accountability
5. Inattention to Results

Some nice exercises to overcome these dysfunctions are described as well.

The first 90% of the book are written as a novel which is easy to read and understand but still highly exciting and insightful. The latter part of the book contains the pure description of the model and the exercises. But it's much more fun to read the novel and see how Kathryn--the main protagonist--is analyzing and guiding the team away from its old habits and dysfunctions.

In the real world you could use the model for team building events or retrospective meetings. Explain this simple model to your team and confront them with their habits. As simple as it is to understand, as hard is it to live it in a team. Just do it and give it a try!

I give this book the highest rating possible. Buy it, study it, apply it, share it with your peers!

Book: Fearless Change

If you need to get some activities to drive change, read this book.

Authors: Mary Lynn Manns, Linda Rising

Title: Fearless Change

Rating: recommended

You work as a change agent? You have a new idea for your organization and want to change processes and interactions? This book may be helpful as it presents 48 patterns for introducing new ideas.

The first part of the book describes a general approach with many examples how to apply all the different patterns. The second part contains detailed descriptions of the patterns with many cross-references between them.

Although the majority of the patterns should be well known to change agents, there might be many insights how to initiate and maintain changes inside an organization. In my point of view there are no brand-new approaches presented in the book. The highest value this book provides is giving an elaborated pattern language so people involved in change are able to talk about the same things with the same wording.

This review may sound as the book would not be worth its pages. Don't get me wrong. It contains a very nice reference and map of change patterns to look up. I'm going to take a look at a random pattern from time to time just to get a reminder and maybe new insights.

Read it so we can talk about it!

Done-Related Story Estimation

In today's Backlog Grooming I tried a new method of estimating user stories. The estimations were based on and related to known done-stories of former sprints. The method is very simple and contains only five steps. 

Step 1: Get user stories from Product Owner

Your Product Owner should be prepared for Backlog Grooming and bring his top-priority stories for discussion and estimation.

Step 2: Select reference stories

Pick a few random stories from your already done stories. Make sure their story points differ enough so a typical mixture of story points is in the set. In today's experiment I chose stories with 3, 5, 8, and 20 points.

Then write a new reference story card for each of them in the following way: write the story on the front of the card and write its story points on the back of the card. Make sure to hide the story points from the team's eyes for now.

Step 3: Sort user stories

Let the team find the right order of old reference stories and new undone stories. You will notice much more comparative conversation on the stories than with playing Planning Poker.

Step 4: Show story points

Now the fun part begins. Turn the reference stories and surprise the team by showing the reference story points.

Step 5: Adjust stories and story points

Let the team discuss if any adjustments are necessary. There will be more conversations on single cards to gain more understanding. Some stories may change due to these conversations. Take care that stories with high points get split properly. In today's example the story at the bottom with 20 points could be discussed and split into two stories. The result was much deeper understanding of the real value for both the team and the Product Owner. 

I'm looking forward to the Sprint Planning meeting next Monday.

Book: Harrison Owen - Wave Rider

Everyone dealing with self-organizing teams should read this book!

Authors: Harrison Owen

Title: Wave Rider: Leadership for High Performance in a Self-Organizing World

Rating: highly recommended

Have you ever wondered why in a well-defined organization there are always a few "key" people who know how things really do work? Have you ever thought about how to plan and deliver the daily food supplies for several million people? Read this book to find out.

In the first part of this book Harrison Owen offers deep theoretical insights of High Performance Systems, Self-Organization, and Open Space Technology. According to his definition, the three major elements of High Performance are chaos, confusion, and conflict, which lead to wholeness, health, and harmony--be it in small teams or large organizations. He states the necessity of grief work at the end of anything, and that--although highly important--such grief work rarely happens. The reason of missing self-organization is the need of control coming from traditional habits and thinking.

The second part of the book is written for practitioners and shows "eight essential steps for the care and feeding of self-organizing systems":

1. Do Your Homework Before You Start.
2. Extend an Invitation.
3. Come to the Circle.
4. Welcome Passion, Responsibility, and Authentic Leadership.
5. Remember the Four Principles.
6. Observe the Law of Two Feet.
7. Keep Grief Working.
8. Formalize the System.

This may sound weird at the first look but it gives a very nice description how Open Space works and how to do it.

The book is an eye-opener and offers so many insights why and how self-organizing systems work. The level of understanding one may reach by reading this book is not restricted to Open Space but is applicable to any organizational structure.