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.

Area of Collaboration: Product Owner and Team

Saturday morning 10:00 in Karlsruhe, Germany. Last event of XP-Days 2009: community day with a very well moderated World Café. All input for this posting was created in a 20 minutes timebox with four random conference attendees including myself as host of the table.

The initial question was: "Does a Product Owner need technical skills?"

We came to the conclusion that the break-down process from product vision to detailed, small user stories may require not only business and domain know-how but also some amount of technical understanding. In theory this should not be the case but experience shows that on a very detailed level of user stories it may happen that technical issues need to be discussed: the smaller the story, the more technical it gets.

Theorem: The technical scope of a user story is reciprocal to its business scope.

This led to the follow-up question: "How many business know-how does the Team need?"

For best collaboration it is obviously required to maximize both the Product Owner's technical skills and the Team's business know-how. The more both parties understand of each other's field, the better does the break-down process work to get small user stories.

Following image was drawn on our World Café table to illustrate the theory.

The image shows an ideal situation. Both the Product Owner and the Team have very high skills and know-how so that maximum collaboration is possible. All the way of breaking down the product vision into small user stories can be a collaborative effort with best results.

We now can define four points in space which made up the so called Area of Collaboration:

1. The Product Owner's position with her strong business expertise.
2. The intersection of the Product Owner's level of technical understanding and the break-down transition. This is the point within the break-down process up to which the Product Owner is able to collaborate.
3. The Team's position with its strong technical expertise.
4. The intersection of the Team's level of domain and business know-how and the break-down transition. This is the point within the break-down process from which on the Team is able to collaborate.

Following image illustrates the Area of Collaboration for an ideal situation. In such an ideal world the team can be fully involved right after the first vision of the product is born. This is the wanted condition of understanding and collaboration!

The less know-how either party has of the opposite field of expertise, the smaller is the area of collaboration. In typical project organizations the know-how is restricted to a low or medium level. This leads to split-up efforts: first a lonely Product Owner breaks down her vision into epic stories forming the big picture of the product. Then some collaboration of Product Owner and Team breaks down into smaller stories and this is the part to brief the Team so that it gets a broad understanding of the business values. In the third step the Team must break down into most detailed stories on its own, as the Product Owner does no longer fully understand the technical issues to be discussed. This is the dangerous part which can lead to misunderstanding and wrong product decisions.

But things can be even worse. Image a Product Owner and a Team who both do not have any common know-how and understanding. The Product Owner breaks down her vision into stories without any involvement of the Team. Then the Team takes over and breaks down into detailed stories without any collaboration with the Product Owner. That kind of approach has great chance to get lost.

Conclusions

• The Product Owner needs at least as much technical skills to understand the Team's break-down into detailed user stories.
• The Team's domain and business know-how is even more important than the Product Owner's technical skills! If the Product Owner lacks technical understanding the Team has to compensate with domain know-how.
• 
  A goal for every agile team should be to reach the ideal, maximum area of collaboration.
• As agile coach, mentor, or Scrum Master you should determine the respective know-how and skills of Product Owner and the Team. Handle low values as impediments instantly and increase the area of collaboration.

Final rule: Make the Product Owner and the Team work together from the very start of the project!

Teach Scrum 6 Times!

We had a really nice Open Space session with Alistair Cockburn at the community day of XP Days 2009 in Karlsruhe, Germany. As the concept of Open Space was just too restricted for Alistair, he simply invited to "Whatever U want 2 talk about" what I'd like to define as Open-Open Space.

After several topics we started to talk about energizing teams and how to do this. The group mentioned good examples of situations when a team was able to show energetic motion.

We finally found the solution and the underlying method to trigger a team's energy and make it self-explode into a hyperproductive state! This is a quantum leap in agile team driving!

Take a look at the whiteboard Alistair is pointing at. The third line from the top shows the overwhelming truth:

Teach Scrum 6 times ("Repeat Yourself")

(Note: this post is pure nonsense. Do NOT teach Scrum 6 times to the same team or you will burn in hell.)

It's just that easy: if you're coaching or mentoring a Scrum team then simply teach Scrum 6 times to that team and it will suddenly jump into hyperproduction for sure!

The underlying principle and general method is "repeat yourself". "Repeat yourself" itself is an iterative process that should be timeboxed for maximum effectiveness. With the theory of dialectic constraints it can be proven that "repeat yourself" will lead to pure truth in the receiver's processing unit after infinite repetition.

Fortunately Scrum is such a reduced and simple framework that 6 iterations are enough for any team.

Try this and be surprised of its simplicity! Should you run into any problems with this approach, you should go on, try harder, and inspect and adapt as always.

Remember, if things do not work well it's always human failure due to the first tenet of the agile manifesto: humans and interactions over processes and tools. Humans err, processes and tools don't!

(Note: if you really didn't get it, this post is pure nonsense. Do NOT teach Scrum 6 times to the same team or you will burn in hell.)

ScrumBut: Method Picking

After two conference days I attended several sessions and talked to lots of people. It is amazing how many claim to do Scrum but mention following typical statements:

"How should I change Scrum to fit into my organization?"
"With which part of Scrum should I start?"
"There is no Product Owner in our team, we don't need one."
"We don't do Sprint Planning because we planned all project phases at the beginning and execute that plan in 3 week sprints."
etc.

This is the wrong way! If you pick a few single methods or practices of Scrum the result will not be Scrum.

Or as Jeff Sutherland said: "You may change anything in Scrum but don't call it Scrum!"

One may argue this is just another dogmatic restriction of Scrum. Let's find out why it makes sense to leave Scrum as is.

Think generally about your team's definition of done. Everyone of your team is able to understand what you mean by saying "this story is done." It is just useful to have such a common basis of understanding. Now replace "done" with "scrum" and extrapolate your team to the rest of the world. The definition of Scrum is based on its roles, activities, and artifacts as described in the Scrum Guide or any other serious book on Scrum. Everyone in the world with such knowledge of the Scrum framework will understand what you mean by saying "we're doing Scrum." Take a look:

"done" = done

"Scrum" = Scrum

"not done" = not done

"not Scrum" = not Scrum

"I'm almost finished with this task" simply means "not done".
"We're using only a few things of Scrum" simply means "not Scrum".
It's that easy.

There is no binary black-white scale, of course. In the beginning of your transition to Scrum you will see many things that won't work as scrummy as intended. The important point is not to exclude these things right from the start of your transition. Always start with the full Scrum set even if nothing is working well. Go on, learn, inspect and adapt - with good mentoring and coaching your team will improve soon enough even if you think that is not soon enough.

Pedantic Coders: Warnings are Waste!

Some days ago I had a discussion with a Scrum Master, a Project Manager, and the team leader of a bunch of developers. We talked about an upcoming big project and how to guarantee high quality output right from the start.


At one point in the discussion I thumped the table and raised my voice:
"No, I do not want to see a single warning! If there is a single tiny warning I will declare the result invalid and failed!"


Everybody looked at me wondering about such a hard call. Let me explain why my request is so important:

Any Warning is Pure Waste!

Imagine the typical logging mechanism in your software. As your system grows your logging output grows in parallel. If there are several developers working on that system anyone of them at some point needs some private debug logging. Or maybe some informal output is written to the log files of the running software.


Now imagine the guys working as administrator, service technician, or customer service manager. What do they expect of this software in their specific role? If the customer did not report an issue, they expect an empty log file, nothing else! Every single line of informal or warning message would be pure waste for them.


The system has to write output only if there really was a problem the user could experience. This is a general constraint of software architecture and design your developers have to take care of.


Now we come to the deeper and underlying reason of my request: your compiler must not show a single warning!


"Yes, in theory, but we have old legacy code. And there are always language specific things that just throw a warning."


Don't allow yourself and your team to be that lazy! No, there is not any reason to let your compiler talk to you. Your compiler has to be silent. If it really wants to raise its voice, the message has to be of major importance! Any other gibberish compiler output is pure waste and distracts from important things.


"If you really want this, we could suppress all warnings in the compiler settings."


No, stop, you didn't get it yet! My request is not about hiding important messages, it is about avoiding important messages. Any compiler warning your code produces is an important hint to a possible defect in your code. In my point of view a compiler warning has an even higher priority than a red unit test.


Go and fix your code! Make it beautiful and clean. And let your team define a working agreement or even include in the definition of done as follows: "Code producing any compiler output is not done!"


I don't know why lot of developers do not have the attitude to be a pedantic coder. Maybe modern developers have lost that discipline because they got too used to deal with uncompiled scripting languages. Maybe they simply lack the knowledge of handling any theoretically possible error situation in their code. Back in the old days when I took a system programming course at university, we had to prove our skills by executing this command:


   gcc -ansi -pedantic mysource.c


You should do the same nowadays by applying following rules:

• Never suppress compiler messages
• Analyze every compiler output and take a deep look at your code to avoid that output
• Handle any theoretically possible error situation in your code, or to be more precise:
• Handle any theoretically possible error situation in your code even if you think it will never happen

Be a pedantic coder and do not allow warnings!

Be lean and remove waste!

Inspect and adapt!

Book: Taiichi Ohno - Toyota Production System

Everyone interested in historic basics of Scrum and other agile approaches should read this book.

Author: Taiichi Ohno

Title: Toyota Production System

Taiichi Ohno - Toyota Production System: Beyond Large-Scale Production

Rating: recommended

If you want to understand several basic principles of Scrum and other agile approaches then take a deeper look at Taiichi Ohno's book. He describes the historic development of all those famous Toyota principles one can see adopted in many agile frameworks:

• kanban
• just-in-time
• five why's (real cause)
• production leveling
• visual control (management by sight)
• waste recognition and elimination

All of this was started some 80 years ago by the visionary Toyoda Sakichi and brought to perfection by his successor Toyoda Kiichiro. The book shows some insight how these people thought and managed their organization. It also covers some economical history of the competitive automobile markets of Japan, Europe, and the USA in the first half of the 20th century.

Overall the book does not unveil the deep details how to implement a Toyota-like production system but it gives great background information why and how this system was invented with all its principles and practices.

The appendix "Glossary of Major Terms" is a nice reference of all important concepts.