Sunday, July 22, 2012

Correlation of Stories and Story Points

The blog has moved

This blog has been silent since quite a time. The major reason is that I have moved my focus on agilecoach.de my german site.

From now on you will find new posts mainly on agilecoach.de/blog - not only in German but also in English.

I will post references here to new English posts so that you will be able to follow up.

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: