Monday, August 15, 2011

Agile 2011 Attended Sessions

At this year's Agile 2011 conference in Salt Lake City I attended following sessions.


At the Open Jam I hosted a session to play the "Fearless Journey" game with Linda Rising, Martin Heider, Portia Tung, and two other guys (sorry I forgot your names). The game was created by Deborah Preuss and is based on Linda Rising's book "Fearless Change".

Also at Open Jam I joined the "Lean Flow" card game by Nancy van Schooenderwoert. With a team of 14 people it was a highly interesting experience to see chaotic alpha-male behavior turn into controlled collaboration -- and we could observe that longer planning does not lead to higher performance.

I will write some more details to several of these attended sessions in the next days.

Friday, August 5, 2011

Preparing for Agile 2011

Only 32 hours from now and I will take my plane from Frankfurt to Salt Lake City. Agile 2011 is arriving and I'm really looking forward to it.

There will be two sessions co-hosted by myself.

On Monday morning together with Ralph Miarka I'm going to host a three-hours workshop on Fear-Driven Impediments. Join us to learn and discuss how to recognize fear and how to deal with it in individual, team, and organizational contexts.

The second session will also be a highly interactive gaming session. We're going to play the Last Responsible Moments Game created by Olaf Lewitz and me during the last nine months. Dave Sharrock will co-host the session with me. Join us to play the game and learn some concepts of Lean Procrastination.

See you in two days in Salt Lake City.


Sunday, May 1, 2011

Agile Principle 12: Inspect and Adapt

Let's take a look at the twelfth underlying principle of the agile manifesto:
"At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly."
What does that really mean? What are the implications for our daily business? Let's analyze this principle and see where this gets us.

  • "At regular intervals" - It's not enough to take a look at the project after it is finished. We are not able to change our project development habits afterwards. So even if a worst-case "post mortem analysis" could bring up severe issues and action items for the next project, we can't change what already happened. Therefore we have to take a look at our current behaviour in an iterative way.
    Values: Commitment
    Principles: Iterative
    Practices: Iteration, Sprint, Weekly Cycle
  • "the team reflects on how to become more effective" - Neither the team's manager, nor the Scrum Master, nor a quality manager is in charge to define the development team's workflows and processes. Only the team is able to inspect its own habits and to decide what and how to change. Of course it is not forbidden to get a retrospective facilitator from outside the team--this may help the team members to focus on getting insights rather than holding the meeting.
    Values: Openness, Feedback
    Principles: Reflection, Inspection
    Practices: Sprint Retrospective, Root-Cause Analysis, Seeing Waste, Value Stream Mapping
  • "then tunes and adjusts its behavior accordingly" - The worst reflection is a reflection without any insights and action items. There have to be actionable results for the team so that it is possible to take charge of these actions.
    Values: Commitment
    Principles: Improvement, Eliminate Waste, Amplify Learning, Adaption
    Practices: Sprint Retrospective
To say it in three words, the twelfth principle is about Inspect and Adapt.



Also read in this blog post series:

Wednesday, April 13, 2011

Agile Principle 11: Self-Organization

Let's take a look at the eleventh underlying principle of the agile manifesto:
"The best architectures, requirements, and designs emerge from self-organizing teams."
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 best architectures, requirements, and designs" - We talk about discovering product ideas, as well as finding the challenges they offer and exploring appropriate solutions. These artifacts must not be approached each on its own, but as a whole system belonging together and building the resulting product.
    Values: Simplicity, Focus
    Principles: Diversity
    Practices: Whole Team
  • "emerge" - The artifacts can not be planned up-front but will be discovered and created in an evolutionary way. Don't think too long about the right way to do something. Just do it in an iterative-incremental way and improve that way by reflecting afterwards.
    Values: Simplicity, Feedback, Courage
    Principles: Decide as late as possible, Baby Steps, Adaption
    Practices: Test-Driven Development, Refactoring
  • "from self-organizing teams" - The team does not need a single responsible person "on top" of it to decide who is going to do what, when, and how. If teams have all the necessary roles and skills to create the wanted product, they are able to decide and organize by themselves.
    Values: Communication, Commitment
    Principles: Diversity, Accepted Responsibility, Empower the Team, Humanity, Supportive Culture
    Practices: Whole Team, Osmotic Communication, Servant Leadership
To say it in two words, the eleventh principle is about Self-Organization.




Also read in this blog post series:

Monday, April 11, 2011

Agile Principle 10: Keep it Simple

Let's take a look at the tenth underlying principle of the agile manifesto:
"Simplicity--the art of maximizing the amount of work not done--is essential."
What does that really mean? What are the implications for our daily business? Let's analyze this principle and see where this gets us.
  • "Simplicity" - As already mentioned in the principle, we talk about "the art of maximizing the amount of work not done". Always think about unnecessary tasks in your todo list. Think about requirements no one needs fulfilled to do her job. Think about methods, classes, and your software design in general - you will find various things to be skipped as they do not contribute to your sprint goal or acceptance tests.
    Values: Focus, Simplicity
    Principles: Limit Work in Progress, Decide as late as possible, Self-Similarity, Opportunity, Eliminate Waste
    Practices: Product Backlog, Refactoring, Seeing Waste, Simple Design
  • "is essential" - The essence is what really creates value. All other things are nice-to-haves, gold plating, and pure technical bits and pieces. We need to focus on the essence to reach the goals we are committed to.
    Values: Focus, Courage
    Principles: Eliminate Waste, Decide as late as possible, Economics, Business Value
    Practices: Seeing Waste
See also my blog post on "Focus on the Essence".
To say it in three words, the tenth principle is about Keep it Simple.



Also read in this blog post series:

Tuesday, April 5, 2011

Agile Principle 9: Technical Excellence

Let's take a look at the ninth underlying principle of the agile manifesto:
"Continuous attention to technical excellence and good design enhances agility."
What does that really mean? What are the implications for our daily business? Let's analyze this principle and see where this gets us.
  • "Continuous attention" - Beware of routine in your daily business! Keep your concentration high, stay focused on the things you're working on. This also implies to take a break when you are not able to do so. Do not force yourself to go on if you're distracted and powerless.
    Values: Focus
    Principles: Opportunity, Accepted Responsibility, Reflection
    Practices: Motivation
  • "technical excellence" - Gather the right staff with the right skills to create the product. Cultivate life-long learning to acquire new knowledge and improve your skills.
    Values: Courage, Simplicity, Focus
    Principles: Reflective Improvement, Amplify Learning, Accepted Responsibility, Quality
    Practices: (agile) Testing, Sprint Retrospective, Motivation
  • "good design" - Don't create a product which looks nice outside but is a piece of crap inside. Follow a professional honor and build your software product in a way you could be proud of in every detail.
    Values: Simplicity
    Principles: Improvement, Quality, Baby Steps, Incremental
    Practices: Pair Programming, Test-Driven Development, Refactoring
  • "enhances agility" - If we do not have the right skills and the right attitude, we will get stuck in our agile journey. This is the reason why many teams do not proceed after their initial agile success.
    (An extreme situation of this principle is when people completely refuse the agile values at all. In this case the best way for both these people and the rest of the team is to break up.)
    Values: Openness, Courage
    Principles: Reflective Improvement
    Practices: Sprint Retrospective
To say it in two words, the ninth principle is about Technical Excellence.



Also read in this blog post series:

Saturday, April 2, 2011

Agile Principle 8: Sustainable Pace

Let's take a look at the eighth underlying principle of the agile manifesto:
"Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely."
What does that really mean? What are the implications for our daily business? Let's analyze this principle and see where this gets us.
  • "Agile processes promote sustainable development" - This is not a principle but rather a presumption which has to be proven by applying agile practices. In my point of view this sentence should be removed from the eighth underlying principle or at least be rephrased.
  • "The sponsors, developers, and users" - It's again a cross-functional approach which includes the whole team and all people involved in the product creation chain.
    Values: Communication
    Principles: Collaboration and cooperation between all stakeholders, Diversity
    Practices: Real Customer Involvement, Whole Team
  • "should be able to maintain a constant pace" - The people involved in the product creation chain must neither suffer from excessive labor nor sit around idling and waiting. An important practice especially for the team is collective ownership of both code and responsibility. Let's call it shared commitment.
    Values: Commitment, Focus, Courage
    Principles: Frequent Delivery, Flow, Baby Steps
    Practices: Energized Work (Continuous Pace)
  • "indefinitely" - It's not enough to keep a constant pace at the start of the project or for just a few iterations. Especially at the end of a project all people should keep calm and just "flow" with that constant pace.
    Values: Commitment
    Principles: Humanity, Flow, Limit Work in Progress
    Practices: Motivation, Energized Work (Continuous Pace)
To say it in two words, the eighth principle is about "Sustainable Pace".


Also read in this blog post series: