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.

Book: Henrik Kniberg - Scrum and XP from the Trenches: How We Do Scrum

This is the must-read book for any new agile team member!

Author: Henrik Kniberg
Title: Scrum and XP from the Trenches: How We Do Scrum
http://www.infoq.com/minibooks/scrum-xp-from-the-trenches
Rating: highly recommended!

Are you dealing with new agile team members from time to time? Do you have to train and explain agile to developers, testers, managers? Do you need an easy to understand book on agile practices? Do you need a highly practical book on how to do Scrum and XP?

Get a copy of Henrik Kniberg's outstanding book and just distribute it to your audience.

This book is full of practical information and shows a very pragmatic approach of implementing Scrum and XP practices with an agile team. It covers almost all aspects and is really easy to read and understand.

Although in my opinion there is no best practice how to be agile--this book just shows a great way how it works. I give this book to all my teams and other people new to agile. It's just a great start to learn about agile practices.

Book: How to Read a Book

Everyone reading a large number of articles and books could read this book.

Authors: Mortimer J. Adler, Charles van Doren

Title: How to Read a Book

Rating: interesting

This book was one of many recommended readings from my survey at ACCDE10. The title was promising so I decided to give it a try.

Many aspects of the reading task are covered in both theoretical and practical ways. Four levels of reading are distinguished:

1. elementary reading - nothing more or less than the ability to read and understand written text
2. inspectional reading - the ability to skim and browse quickly through a text
3. analytical reading - the ability to get into the details of a text as well as understanding and criticizing an author's messages
4. syntopical reading - the ability to analyze and put a text into the context of related books on the same topic

The book offers many practical advice on how to read texts of specific kinds like e.g. history, novels, mathematics, and practical books.

I made the experience to have applied some of the practical advices to the book itself. So I skipped some 40% of the actual content of the book - and I don't feel bad about it. I assume such reading behavior was intended by the authors.

On the other hand I'm still puzzled if the book is worth its 400 pages. I'm sure the essence of the book with all its advices and "how to"s would fit on less than 10 pages. The authors probably should have read something like "How to write a book". Nonetheless the book is interesting and to read it may serve well for a reflection on one's own reading approach.

Let the Team play Product Owner

Today I made a nice but rare experience: team A could play Product Owner for team B.

Team A is settled since several iterations and is working on a new product. Team B is only a few days old and is going to build an internal, technical product to emulate the behavior of depending external hardware.

As the developers and testers of team A are going to be the real users of team B's product it was obvious to do a short user story workshop with them. So I gathered everyone of team A around a table in the team room bringing some blank index cards and a marker to start with.

I made several interesting observations during the workshop:

• Some developers show the same behavior as many customers do. They have problems to state what they want to achieve and rather base their statements on the currently planned product features.
• Some developers think very broad so that new themes and stories emerge no one had thought of before. Of course these stories look obvious afterwards but nevertheless would have been forgotten if the real users were not involved.
• Some developers fully understand the agile roles and do not care about the technical implementation. "I don't care how they realize it but I want to have this and that."

We finished that session with a dozen user stories which will result in many more smaller stories after some backlog grooming. I'm going to do the grooming exercise with the team as well so they have the chance to get more and deeper insights into a Product Owner's work and responsibility.

A team and it's Product Owner need mutual understanding and a prospering relationship. In the end it's again--as almost always--a game of Individuals and Interactions.

Recommendation to Scrum Masters and Agile Coaches: let the team play Product Owner every now and then.

CCD Reflection 2: Red Grade finally finished

Four weeks have passed since my last CCD Reflection. So today is day number 49 of wearing the CCD Red Grade wrist band which is quite a lot of time staying with one single CCD grade.

What have I done in the last four weeks?

• Weekly Coding Dojos with my team
• Thought about features and user stories of an online CCD Reflection tool to make daily reflections easier
• Took Industrial Logic's eLearning course on "Composing User Stories"
• Worked on the formal proof that agile practices match very well the software life cycle requirements of specific laws and regulations. But well, this is way too off-topic here.

How do I rate my performance on the principles and practices of the CCD Red Grade?

• DRY - highest rating
• KISS - high, still room to improve
• Beware of Optimization - high, no longer skipping TDD baby steps but from my gut feeling still room to improve
• FCoI - high, I initiated a design session with the team to talk about FCoI. One guy came up with FNoCaI: Favor Nothing over Composition and Inheritance - which sometimes could be the best choice.
• Boy Scout Rule - lowest rating due to 100% work on new, fresh Kata code
• Root Cause Analysis - high, this just belongs to my daily job as team coach and Scrum Master, at least in the last four weeks
• Version Control - high, nearly 100% done
• Simple Refactoring - highest rating, completely done as integral part of doing TDD
• Daily Reflection - medium as I have thought about developing an online CCD Reflection tool

I gave every of these principles and practices a value from 1 point (not done at all) to 5 points (perfectly done), see image.

Red Grade finished for now!

Although I wrote in my last post ...

It would be meaningless to go on as long as I fail to apply the boy-scout-rule, root-cause-analysis, and daily reflexions on a regular basis.

... I'm going to switch to the next Orange Grade by tomorrow morning simply because it's the right time to do so from my point of view. I'm just too excited to experience the next grade. Expect feedback in at least 21 days here again.

CCD Reflection 1: Red Grade finished

Today is day number 21 of wearing the CCD Red Grade wrist band and time to reflect on the last three weeks.

What have I done in the last three weeks?

• Several code katas
• A little pairing with one of our developers to find weird UI problems
• Initiated the first Coding Dojo in our team - we are going to do weekly Dojos now

How do I rate my performance on the principles and practices of the CCD Red Grade?

• DRY - everything was done only once, I give a high rating
• KISS - almost everything was kept simple or--even better--was made simpler
• Beware of Optimization - I can't remember any optimization but want to rate "not perfect" as I think that some shortcuts were made during TDD (two or more baby steps at once). And taking shortcuts is some kind of optimization as well.
• FCoI - my kata and dojo code was too simple, FCoI could not have been applied
• Boy Scout Rule - interesting experience: during a debugging session we walked through code and saw dirty places BUT at that time we were hunting a very specific system behaviour and did not want to interrupt this task by doing boy scout cleaning. Unfortunately we forgot to clean the code afterwards. Learned for next time: take a note of the dirty location and come back later to clean it.
• Root Cause Analysis - did not happen at all in the last three weeks
• Version Control - 50% done but not for some spiking code experiments and all my private katas
• Simple Refactoring - completely done as integral part of doing TDD
• Daily Reflection - thought about it but not very structured

I gave every of these principles and practices a value from 1 point (not done at all) to 5 points (perfectly done), see image.

Red Grade done, finished, or on-going?

The idea of the CCD initiative is to stay with your current grade until you are able to high perform on all aspects of this grade for at least 21 days in a row. My initial plan was to switch to the next Orange Grade after three weeks regardless of my red performance. I wanted to go on and focus on the next principles and practices - and simply keep in mind that I have to improve my red skills. Now I realize that CCD doesn't work this way. I want to prove significant success in the current grade to myself as a trigger to switch to the next grade. It would be meaningless to go on as long as I fail to apply the boy-scout-rule, root-cause-analysis, and daily reflexions on a regular basis.

I try to do daily reflexions from now on to get self-feedback early and improve my grade performance. To be continued...

CCD: The Personal Experiment

Two years ago I left the path of writing code as I had to deal with leadership, management, and organizational things for my teams more and more. That really was no big deal in the beginning but after a while I felt two important reasons to get back into coding again: (1) something was missing regarding my passion for software development: actual coding working software, and (2) I was not able to participate actively in discussions about all those fancy new things: frameworks, languages, and technologies I've never used.

From my theoretical point of view I knew that Uncle Bob's Clean Code was the right approach to go. This was what I wanted to head for not only personally. I also wanted to work with developers who understand and foster their own software craftsmanship in that way: writing clean and SOLID code, following XP practices, and valuing Agile principles.

In November 2009 I started to contribute to the Agile Skills Project for quite a while but unfortunately this project was running into a dead end in the last months. I still hope it will continue somehow but this is another story for another blog post.

At about the same time in November 2009 I attended a session of Stefan Lieser talking about the Clean Code Developer (CCD) initiative at XP-Days 2009, Germany. For in-depth information take a look at

clean-code-developer.de

but note that there is only a German version available.

CCD was exactly what I needed. It it based on four values which always should be focused by developers:

• Evolvability - take care that software is able to be changed easily and at a reasonable low price late in a project or even after years of production.
• Correctness - software is correct if and only if all functional and non-functional requirements are implemented
• Efficiency of Production - short development time, automated tasks, and low bug ratio are necessary to be efficient
• Reflection - learn and improve often and early (on all the individual, the team, and the organizational levels)

These are good values to follow but they are quite too abstract to know how to do it. Ralf Westphal and Stefan Lieser,  founders of the CCD initiative, did a great job with structuring lots of principles and practices and giving easy-to-start guidance to developers.

The whole system is divided into seven colored grades of which five contain specific principles and practices. A CCD developer starts with the first (red) of these five grades and works with the given principles and practices until she has reached a proficient level in this grade for at least three weeks in a row. Then the developer turns to the next grade and continues cycling through all the grades. This grade system provides an easy way to start with specific things and increases a developer's focus.

So I started with the red grade a while ago and will post my experiences on a regular basis here on my blog.

Aqua Doodle as Presentation Tool

Several days ago we bought a new toy for our 15 months old son. It's a drawing toy called "Aqua Doodle" and has a magic canvas: when the water filled pen touches the canvas it becomes visible and gradually disappears again within the next few minutes.

Image: the canvas and the water filled pen.

This is great tool for kids... but only for kids? I think this could also be used for presentations, moderation, creative group work, and unfocused people: there's a few minutes timebox to come to the point and sell your idea, nothing more.

Images: disappearing illustration.

The images were shot with three minutes gaps.

What's the big advantage? People need discipline and focus to reach their conclusion within the given timebox. And it should be an entertaining experience for the audience.

There's only one disadvantage: if you're really good at presenting quickly, the time until things disappear might be too long, so you'd better bring a hair-dryer.

Book: Rachel Davies - Agile Coaching

Everyone supporting agile teams has to read this book!

Authors: Rachel Davies, Liz Sedley

Title: Agile Coaching

Rating: highly recommended!

More and more developers and project managers suddenly have to take over the role of ScrumMaster these days. All our agile frameworks and methodologies are easy to learn and understand so people become facilitators, supporters, and coaches of an agile team--without knowing anything about how to do that effectively. 

This book covers many important aspects of coaching an agile team.

Starting with coaching basics the authors explain what it means to work as an agile coach. Why do I coach? Do I have the right attitude for coaching? What does it mean to work with people? How do I encourage change? How can I help building an agile team? These and related questions get answered in the first part of the book.

Part two describes a lot of coaching tips and practices related to the planning activities of a team. The reader gets answers to questions like: How can I facilitate daily standup and planning meetings? Is it really necessary to coach in daily standup meetings? How to support the team understanding user stories and backlog priorities? How to create the team board and increase visibility?

The third part takes care about quality: How to introduce test-driven development? How to introduce clean code? How to start with pair programming? How to define and get to "done"?

The fourth and last part of the book covers inspection and adaption practices: How do I demo working software increments? How do I facilitate a retrospective meeting? What can I do to get better as a coach?

A very helpful resource in this book are all the short experience reports of Rachel and Liz. Every chapter ends with a typical list of hurdles and contains a checklist so it's easy to do regular self-reflections of specific topics as an agile coach.

This is a really nice reference book on the ScrumMaster's desk to look up how to improve one's own coaching skills.

Agile Coach Camp 2010 Germany - Day 3

The final day of the Agile Coach Camp 2010 in Germany started again at 8:30 am. Mike Sutton provided facilitation so attendees and session hosts could change the marketplace to their needs.

9:00 am. I joined the "Swashbooking" session of Jürgen "Mentos" Hoffmann. It was a fascinating experience. We were six people in this session with six books on a table. The goal of this session was to read 3 books in 30 minutes and to take notes on these books while reading them. After this time we talked about the books and the 3 people who have read the book gave a short report on their lessons learned within the 10 minutes they had with the book. My insight of this session was that the learning process of swashbooking highly relates to the structure of a book and the level of knowledge I already had of a book's topic. This is an experiment which has to be continued!

10:00 am. I joined the "Velocity" session of Deborah Hartmann-Preuß. I got a nice reminder of two important things: (1) the team has to look ahead 1-3 sprints to get a feeling of what probably will come, and (2) backlog grooming is explicitly needed in every sprint to get stories ready for the next sprint.

10:30 am. I moved to Krishan Mathis' session on "Kanban sucks the spirit out of agile". We had consensus that Kanban offers an easy way to de-agilize a self-organizing Scrum team. Kanban tends to create a dangerous mini-waterfall if applied invalid. It's a good approach to extend the Scrum board on the left side with more lanes to define the steps it needs to get a story ready. And maybe on the right side to define necessary steps after a story is done-done. But the simple, team protecting Scrum board must not be changed!

11:00 am. I joined the "How to make a Product Owner" session of Nicole Rauch. We discussed about the responsibilities of a Product Owner and what a Product Backlog has to contain. I gave a short experience report of my last project on how I tried to transform one of three product managers to a committed Product Owner. The fundamental way to get a Product Owner committed is to show the benefits for the Product Owner with Sprint Reviews and the ability to give and get early feedback.

11:30 am. I moved to the session "LEGO Serious Play" of Olaf Lewitz. It's amazing what can be surfaced just by letting adult people play with a set of LEGO bricks. The game is to build models of individual constellations, teams, and organizations. These models can surface many aspects which would not have been surfaced only by talking to people. This needs further inspection from my side... finally I found a reason to buy some new LEGO sets.

12:00 am. Lunch break.

1:00 pm. I made a small walk around the venue to give my wife a phone call. And I never intended to participate in Martin Heider's outdoor session "Walk the Wire". As I walked by, it just looked interesting what they did between those trees so I moved closer. In the end I tried to walk the wire several times with one or two people guiding on my side. It was amazing how many similarities to coaching were discussed. Even if a way (of change) is difficult, it often is enough that a coach (or guide) exists inactive. For me this session was an eye-opener.

2:00 pm. The "Open OpenSpace" session of Sebastian Eichner and me was not needed as all attendees had enough other sessions to go to. Some people in the book's corner were inspecting books which suddenly brought me to the idea to start a spontaneous survey: I wanted to ask all attendees which one book they recommend other people should read. I posted the results of this ACCDE10 Survey: The One Book already.

2:30 pm. I went on to the "Agile Coach Camp 2011 Organizer" session and registered as volunteer.

2:45 pm. Finally I took a look at Heiko Stapf's session on "Marshmallow Challenge". They already had built a tower with spaghettis and a marshmallow on top of it. The tower was 65 cm in height and very stable. The marshmallow challenge is a nice game to demonstrate agile engineering practices.

3:00 pm. Last small break.

3:15 pm. All attendees of the Agile Coach Camp gathered in the biggest room for a final retrospective of the last 2 days. Mike Sutton was our moderator. We had great appreciations and the group felt energized!

4:15 pm. End-of-the-show. All attendees left the venue. We organizers cleaned everything up and took all important artifacts with us for our internal organizer retrospective in a few weeks. The Agile Coach Coach started off with 9 people heading back to Karlsruhe, which we arrived at 7:30 pm. It was just in time for me to drive home and put my little son Henry to bed.

The Agile Coach Camp was a great event. From my perspective, it was exactly the right people at the right time! Thanks to everyone for participating!

ACCDE10 Survey: The One Book

During the last few hours of the Agile Coach Camp 2010 in Germany I started to do a spontaneous survey with one simple question: "Which ONE book should I read?"

People's reactions were quite different. Some mentioned a book within a few seconds, others needed time to think of the most recommendable book. The question even triggered something in a handful of people so they started to brain dump a list of books. Several people hesitated and wanted to know about the context--should it be a technical book or a novel or related to a special topic? I just didn't care. The goal was just to name the one book everybody should read.

Have fun browsing the list of recommended books. Try following experiment if you want: take a look at the list but completely ignore the people who recommended the books. Choose the book which sounds most interesting to you. Now take another look at the list and take the recommending people into account. Which book would you choose now? Why? Think about your decision process and how it is related to coaching, leadership, and rock stars. Self-reflect on this and add your thoughts to the comment of this post if you want.

So here are the survey's results in order of their appearance.

• Paulo Coelho - The Alchemist (recommended by Mike Sutton)
• Guy Kawasaki - The Art of the Start (recommended by Claudius Link)
• Mary and Tom Poppendieck - Leading Lean Software Development (recommended by Sebastian Eichner)
• Julia Cameron - The Artist's Way / Der Weg des Künstlers (recommended by Christine Neidhardt)
• Lobsang Rampa - Third Eye / Das dritte Auge (recommended by Andreas Leidig)
• Alan Alexander Milne - Winnie the Pooh / Pu der Bär (recommended by Juliane "Jule" Conradt)
• Mike Cohn - Agile Estimating and Planning (recommended by Florian Eisenberg)
• John Medina - Brain Rules (recommended by Olaf Lewitz)
• Neal Stephenson - Snow Crash (recommended by Joseph Pelrine, who started to dump at least 5 books within a few seconds, but this one was his first choice)
• Mike Cohn - Succeeding with Agile (recommended by Simon Roberts and Krishan Mathis)
• Rosamund Stone Zander and Benjamin Zander - The Art of Possibility (recommended by Heiko Stapf)
• Linda Rising - Fearless Change (recommended by Kai Beck)
• Gabriel García Márquez - One Hundred Years of Solitude / Hundert Jahre Einsamkeit (recommended by Angelika Drach)
• Michael Ende - The Neverending Story / Die unendliche Geschichte (recommended by Klaus Schenck)
• Nassim Nicholas Taleb - The Black Swan (recommended by Michael Podvinec)
• Seth Godin - Tribes (recommended by William Gill)
• Insa Sparrer und Matthias Varga von Kibed - Ganz im Gegenteil (recommended by Pierluigi Pugliese)
• John le Carré - The Little Drummer Girl / Die Libelle (recommended by Nicole Rauch)
• Jeswald W. Salacuse - The Wise Advisor (recommended by Pierre Neis)
• Rachel Davies - Agile Coaching (recommended by Grazyna Scherer)
• Robert C. Martin - Clean Code (recommended by Stefan "Steff" Huber)
• The Holy Bible / Die Bibel (recommended by Jürgen "Mentos" Hoffmann)
• Kent Beck - Extreme Programming Explained (recommended by Christiane Philipps, who actually put two books on the list with this recommendation--it's up to you to find the other one)
• Harry Mulisch - The Discovery of Heaven / Die Entdeckung des Himmels (recommended by Swen Gonsberg)
• Eliyahu M. Goldratt - The Goal / Das Ziel (recommended by Josef Scherer)
• Dale Carnegie - How To Win Friends And Influence People (recommended by Martin Klose)
• Christopher Alexander - The Timeless Way of Building (recommended by Rachel Davies)
• Harrison Owen - Wave Rider (recommended by Deborah Hartmann-Preuß and Bernhard Findeiss)
• Jon Jenkins and Maureen Jenkins - The 9 Disciplines of a Facilitator (recommended by Sandra Sieroux)
• Dee Hock - One From Many (recommended by Martin Heider)
• Mortimer J. Adler - How to Read a Book (recommended by Ilja Preuß)
• Tom DeMarco - Slack (recommended by John McFadyen)
• Richard Hackman - Leading Teams (recommended by Pawel "Paul" Lipinski)
• Douglas Adams - The Hitchhiker's Guide to the Galaxy / Per Anhalter durch die Galaxis (recommended by Stefan Gfrörer and Sven Tiffe)
• Hermann Hesse - Steppenwolf (recommended by Jens Korte)
• Alistair Cockburn - Crystal Clear (recommended by Maurice le Rutte)
• Stephen R. Covey - The 7 Habits of Highly Effective People (recommended by Yves Hanoulle)

Agile Coach Camp 2010 Germany - Day 2

Starting at 8:30 am Mike Sutton did a great job facilitating the OpenSpace. A lot of interesting sessions were proposed by the attendees.
 
9:30 am. I hosted a session called "Drive-Driven Personality -or- how to handle driveless people". Pierluigi Pugliese joined in with his similar topic about dealing with unmotivated teams. For me this session's result was to underline that people can't be motivated, only their environment can be changed to help them getting motivated again on their own. I will adapt some insights and improve my lightning talk on "Drive-Driven Personality" at the XP2010 conference in Trondheim.
 
10:30 am. Joined a session by Martin Heider "Sharpen your saw - how to improve as an Agile Coach". Basic insight for me was that co-coaching and pair-coaching is helpful to improve.
 
10:00 am. Sneaked into Christine Neidhardt's session on graphical and visualization techniques at flipcharts. Nice ideas how to improve my presentation skills just by drawing good looking visuals.
 
11:30 am. Krishan Mathis, Nicole Rauch and I hosted a joint session composed of "Agile Skills meeting in Ann Arbor", "Agile Skills Project", and "Clean Code Developer". We spend 90 minutes to talk about how it all started in Ann Arbor and how the Agile Skills Project developed until the present day. There is lot of doubt if such a project is needed and if it's heading in the right direction. I focused on the "Quests" of the project as a good starting point for interested people to join, experiment, and contribute. We also took a look at the German "Clean Code Developer" initiative and compared both approaches. What I learned from this discussion is that any approach to do a job is highly related to the passion of the people doing it.
 
1:00 pm. Lunch time with 30 minutes delay. Food was good, nothing more to report on this.
 
1:30 pm. Joined a session by John McFadyen on "Comfort Zones". Many definitions were discussed so we finally knew about people's comfort zone, safety zone, and safe zone. The question came up if we as coaches should be prepared to kick people out of their comfort zone. Fortunetaly we calmed down and said that we're not able to move people. We only can move the environment so that people's comfort or safety zones get moved. The goal is to make people notice that they are about to leave their safe zone by staying in their comfort zone.
 
2:30 pm. Joined a session by Joseph Pelrine on "Psychology of Task Estimation". It is not enough to give the number of hours for a task but also to give the confidence level of that estimate. People are much better to estimate in real intervals: "if you need four hours for this task, do you think you will be finished by lunch?" Estimates are based on the current status of a system and knowledge. Therefore estimates have a best-before-date which is by the end of the current sprint. Re-estimating is necessary in many cases.
 
3:30 pm. Joined a session by Rachel Davies on "Improving Retrospectives". I got some new ideas for retrospective activities to try. My basic insight of this session was to strengthen my belief of the major importance of the inspect-and-adapt principle.
 
4:30 pm. Break. Closing the day and some organizational topics.
 
7:00 pm. Dinner and socializing. After the food we had some nice improvisation games and theatre moderated by Mike Sutton. This was great fun mixed with brain confusing short-term memory games. The day was finished for me after a funny Agile Jeopardy game.
 
This was a great conference day with lots of insights. My strongest belief was affirmed by many sessions, I heard it over and over again: software craftsmenship, being agile, teamwork, promoting change, team building, as well as any other topic related to people working in an organization depend on the passion of these people to do a great job. People have to love what they do to be good and to be able to improve constantly.
 
Tomorrow is the last day with another five sessions... I'm curious to get more insights.

Agile Coach Camp 2010 Germany - Day 1

We organized an Agile Coach Coach bringing 8 people from Karlsruhe to the venue of Agile Coach Camp 2010 in Germany this afternoon. The first come-together started at 6 pm with some finger food. It was an easy way to talk to some people I knew from other conferences and say hello to some new faces.

Parts of our organizing crew gathered at 6:30 pm to form a kind of production line for the conference folders and other things. All papers and flyers had to be bundled and inserted into the folders, as well as all the other give-aways (t-shirts with the ACC logo) had to be prepared for the attendees.

Big Bang was at 8 pm with a great introduction by Deborah and Martin, giving some information on general conference organization. We were some 40 attendees at this time, still 10 missing while on their way to the venue.

Lighning Talks started at 8:30 pm for one hour. After some first hesitation things came into a high energetic flow. Attendees queued up to present their thoughts in the given three minutes. It was a great show to see this happen. Unfortunately I had no possibility to give a short talk as the session stopped at 9:30 pm. There will be more opportunities for lightnings talks tomorrow evening and I'm really looking forward to it. Many interesting topics have been mentioned already so there will be lots of OpenSpace sessions with topics like

• software craftsmenship
• clean code / clean code developer
• how to make people adapt agile methods
• solution focused approaches
• how to deal with the "scrum is everywhere" tendency
• kanban vs. scrum / kanban with scrum
• how to become a better agile coach
• wave making or wave watching? ... gently or toughly creating change?
• retrospection
• and many, many more.

I'm going to propose at least three OpenSpace sessions:

• Drive-Driven Personality - talking about people's intrinsic motivation and how to deal with driveless people
• The Agile Skills Project - defining the skills of our craft
• OpenOpenSpace - whatever you want to talk about

After the lightning talk session we had great discussions with Rachel Davies, Marc Löffler, and John McFadyen. We talked about how to introduce XP practices to teams that never have heard of anything XPish before. My recommendation was quite simple: gain first knowledge (buy trainer or learn by yourself), then get more experience by applying practices like TDD, and always do retrospections to improve.

Another topic was the question how to deal with an old, no longer maintainable legacy system. Throw it away and build it new from scratch? Or replace parts of it one by one? There's no simple answer to this kind of problem as it highly depends (on many things). I won't give a recommendation here though all participants of our discussion tend to prefer the replacing-one-by-one approach.

I'm looking forward to the next two days. This is going to be a great Agile Coach Camp!

Skill-Driven Development

There was a nice discussion yesterday at the meeting of the Scrum User Group Karlsruhe. We talked about dysfunctional Scrum organizations and the new roles of lost middle-managers. At some point a participant said that with really good people one could create really good products regardless of any methodology--either waterfall or agile would work. That lead me to the following statement:

Skill-driven development helps a lot to create working results.
Unfortunately skill-driven teams are not the norm.

So what can you do to improve your own and your team's skills?

• Improve your agile coaching
• Coach your team
• Learn to be patient and disciplined: handle the untrained team
• Surround yourself with people better than you: hire drive-driven personalities (if you are not able to collect the people around you, try to choose an existing team/organization with higher skills than your own)
• Get involved with the Agile Skills Project
• Help the team to improve: facilitate retrospective meetings
• Read at least one book on agile/development topics every other month
• Support or become a Clean Code Developer (German content only)
• Join and get active in a local user group
• Attend conferences: listen to talks, participate in workshops

This list for sure is not complete. There are more ways how to create a skill-driven development environment. If you have any ideas, please leave a comment.