Wednesday, March 30, 2011

Agile Principle 7: Working Software

Let's take a look at the seventh underlying principle of the agile manifesto:
"Working software is the primary measure of progress."
What does that really mean? What are the implications for our daily business? Let's analyze this principle and see where this gets us.

  • "Working software" - it does not matter how many modules, interfaces, and documents we have in progress. The only thing that counts is completed, fully functional pieces of the wanted product.
    Values: Commitment, Focus
    Principles: Quality, Active User Involvement, Build Integrity In
    Practices: Definition of Done, Acceptance Tests, Real Customer Involvement, Customer Tests, Product Demonstration
  • "is the primary measure of progress" - no one is interested in the number of work hours, lines of code, or any other technical metric. Only done and releasable features are important.
    Values: Simplicity, Commitment, Feedback
    Principles: Business Value, Frequent Delivery,
    Practices: Incremental Deployment, Small Releases, Release Burndown, Product Demonstration, Measurements

Thursday, March 24, 2011

Agile Principle 6: Face-to-Face Conversation

Let's take a look at the sixth underlying principle of the agile manifesto:
"The most efficient and effective method of conveying information to and within a development team is face-to-face conversation."
What does that really mean? What are the implications for our daily business? Let's analyze this principle and see where this gets us.
  • "The most efficient and effective method of conveying information" - it is not enough to make information available in a passive way but it should be pushed actively to the target audience.
    Values: Communication, Openness
    Principles: Transparency, Make Work Visible, Tell don't ask
    Practices: Osmotic Communication, Informative Workspace
  • "to and within a development team" - do not only expect active communication from the outside of your team but also foster active communication with your own team members.
    Values: Communication, Openness
    Principles: Humanity, Transparency, Make Work Visible, Tell don't ask
    Practices: Osmotic Communication, Informative Workspace, Servant Leadership
  • "is face-to-face conversation" - do not open inefficient communication channels like writing things down on paper, emails, and bug-tracking systems. Rather talk to the receiver of your message directly via phone, video, or in the best case in front of a white board from person to person.
    Values: Focus, Feedback
    Principles: Tell don't ask, Mutual Benefit, Collaboration and cooperation between all stakeholders
    Practices: Sit Together, Team Room
To say it in four words, the sixth principle is about Face-to-Face Conversation.



Also read in this blog post series:

Monday, March 21, 2011

Agile Principle 5: Support and Trust

Let's take a look at the fifth underlying principle of the agile manifesto:
"Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done."
What does that really mean? What are the implications for our daily business? Let's analyze this principle and see where this gets us.
  • "Build projects around motivated individuals" - search and hire Drive-Driven Personalities who love their job and are passionate about what they're doing. Get rid of unskilled or even destructive people as they will have a major negative impact on the project's success.
    Values: Commitment, Courage
    Principles: Opportunity, Amplify Learning, Humanity, Accepted Responsibility
    Practices: Motivation, Energized Work (Continuous Pace)
  • "Give them" - as the Holy Bible already mentions "give, and it will be given to you". Do not demand results from the team but give them what they demand for their private and professional life.
    Values: Respect
    Principles: Empower the Team, Humanity, Supportive Culture
    Practices: Servant Leadership
  • "the environment" - the team needs a proper workspace and the best equipment available to do its work in a professional manner. This is also about the team's processes from a larger organizational point of view. Surround the team with lean structures, try to avoid beaurocratic structures impeding the team's performance and pace.
    Values: Simplicity, Openness
    Principles: Empower the Team, Supportive Culture
    Practices: Whole Team, Team Room
  • "and support they need" - help the team instantly as they get stuck. Clear their path and remove any obstacles. Show them alternative ways to go.
    Values: Courage, Focus
    Principles: Improvement, Adaption, Supportive Culture
    Practices: Servant Leadership
  • "trust them to get the job done" - if you have motivated individuals on the team, you also have to trust them. They are the people knowing exactly how to do their job. Do not let anyone else decide and plan how the team should work and who is going to do what and when.
    Values: Respect, Courage
    Principles: Self-organizing Team, Empower the Team, Humanity, Diversity, Supportive Culture
    Practices: Whole Team, Team Room, Team Continuity, Personal Safety, Energized Work (Continuous Pace)
To say it in three words, the fifth principle is about Support and Trust.




Also read in this blog post series:

Thursday, March 17, 2011

Agile Principle 4: Cross-Functional Collaboration

Let's take a look at the fourth underlying principle of the agile manifesto:
"Business people and developers must work together daily throughout the project."
What does that really mean? What are the implications for our daily business? Let's analyze this principle and see where this gets us.
  • "Business people" - there are people with a vast knowledge of the product's target markets, its users and customers, and its needed features. These people should not be the developers of the product as they normally tend to implement developer-centric, fancy things. The 'business people' should be the ones grooming and prioritizing the product features of the largest customer and business value.
    Values: Respect, Communication
    Principles: Active user involvement, Economics
    Practices: Real customer Involvement, Whole Team
  • "Developers" - in terms of "product developers" not solely coding software developers. This includes also testers, technical writers, interface designers, business analysts, and whatever role is necessary to give input and create a working software product.
    Values: Respect, Communication
    Principles: Diversity, Humanity
    Practices: Whole Team
  • "must work together" - it is not helpful to let experts work on their own and pass over their finished results to the next expert in a process chain. Their output rather should be the result of strong collaboration and communication.
    Values: Communication
    Principles: Diversity, Mutual Benefit, Collaboration and cooperation between all stakeholders
    Practices: Whole Team
  • "daily" - collaboration and communication do only work well on a continuous basis. The Product Owner has to be present and available to the team during the whole iterations, not just at the planning and review meeting.
    Values: Focus, Commitment
    Principles: Flow, Iterative
    Practices: Sit Together, Osmotic Communication, Daily Scrum, Whole Team
  • "throughout the project" - collaboration and communication do not happen during specific project 'phases' only. They need to happen right from the start until the end of the project.
    Values: Commitment, Focus
    Principles: Frequent Delivery, Flow, Iterative, Collaboration and cooperation between all stakeholders
    Practices: Team Continuity, Energized Work (Continuous Pace)
To say it in three words, the fourth principle is about Cross-Functional Collaboration.



Also read in this blog post series:

Tuesday, March 15, 2011

Book: Lyssa Adkins - Coaching Agile Teams


The definitive must-read for every Scrum Master, agile manager, and agile coach!

Author: Lyssa Adkins

Rating: highest recommendation!

This is one of the most valuable books I've ever read in my agile life. More than 300 pages full of practical advice with many examples make this book a perfect reference on the desk of every Scrum Master, agile manager, and agile coach.

Lyssa has a very nice and easy to read style of writing and yet offers so many insights. Following topics are covered in her book:
  • You and your mastery as a coach
  • Coach as Coach-Mentor
  • Coach as Facilitator
  • Coach as Teacher
  • Coach as Problem Solver
  • Coach as Conflict Navigator
  • Coach as Collaboration Conductor
  • Agile Coach Failure, Recovery, and Success Modes
  • Your Journey as Agile Coach
There's nothing more to say about this book other than: buy it, study it, and live it!

It may sound pathetic but this book deeply changed the way I think about and practice agile methods. It probably even changed my life.

Thanks, Lyssa, for writing this book!


Agile Principle 3: Frequent Delivery

Let's take a look at the third underlying principle of the agile manifesto:
"Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale."
What does that really mean? What are the implications for our daily business? Let's analyze this principle and see where this gets us.
  • "Deliver" - actually have something finished that is worth being given to the users.
    Values: Courage, Commitment
    Principles: Deliver as fast as possible
    Practices: Incremental Deployment, Small Releases, Sprint Review, Product Demonstration
  • "working software" - the results of our efforts must not be theoretical concepts or prototypes, but a functional software product the user is able to work with effectively
    Values: Focus, Commitment
    Principles: Quality
    Practices: Definition of Done, Acceptance Tests, Sprint Review, Product Demonstration
  • "frequently" - give an usable product more often to the users than just once at the end of the development project
    Values: Focus, Courage
    Principles: Frequent Delivery
    Practices: Incremental Deployment, Small Releases
  • "from a couple of weeks to a couple of months" - keep the iterations short so they are easily manageable and clearly arranged
    Values: Focus
    Principles: Deliver as fast as possible, Iterative
    Practices: Iteration
  • "with a preference to the shorter timescale" - create results early and often so the customer is able to react and decide quickly
    Values: Focus, Simplicity
    Principles: Iterative, Limit Work in Progress, Deliver as fast as possible, Eliminate Waste
    Practices: Incremental Deployment, Small Releases, Sprint Backlog, Iteration
There's not much to summarize here but to say it in two words, the third principle is about Frequent Delivery.



Also read in this blog post series:

Sunday, March 13, 2011

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:

Thursday, March 10, 2011

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:

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:

Wednesday, March 9, 2011

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!


Sunday, March 6, 2011

Book: Fearless Change


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

Authors: Mary Lynn Manns, Linda Rising

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!