Marc Bless

Agile 2011 Attended Sessions

2011-08-15T16:36:00.000-07:00

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

Workshop: Fear-Driven Impediments
by Ralph Miarka and Marc Bless
Workshop: Introduction to Behavior Driven Development
by Liz Keogh and Katherine Kirk
Special Event: The Agile Manifesto 10th Anniversary Reunion: The Big Park Bench
with 15 of the 17 original authors of the agile manifesto
Keynote: Why Care about Positive Emotions?
by Barbara Fredrickson
Talk: Exploring Enterprise Agile Transformation Strategies
by Mike Cottmeyer and Dennis Stevens
Workshop: Release your team's intelligent energy through five powerful conversations
by Declan Whelan and Bryan Beecham
Tutorial: Scaling Software Agility: Advanced Practices for Large Enterprise
by Dean Leffingwell
Workshop: Lean Procrastination - How to Identify the Last Responsible Moment
by Marc Bless and Dave Sharrock
Tutorial: Agile Education by Object Game - most HISSATSU way to understand it
by Tsuyoshi Ushio
Workshop: Flirting With Your Customers
by Jenni Jepsen

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.

Preparing for Agile 2011

2011-08-05T15:37:00.000-07:00

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.

Agile Principle 12: Inspect and Adapt

2011-05-01T05:24:00.000-07:00

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:

Agile Principle 11: Self-Organization

2011-04-13T15:05:00.000-07:00

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:

Agile Principle 10: Keep it Simple

2011-04-11T14:30:00.000-07:00

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:

Agile Principle 9: Technical Excellence

2011-04-05T03:01:00.000-07:00

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:

Agile Principle 8: Sustainable Pace

2011-04-02T14:51:00.000-07:00

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:

Agile Principle 7: Working Software

2011-03-30T16:07:00.000-07:00

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

To say it in two words, the seventh principle is about Working Software.

Also read in this blog post series:

Agile Principle 6: Face-to-Face Conversation

2011-03-24T03:37:00.000-07:00

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:

Agile Principle 5: Support and Trust

2011-03-21T16:13:00.000-07:00

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:

Agile Principle 4: Cross-Functional Collaboration

2011-03-17T08:08:00.000-07:00

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:

Agile Principle 1: Satisfy the Customer
Agile Principle 2: Embrace Change
Agile Principle 3: Frequent Delivery
Agile Principle 4: Cross-Functional Collaboration
Agile Principle 5: Support and Trust
Agile Principle 6: Face-to-Face Conversation
Agile Principle 7: Working Software
Agile Principle 8: Sustainable Pace
Agile Principle 9: Technical Excellence
Agile Principle 10: Keep it Simple
Agile Principle 11: Self-Organization
Agile Principle 12: Inspect and Adapt

Book: Lyssa Adkins - Coaching Agile Teams

2011-03-15T15:57:00.000-07:00

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

Author: Lyssa Adkins

Title: Coaching Agile Teams

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

2011-03-15T14:00:00.000-07:00

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:

Agile Principle 2: Embrace Change

2011-03-13T15:58:00.000-07:00

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:

Agile Principle 1: Satisfy the Customer

2011-03-10T08:01:00.000-08:00

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

2011-03-10T08:00:00.000-08:00

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:

[German Version of this article: http://agilecoach.de/2011-09-26/prinzipien-hinter-dem-agilen-manifest/]

Book: The Five Dysfunctions of a Team

2011-03-09T13:50:00.000-08:00

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:

Absence of Trust
Fear of Conflict
Lack of Commitment
Avoidance of Accountability
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!

Book: Fearless Change

2011-03-06T15:07:00.000-08:00

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

Authors: Mary Lynn Manns, Linda Rising

Title: Fearless Change

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!

Done-Related Story Estimation

2010-11-29T15:08:00.000-08:00

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

2010-11-13T16:52:00.000-08:00

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":

Do Your Homework Before You Start.
Extend an Invitation.
Come to the Circle.
Welcome Passion, Responsibility, and Authentic Leadership.
Remember the Four Principles.
Observe the Law of Two Feet.
Keep Grief Working.
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

2010-10-25T16:33:00.000-07:00

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

2010-10-23T17:38:00.000-07:00

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:

elementary reading - nothing more or less than the ability to read and understand written text
inspectional reading - the ability to skim and browse quickly through a text
analytical reading - the ability to get into the details of a text as well as understanding and criticizing an author's messages
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

2010-10-15T14:57:00.000-07:00

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

2010-08-15T16:58:00.000-07:00

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

2010-07-12T05:25:00.000-07:00

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

2010-07-11T14:43:00.000-07:00

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

2010-05-27T14:45:00.001-07:00

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

2010-05-12T15:54:00.000-07:00

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

2010-05-02T17:31:00.000-07:00

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

2010-05-02T16:01:00.000-07:00

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

2010-05-01T14:46:00.000-07:00

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

2010-04-30T15:53:00.000-07:00

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

2010-04-08T15:59:00.000-07:00

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

2009-11-30T15:51:00.000-08:00

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:

The Product Owner's position with her strong business expertise.
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.
The Team's position with its strong technical expertise.
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!

2009-11-28T14:57:00.000-08:00

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

2009-11-28T14:14:00.000-08:00

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!

2009-11-25T08:37:00.000-08:00

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

2009-11-23T15:27:00.000-08:00

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.

Lose Customers with Disorganized Workflows

2009-11-15T09:10:00.000-08:00

Last week my wife and me went to the traditional Saint Martin Procession with our son. It was a nice walk with all those gleaming hand laterns of the kids. The walk ended at a school were the local music society had prepared some food and beverages. Ordering and delivery was organized as follows:

At the cash desk customers have to buy vouchers for specific food and beverage
One person works at the cash desk
Left of the cash desk all beverages are handed out
Three persons are in charge of handing out the beverages
Right of the cash desk all food is handed out (french fries, German "Bratwurst", stuff like that)
Four persons are in charge of handing out the food

When we arrived at that location I hurried to the cash desk only to append myself to a long row of approximately 50 people waiting. After 5 minutes there were still 40 people in front of me.

There were several severe problems in the way of organization:

Only one person at the cash desk. Maybe a single resource would have been able to handle the queue of people but unfortunately this person was the slowest imaginable.
No team work. All the resources had been strictly assigned to their specific stations. No one was able or willing to help at another station to deal with overloads.
No one-way routing of customers. After the cash desk first you had to decide to move left or right and cross the row of people in front of the cash desk again to go to the other side.

It really was a mess and I analyzed all these problems within the first minute of waiting. If they only would have organized their work order with a simple kanban, everyone would have been happy with a faster delivery of finished orders to the customers.

We finally decided to abort this experiment after 15 minutes, walked away and got something to drink at home. So my conclusion is: disorganized workflows loses customers.

The Untrained Team

2009-11-10T16:33:00.000-08:00

"Patience. Discipline."

Undead NPC, Undercity, WoW

Successfully getting to Agile requires two important abilities -- patience and discipline:

Patience of the ScrumMaster to let the team self-organize and learn to improve. This may sound contrary to the drive-driven personality a ScrumMaster must have. But it is important for every driver to power up an engine and just let it run on its own from time to time.

Discipline of the team to stay focused at self-organizing and improving. This may sound contrary to the good mood Scrum creates. But discipline is needed both on a personal and team basis. It is barely possible to succeed with test-driven development, pair programming, or continuous integration without discipline.

Now here is the issue: how to deal with missing discipline?

Two answers depending on the underlying root cause of missing discipline: either fire them, or train them!

If discipline is missing simply because team members do not want to be agile you should consider to break up with these guys.

If discipline is missing because team members do not know how to be agile you have to mentor, guide, and train them. It is not enough to give your team an one hour up-front presentation and tell them "you have to write unit tests for everything now because we have it in our definition-of-done." A developer without knowledge and experience how to write good unit tests will get lost. She will try to test the written code afterwards and you will hear statements like "no, I can't write unit tests now because the implementation is not finished yet."

Another fruitless approach is to tell your team "we will do continuous integration now because we are agile." It won't work as long as the team does not know how to integrate continuously on a daily basis. Developers again will get lost mentioning "yes, of course we will integrate but we have to wait for the three stories in this SVN branch to be finished before we can do so."

Do not wait any longer, act now! Your developers will fall back to old, traditional, waterfallish behavior. This will destroy huge parts of the team's success. Do not blame them - they simply do not know better.

Start now to set up training lessons, coaching sessions, and workshops to gain knowledge of all the things anyone of your team must possess. Use experts available in your organization to spread knowledge. Or get professional external help - there are lots of experienced trainers out there to help your team. And the team will be thankful to get something fresh from external people. Just weigh the pros and cons of the money invested in a trainer and the inspirational motivation of the team.

Pure self-organizing advocates will argue that the team by itself has to find all of these issues and how to improve accordingly. Yes, your team should do so. But if you as a ScrumMaster notice slack of improvement it's your turn to brief the team and kick-off some hints.

And always remember:

"Training is useful.
But there is no substitute for experience."

Rosa Klebb, From Russia with Love

Scrum Checklist: German Translation

2009-11-02T17:30:00.000-08:00

I proudly present the German translation of Henrik Kniberg's Scrum Checklist.
Download: http://agilecoach.de/scrum/Scrum-checklist_German.pdf

Have fun with it and give me feedback if there is a typo or anything else is broken.

If you are interested in Henrik's original version, take a look at his Scrum Checklist site.

Book: Mike Cohn - Agile Estimating and Planning

2009-10-30T15:21:00.000-07:00

Everyone getting agile has to read this book!

Author: Mike Cohn

Title: Agile Estimating and Planning

http://bit.ly/1JA1Cr

Rating: highly recommended!

This book is just a must have and a must read! Mike Cohn describes all important aspects and concepts of estimating and planning in an agile approach. Lots of real-world examples show how to apply these concepts.

Note that this book is NOT about traditional estimating and planning for agile projects. It is about *agile estimating and planning* and this is what agile projects need to succeed.

You probably read several Scrum books and know the basics about story points, planning poker, story priorities, sprint planning, burndown charts, and velocity. If you really want to get in-depth details on all these and related topics you have to read this book! It is worth every single word - and Mike knows that "every word counts".

If you already are running agile practices then read this book and inspect your methods. You will find so many things to improve and adapt.

Enough said. Buy it, read it, and keep it on your table for reference!

PS: I'm looking forward to read Mike's new book "Succeeding with Agile". It will be on Amazon's stock on Monday.

Generalize Your Specialized Generalists

2009-10-30T14:29:00.000-07:00

The software developers in a well-known Scrum team have undergone a transition from generalists to specialists in former times. They have been responsible for no specific parts of the software system. Every developer was assigned to the next high priority tasks regardless of knowledge and experience. Combined with classical waterfall project management, solo programming, missing code reviews, and missing unit testing, the resulting quality of the system was extremely low. There was a vast lack of knowledge of the old legacy code the team was working with. To compensate that knowledge all parts of the system were assigned to specific developers - a step that turned them from generalists to specialists.

Instead of moving out of the waterfall into Scrum and introducing pair programming and unit testing it was decided to go the pretended easy way and transforming generalists to specialists. Now single persons were assigned to specific parts of the system but unfortunately there still was a vast lack of knowledge of the old system. The major disadvantage of assigned specialists is the "not my job" syndrome: there always is another guy responsible for the task on my table so work can easily be pushed away. The next disadvantage is the "don't touch my baby" syndrome which instantly blames developers who dared to touch code not in their area of responsibility.

The team resulted in a hypoproductive group of developers, controlled by waterfall processes, solo programming, missing code reviews, missing unit testing, vast lack of knowledge, and individual code ownership: the worst of all worlds finally was born.

Productivity raised instantly after installing a working Scrum with that team. Bug rates dropped rapidly simply by applying the definition of done: code reviews and unit testing now are mandatory. As a next step single team members were asked to spread their knowledge via pair programming. This opened the way to collective code ownership.

The team has to improve a lot more and it will find out all those issues as impediments in the next retrospective meetings. Well, if they don't, the Scrum Master will give some hints by defining appropriate retrospective goals.

In the end, the team will become hyperproductive and will finally re-generelize their specialized generalists.

Drive-Driven Personality

2009-10-27T15:48:00.000-07:00

There was heavy "agile fun" in the last months with all the agilists working close with me. We made lots of wordy jokes like "the goal is the goal", "the way is the way" which became things like "way-driven driving" and nonsense like that. Thinking of all these things all the time made me come to the conclusion of a quite meaningful term I'm going to explain: the Drive-Driven Personality.

"Say what? Drive-driven personality? Yup, right, c'mon, go away and never come back!"

No, really and seriously. It's that easy: Drive-Driven Personality is needed to push changing the world!

Many people just live their lives as is, be it private or professionally. These people may be good, valuable, hard-working thinkers with a quality above the average. Nevertheless these people keep things as they are most of the time. At max they optimize their local environment with smallest influence. But they never will change the world with what they do. They simply do not have the drive to force change.

Drive is not about power - most people do not have vast power to change things with a fingersnip. Usually power is given to people in a local scope only.

Drive is about an inner mental state - a heavy desire to do specific things. It's an inner calling, some kind of mission one has to complete with concentrated passion.

Typical examples of Drive-Driven Personality are writers, painters, artists in general.

Applied to Scrum: everything is quite simple and understandable in scrum. What for do we need Drive-Driven Personality? Jeff Sutherland explains the basic theory of bringing an average waterfall team to be hyperproductive - an initial kind of high-energy is needed to shake and trigger the waterfall team so that it is ready to start the journey. In my opinion this kind of high-energy has to be provided by Drive-Driven Personality. The ScrumMaster has to take care that not only the team but the surrounding organization is ready to start the journey into agility. If you do not possess inner drive to change anything, your attempt to do so will stagnate after a while and will end in keeping a status quo. A Drive-Driven Personality is needed or risk to fail increases.

What for do we need Drive-Driven Personality if our scrum team already moved to a score of 6.4 on the Nokia scale? The team is self-organized, holds retrospectives, and understands how to improve on a regular basis. In this case you need a Drive-Driven ScrumMaster to perform the last hard step bringing the team hyperproductive to a score of 10. There will be impediments to change or remove which are way outside the scope of a scrum team. To change old top-management structures a fearless, Drive-Driven Personality is necessarily needed.

Drive-Driven Personality is what you want for everyone you are working with! Whenever you have to recruit and get people on your team, find out if an applicant is Drive-Driven enough for her job. Avoid working with mediocre skilled people - search a Drive-Driven team and your working paradise is reached.

Book: Mike Cohn - User Stories Applied

2009-10-26T17:05:00.000-07:00

Everyone getting agile has to read this book!

Author: Mike Cohn
Title: User Stories Applied for Agile Software Development
http://bit.ly/POrak

Rating: highly recommended!

During any approach to implement agile procedures in an organisation there is a need to explain how management and engineering of requirements should work. Coming from traditional waterfall projects most people do not understand what those User Story stuff is all about. Usually lot of concerns are mentioned...

"So, User Stories are Use Cases, right? Why don't you just call it Use Case?"

"But we need all requirements at the start of our project. How should that work with User Stories?"

"No, we don't need that. We know what the customers want and we know all features of the product. What for should we waste time with User Stories?"

Mike Cohn is one of the most experienced agilists and board member of the Scrum Alliance. In his book he explains every detail you must know about User Stories. This books makes you understand how to argue against the usual concerns. Mike wrote down his vast experience and makes any aspect of the topic easy to read.

Did you ever wonder how to deal with nonfunctional requirements in Scrum? Read this book and find out.

Did you ever ask who would be the best product owner writing your stories? Read this book.

Have you read this book and still have issues bothering you about User Stories? Well, you either got lost in something else than being agile or you probably may be on to something really new.

Guerilla Scrum: How to force organisational change

2009-10-22T15:41:00.000-07:00

Situation

Many organizations do not dare to change themselves although everyone knows that things do not work well. Usually real working employees have a good feeling that things are going wrong. Unfortunately they do not have the power to trigger change but expect middle management to do so. Usually top management expects everyone to do the best job and will ask questions to middle management if things go wrong. Therefor middle management is sandwiched with expectations - this is a hard job to handle and needs explicit skills.

People tend to keep an organisational status quo for several reasons:

Why change anything? Never change a running system.
A change would have impact on many parts of the organisation, we just can't do this.
We do not have time for changes.
We do not have budget for changes.
We can't change anything due to laws and external regulations.
We already tried to change things but it didn't work.
My boss forbids change.
I do not change anything so that I am not responsible for any fault.

Analysing any single reason not to change an organisation leads to the basic cause: fear-driven management avoids organisational change.

Solution

Four phases as follows are needed to overcome fear-driven management and force organisational change.

1. Guerilla Scrum

Guerilla Scrum is about just starting to change things in your own local scope of influence. Simply start your next project by applying scrum. Even if you have to deal with scrumbuts like missing product owners or an unprepared team you should start scrumming. Try to live scrum with all the few details it prescribes. Just do it and the results will prove your right decision.

If you can't setup a scrum team or if you are bound to a running project, then try to apply as many of the following:

Inspect and Adapt: setup timeboxes of several weeks in your project and bring together all team members on a regular basis to do retrospectives of these timeboxes. Do this to find obstacles and impediments and remove them as soon as possible.
Direct Contact: bring people together. Make people communicate with each other. In many projects people talk to the project manager only instead of talking with the co-worker in the neighbour room. Force them to work in direct contact.
Show Progress: use the mentioned timeboxes and give a project presentation at the end of such a box. Make the team responsible to demonstrate what they have achieved. Try to invite your product manager or whoever is the major project stakeholder from the business point of view. Convincing this business guy is important for the next point.
On-site Customer: bring in the convinced product manager to talk to the team. Use this direct contact to clear requirements and get a better understanding of each other.

You will see huge overall improvements after repeating these things two or three times.

2. Push into Organisation

Visit the barber, jump into your best suit and get ready for marketing: make your improvements visible to other parts of the organisation.

Do not promise the silver bullet! Do not promise infinite ROI and do not promise vast improvements by presenting the theory of a new method!

Simply present the real, measurable improvements of your guerilla scrum. Just mention a few words about "agility" and "scrum", just give an indication of doing things differently than before.

You should explain some details of your scrum to the next neighboured managers: show them the daily micromanagement, the tracking of all things, the planning, everything - and let them be both surprised and confused. They will need time to think about what they saw.

3. Expect Growing Interest

The word will spread through your organisation: the product manager will talk to her colleages, your manager will mention improvements of his department with a new method. Other people will take notice of you and your team.

Members and managers of other departments probably will contact you to learn more. Use this chance to give a presentation on agile methods. Set a date for a workshop on timeboxing, agile estimating, or any other interesting agile topic.

Don't forget: always include step 2. and continuosly present your real improvements!

Persuade as many stakeholders as possible.

4. Use Multiplicators

Time will come when someone will have entered the agile train. Maybe another project manager read a book, joined a conference, or actively went into agile in any other way. There will be people getting the big picture and have their eyes opened.

Use these people, they are your allies! Let them spread the word for you. Support them and get supported in return.

Ideally some of these people are from top management - these are your wanted multiplicators! Try to sandwich your middle management organisation with agilists: persuated managers and successful, improving project teams.

When enough people are on your side, being agile becomes common sense and will not be questioned any longer.

Conclusion

Every organization is able to achieve major improvements. Overcome fear-driven management by proving results of guerilla scrum. Do marketing and present your real improvements and results. Persuade as many people as you can, so that being agile becomes common sense.

The most import agile principle of "Inspect and Adapt" will help your organisation to embrace change - so finally you reached your goal.

Personal Taskboard: Evolution to Mobile

2009-10-16T15:40:00.000-07:00

The major disadvantage of a wall-based personal taskboard is its pure static character. You can't take it with you for travelling or for working on it at home.

Here's the solution: the mobile personal taskboard.

Side note: this version of the personal taskboard is not used by myself but I like the idea a lot. For me it works to move the 2 most important task from my wall-based board into my paper book. So my paper book is some kind of additional optional external kanban lane.

Don't forget: always inspect and adapt! This topic will go on for sure...

Personal Taskboard: Evolution to Priorities

2009-10-16T15:21:00.000-07:00

Just a small update on my personal task board: as the open tasks got more and more it was hard to filter and select the next task to pull into WIP (work in progress).

Solution: tasks are now sorted by urgency from left to right and by importance from bottom to top. The most upper right task is ready-ready to jump into WIP.

To be continued...

Personal Taskboard: Evolution to Kanban

2009-09-26T16:44:00.000-07:00

A few weeks ago I setup a personal taskboard at the wall next to my desk. It had three lanes like a Scrum task board: "open", "in progress", and "done". After one day there were lots of things in progress and two tasks were done already:

The major problem was the number of tasks in progress. There were just too many things ongoing so that control could easily get lost. Fortunately things were sorted out a few days later. Lots of things done and few things in progress:

After a while I recognized the repeating problem of too many thing in progress. After a short personal retrospective I decided to improve my focus on the "in progress" lane. It seemed obvious to limit the number of things to work on in parallel. I splitted the "in progress" lane in two parts:
a) an "on hold / wait" part for all the things that have been started but need external help
b) a "working on" part with focus on all the things in progress. This part now is a Kanban box with a limit of two tasks.

The positive effects of this change appeared instantly: things got their focus on the essence! Tasks were done in a much more sustaining pace than before.

I am curious about the next improvements of my personal task board. Let's see what my next retrospectives will expose.

Sprint Meetings in Distributed Scrum

2009-09-23T15:14:00.000-07:00

My current scrum team is distributed in three locations:

Location A: developers only
Location B: testers and the product owner
Location C: testers, developers, and the scrum master

In this situation we have to deal with some lack of communication. Location A is in a different time zone, 5 hours away, which makes communication even more complicated. We can't use a simple task board everyone can easily work with on a daily basis. Electronic documents are used to substitute most sprint artifacts.

How do we succeed with all those sprint meetings we have to perform? Daily scrums, sprint review, product demonstration, sprint retrospective, sprint planning. These are quite hard to do with emails and phone calls only. In fact it simply is not possible to let the team improve by these means. (And please do not call it Scrum if you have to work that way.)

We use a video conferencing system to connect all three locations in all the meetings necessary. The team sits together in virtually one room, can see the other team members, and has direct communication with everyone. This is just great and after a few seconds you simply forget that the other people are far away.

To simulate the feeling of everyone standing in front of a task board, we use a remote desktop system with one master and two client connections. That way all participants are able to move the mouse, enter some information, and instantly see what other people do with the documents.

Today we had a really good distributed product demonstration for our product owner. The software system was hosted at location C, was presented by a developer of location A for our product owner sitting in location B. The product owner was impressed of the early feedback. As our testers already have done their job, the software was in a really good quality. So the product owner said something about "wonderfull" several times, which made the team proud of what they had achieved in the last two weeks. The product owner also gave suggestions and hints (in traditional tongue: "detailled requirements") so that the developers understood way more than a written requirement specification document ever could provide. I just love these short feedback cycles, the increasing team motivation, and the positive outcomes of Scrum!

Hint of the day: get video conferencing systems and remote desktop systems if you have to deal with distributed scrum meetings!

Plan-Driven Testing fails with Agile Developers

2009-09-18T16:36:00.000-07:00

There were two situations today in the office that opened my eyes. I finally understand why it is so hard to form a team of plan-driven testers and agile developers.

Our daily scrum meeting went fine today. Our iteration progress is back in parallel with the ideal burndown after a 2 days upward drift.

After the meeting a tester came to me and said, "it's really annoying to notice in the daily scrum that some stories are ready for testing. Why don't the developers write me an email?"
SM: "What's your problem? You just got the information a few minutes ago in the meeting. What could we improve to help you?"
Tester: "I don't know. I just don't like to wait for answers. The developers do not react on my postings in the bug tracking system. Therefore the testing crew is in waiting mode."
SM: "Have you asked the developers?"
Tester: "What do you mean?"
SM: "Whom did you give a phone call? Did you talk to a developer directly?"
Tester: "No, they know that they have to write me an email."
SM: "OK, obviously we have to improve something here."

I stopped the discussion. And I am very curious if this issue will be mentioned by the tester in the next retrospective.

Later in the afternoon I went to the test lab. I met another tester there and asked, "Have you seen all the fixed bugs in the bug tracking system? There's lots of stuff ready for testing."
Tester: "Oh, no I didn't take a look."
SM: "You could start to look right now."
Tester: "'Err, no first I need the bug list."
SM: "What do you mean? Just take a look at the bug tracking system to get that list."
Tester: "No, one of the other testers is responsible to create an Excel sheet with the bug list. Then we can coordinate who is testing which bug when and how long."
SM: "Yeah, OK, I understand."

I stopped again. And this time I was sure that this issue will be mentioned in the next retrospective: testing has to be agilized much more!

Imagine to have a detailed iteration task board which gets updated every morning in the daily scrum by the whole team. Everyone knows, what's going on, and everyone is up-to-date. But simply having actual knowledge of status is not enough for the testers - they want to be informed explicitely by email. Then one of the testers takes a look at the stories "ready for testing" and maybe takes a look at the bug tracking system. The bug tracking system is already one redundant system too much but for the testers even this is not enough. One tester copies all important information out of this system into a new list. For what sake? Simply to fall back to old habits and have a plannable list of things one can assign people to and give each an effort estimation.

If the next retrospective meeting would not be within the next 3 days, I for sure had raised my voice today. But I'm sure the team will see and mention these issues on its own. The next retrospective will be exciting!

Transition of the Definition of Done in Regulated Environments

2009-09-15T09:19:00.000-07:00

Projects in regulated environments have to follow strict guidelines and rules. Laws, normative regulations, product risk analysis, and detailled development processes are defined and controlled by Quality Management departments. Besides of that you have to deal with external groups like editorial staff for documentation.

From a User Story's point of view all of the following is necessary for a proper Definition of Done:

Done: internal Scrum DoD (specified, implemented, unit tested, reviewed, UI tested, integrated, and so on)
Done-Done: external Documentation DoD (readme edited, online help edited, user manual edited, translated, layouted, printed)
Done-Done-Done: external System Release Testing DoD (regression tested, all stories tested, documentation tested, system interoperability tested, etc.)
Done-Done-Done-Done: external Quality Management DoD (risks analyzed, overall risks reviewed, remedial actions defined, project documented, and much more)

One could argue to change the organization to move the external departments into the agile team. Not only laws and regulations make this impossible but there are simple economic and time issues as well:

Documentation can't be translated on a User Story basis every time something changes. This would get too expensive and it is much easier for an external translator if she has the final document ready at hand. Nevertheless a translation into a dozen languages may take up to 4 weeks.
System Release Testing can't be started until everything is finished and shippable. Unfortunately some unexpected behavior on a User Story basis may be reported which need instant action (code adaptation, re-documentation, re-review, re-testing).
Quality Management departments traditionally follow a very waterfalling approach. After every other thing has beed finished they start to look at a project, do some reviews, read project documentation, and - worst of all - start asking questions and suggesting changes here and there. These changes may have impact on single User Stories.

So how do we deal with all these "Dones"?

We have to de-agile our project and split it into phases:

Development: here we do Scrum at its best - but we are never able to ship our product after any sprint
Documentation: all documents will be finished, translated and ready to be shipped
System Release Testing: the shippable product will be tested from scratch
Quality Management: all documentation and project results will be reviewed and the final "Go" is expected

Next, we move as many DoD parts as possible from the later phases to development:

"documentation drafted" from Documentation to Development: sketch the documentation changes for every single User Story. I recommend to find a semi-team member in the documentation department and deliver all drafts after each sprint to her for a first review.
"risk analyzed" from Quality Management to Development: think about product risks of every single User Story. Again I recommend to closely work with a QM guy after each sprint.
In general "any small thing finished" from later phases to Development

With this approach we are able to strengthen the DoD we are tracking in our Daily Scrums. We move as many tasks as possible to the early development phase and thus we handle risky things right from the start.

The big advantage of more early "Dones" is the expansion of the agile, iterative development phase. Agile progress tracking can unfold its power with much more tasks being finished during development. As a result all later phases have less risk of failure.

Explaining Agile Projects

2009-09-14T10:00:00.000-07:00

Here are some impressions of expressionistic drawings while I explained how we do Agile Projects to some people.

The complete picture

This drawing covers a lot of aspects. Try to find as many as possible:

Definition of Done
Iterative cycle of system qualification (testing) and bug fixing (development)
The need to release multiple software products due to shared components
V-Model (with a substitution of level "P"roduct with "F"eature)
50% buffers
Parkinson's Law
Feature Branching Strategy

Single Point of Communication

In organizations without fully implemented Scrum teams there always are victims in the center of all other groups. The poor guys in the middle (old fashioned project managers) are flooded with questions from the developers and testers (left) and instantly have to pull answers from the business guys (right). As a result, they constantly jump from left to right and vice versa.

Agile Process Refinement

This image shows an approach to implement mixed agile processes to an organization:

Discuss about features on an epic level with top management. Call this FDD for these guys and show them the FDD process - they do not need more details.
Refine these epic features and create detail feature specifications with the lower management and business people. I call this F++ just for fun. They want to discuss implementation details and user interfaces - in fact, this is where user stories are created.
Implement Scrum (or better: ScrumBut) for the development and testing team, use task boards, burndowns, dailies, and retrospectives.
Major goal in this drawing: pull the business guys into the Scrum team and convert them into real product owners.

Book: Esther Derby, Diana Larsen - Agile Retrospectives

2009-09-13T15:40:00.000-07:00

Everyone working with teams has to read this book!

Authors: Esther Derby, Diana Larsen
Title: Agile Retrospectives - Making Good Teams Great
http://bit.ly/cvoaH

Rating: highly recommended!

Esther Derby and Diana Larsen describe 38 activities for all stages of a retrospective meeting. These activities provide ways to improve the team work and to get better results of the retrospective. There are no rules when to choose which activity but you get a nice set of activities to select from. Goal: avoid boring routine by varying activities.

Retrospectives are one of the major keys to successful agile teams! This book helps to improve teams and so to improve the agile approach of a team.

Be aware of technical teams being focussed on hard skills rather than soft skills - this may be a problem to solve before introducing an activity working with feelings of team members and the expression of feelings. Tech staff often judges such things as psycho stuff. So what is the great thing about retrospectives? Even the 'psycho stuff' situations will improve as the team does.

Conclusion: read this book and try to vary your very next retrospective meeting.

ScrumBut: The "Agile" Buzzwords

2009-09-04T13:58:00.000-07:00

A normal day in the office. I tried to get more details for some stories from a product owner. Half an hour before lunch time a co-worker entered the room, we did some small talk and made an appointment to go for a walk'n'talk later.

Suddenly he wondered about the book on my desk: "Agile Retrospectives" by Esther Derby and Diana Larsen (http://bit.ly/cvoaH). He took a look at the back and read "Project retrospectives help your teams examine what went right--and what went wrong--on a project."

He instantly asked "Why is any new book called 'agile'? There are enough 'agile' books on the market. Is there any need for a book on retrospectives? Doing retrospectives is a common project management method, so what for do we need that 'agile' buzzword for retrospectives?"

In my point of view we need the 'agile' buzzword for everything we do! Why? Simply to intensify our agile project marketing. There are lots of stakeholders who still do not understand what it means being agile. We have to throw all that agile mumbo-jumbo around so that they get the chance to ask what we are talking about.

"We have to get higher quality, faster development, more features realized, so we will use a bunch of agile best practices. But whatever we are going to do, the most important thing is to control everything in a closed-meshed manner. And we need key performance figures."

The biggest ScrumBut in this quote is "use a bunch of agile best practices": do some planning poker here, take the name 'feature' from FDD, talk about Critical Chain project management, and write a 40 pages definition of those 'best practices'. Will such an approach have any chance for success? I doubt it.

Lets take a look at the other points of the quote. You want to control everything? Of course, you can, it's no problem at all: daily scrums, iteration reviews, and product demonstrations will assure controlling. You want figures? Just collect our agile metrics and you have them: velocity, burndowns, number of stories done, and so on. But what is the goal of controlling and collecting figures? We want to improve our team, our methods, our agility. The best way to improve is by implementing retrospectives the agile way (just read the book on my desk if you want to know more http://bit.ly/cvoaH).

Once a manager said: "Could you please stop talking about 'timeboxing'! This concept is so old and it's common sense to keep track of my project at least once a week. I don't want to hear that term 'timeboxing' any longer!"

"Timeboxing is not about frequent progress tracking, it's about fixed lengths of meetings and iterations. You even can timebox our release if we have to be date-driven. If story priorities change at the end of the timebox, some lower valued stories will just be moved into the next release", I replied.

"What do you mean 'moved into the next release'? You gave the promise to implement this set of features for this release at the planned date."

"You know reality. Project scopes change constantly, things may be decided to be more important this month and less important next month. Additional features are moved into a project and some other features get too large to be implemented at the proposed date. If your goal is to release twice a year, we have to timebox our releases to 6 months. This will guarantee a sustainable pace for the releases. If additional requirements get into a release, some other stories have to move to a later release. Otherwise we will not be able to guarantee a new release of the product every 6 months. Even worse: the succeeding release will be delayed before it ever started."

Somehow my last sentences opened his eyes at least a little. But that ScrumBut discussion has not been finished yet. I will report the results of our next discussions, of course.

The team leader of a group of developers once said: "we will not do iterations. That would be too many changes for the team, let's just do this feature driven-development now. If this works, maybe we can do some more."

This one is a heavy ScrumBut: do half of some agile method. Without iterations every other advantage of being agile gets lost completely. You would win nothing if you had to take a look at the project's results half a year later for the first time. Iterative planning and iterative retrospectives are so important that they must not be skipped by any means!

If you want to know more about ScrumButs, take a look at Ken Schwaber's site http://www.controlchaos.com/. Some interesting thoughts about ScrumButs can be found in http://www.noop.nl/2009/09/scrumbuts-are-the-best-part-of-scrum.html.

Daily Tracking

2009-09-01T06:22:00.000-07:00

A big advantage of the perfect world of strong, deterministic, complete, overwhelming and unchangable project scopes is that you can track your progress on a micro percent basis, two post commas included. All glory to the waters falling from beginning to end!

Suddenly everything is different in the real world where we live such wondrous things like Scrum.

I was asked by a senior project reviewer how I do track the progress of my projects. He was wondering about missing work breakdown structures with assigned resources and working hour efforts - none of that was in my pro forma MS Project plan.

I told him about story point estimated, feature story based release planning and burndowns. "OK, but..."

I told him about iteration planning, task breakdowns of stories, task estimates in hours, daily scrums, daily progress, daily tracking, daily burndowns, daily knowing-what-happened-what-will-happen-and-what-the-issues-are. His eyes got wide and he said "wow, I'm really impressed of such direct, short-term feedback cycles. Let's give it a try. I'm curious about the results of the next weeks."

Satisfied we left the meeting and yet another time I thought how easily critical people get persuated simply by explaining the details of what we're doing on a daily basis.

Praise the Daily Day!

Why does Scrum feel so good?

2009-08-31T05:41:00.000-07:00

Everyone likes the feeling of having success. And nothing is more depressing than a consistently growing bad feeling that something is not right or heading in the wrong direction. Typical example of such bad feelings: hearing or reading for the 5th time "it's 90% finished".

So what is the great mood enlarger in agile, iterative methods like Scrum? Simply its transparent progress of small and visible results!

And this is not only for product owners to quickly see what they expected but also for the development team to quickly get positive feedback and as well for scrum masters to quickly see that their mentorship is fruitful.

Quick satisfaction with your own work is a success key of being agile!

Daily Video Scrum

2009-08-28T13:30:00.000-07:00

Implementing agile methods like Scrum relies on broad communication. With a distributed team there's a need for much more heavy communication. Unfortunately the distributedness of a team complicates easy communication. In most cases the common ways to send and receive information is

one-to-one/many by email: the most anonymous distributed communication from one person to a group of people. Advantage: ability to spread complete and detailed information. Disadvantage: uncertainty of the message being read and understood.
one-to-one by phone: the most direct distributed communication between two persons. Advantage: direct feedback is possible. Disadvantage: not useful for team communication.
one-to-many by phone (phone conference): mostly uni-directional communication from one person to a group of people. Advantage: team communication is limited but possible. Disadvantage: direct feedback is hidden.
many-to-many by meeting: ideal way of team communication. Advantage: face-to-face in one room, ability to use boards, cards, beamers. Disadvantage: unable to participate for distributed team members

Best solution for distributed teams: use a video conferencing system with all team members in front of the cameras. That way you virtually enlarge the meeting room and can use most of the advantages of a usual meeting. By adding a beamer to each side of the system and setting up a remote desktop infrastructure, all other tools can be simulated as well.
I initiated a Daily Video Scrum for my distributed development team. Of course a little more preparation is needed to start the video system and, the beamer. But it's worth the effort - try it and you will see the benefits!

Planning Joker

2009-08-28T07:29:00.000-07:00

In one of our last planning poker sessions the team was asked to give estimates for a story. Surprisingly all of the team members chose either a 100, an infinite card, or a combination of cards to express the weirdness of the story. After some explanations it came clear that we were missing an important card in our deck: the Planning Joker!

What's the meaning of the Planning Joker? - "I will not estimate this story as it is completely crazy."

If a story has a vast lack of meaning and does not contain any useful information then the Planning Joker is the right choice. An example for such a story would be "as a user I want to see all information" - whatever this means, it is not estimatable and needs clarification by the product owner.

Besides of a new meaningful expression in your poker sessions, the Planning Joker adds some healthy amount of fun to these sessions. Try to use it and see if it works for you - feedback is highly appreciated.

Thanks to Anton Morozov for the nice drawing of the Planning Joker.

Iteration planning: hours of tasks or number of tasks?

2009-08-27T13:55:00.000-07:00

I recently had a discussion with another Scrum Master. He participated as a chicken in my sprint planning meeting.

When the team had finished the breakdown of user stories into tasks, I wanted to get estimates in working hours for every single tasks of the sprint. The other Scrum Master wondered why I insisted on getting those hours. He would have just worked with the number of tasks in the sprint rather than put more effort in getting those estimates. In his eyes that would be sufficient to track progress and draw an iteration burndown.

In my point of view it is not enough to have the number of tasks solely due to following reasons:

task sizes are unknown and not comparable
it is difficult for the team to choose open tasks for the next day without knowing an estimated effort in hours
it is impossible for the team to honestly commit to a story on the basis of story points (or ideal days) only
the iteration burndown will get more realistic and shows "real work done"

Finally an iteration contains a more detailed scope than a release so more detailed estimating and planning has to be applied.
Bibliographic recommendation on this topic: Mike Cohn - Agile Estimating and Planning (http://www.amazon.com/Agile-Estimating-Planning-Mike-Cohn/dp/0131479415)

Information Overload: Focus on the essence

2009-08-22T15:31:00.000-07:00

Why am I starting to write the first post of my own blog? What do I expect? What do readers expect from my blog? And who has answers to all that questions?

I just asked myself how many time one has to spend to be updated with all news from Facebook friends, Twitter followings, Xing and linkedin contacts, and all other interesting information sources. Summed up I

have 315 direct social networking contacts,
am subscribed to 30 interest groups,
am member of 4 organizations, associations, or institutes, and
have been in email contact with more than 1.000 people in the last 15 years.

Let's assume an activity rate of 5% for my email contacts and 10% for my social networking contacts. This will lead to some 80 active contacts - with one message a day resulting in 80 messages daily.
Let's further assume that the interest groups and other organizations publish 5 messages as daily average. This will lead to some 170 messages daily.
So I should deal with 250 messages every single day - that sounds quite exciting! This is probably even more exciting when returning from a 10 days vacation...
To make a long story short: it's just not possible to handle such vast amounts of information!
What's the solution of all of this? Focus on the essence in three steps:

Read only the subject of an email, the abstract of a paper, the labels of a blog. Dismiss highly uninteresting topics instantly - do not keep them to postpone your time, just get rid of unimportant things.
Cluster all information and try to delete as much redundant or outdated messages inside each cluster - this will reduce the number of messages.
Dare to delete everything which needs no urgent attention - people will get back to you if it's really necessary.

-----

Focus on the essence:take care of the interesting, the new, and the urgent - simply ignore all other information.

-----

Try it and be agile!