Area of Collaboration: Product Owner and Team

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

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

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

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

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

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

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

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

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

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

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

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

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

Conclusions

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

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

Teach Scrum 6 Times!

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

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

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

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

Teach Scrum 6 times ("Repeat Yourself")

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

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

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

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

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

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

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

ScrumBut: Method Picking

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

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

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

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

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

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

"done" = done

"Scrum" = Scrum

"not done" = not done

"not Scrum" = not Scrum

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

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

Pedantic Coders: Warnings are Waste!

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


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


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

Any Warning is Pure Waste!

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


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


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


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


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


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


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


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


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


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


   gcc -ansi -pedantic mysource.c


You should do the same nowadays by applying following rules:

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

Be a pedantic coder and do not allow warnings!

Be lean and remove waste!

Inspect and adapt!

Book: Taiichi Ohno - Toyota Production System

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

Author: Taiichi Ohno

Title: Toyota Production System

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

Rating: recommended

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

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

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

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

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

Lose Customers with Disorganized Workflows

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

"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

I proudly present the German translation of Henrik Kniberg's Scrum Checklist.
Download: http://agilecoach.de/scrum/Scrum-checklist_German_v2016.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

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

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

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

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

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

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

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

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

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

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

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:

1. Development: here we do Scrum at its best - but we are never able to ship our product after any sprint
2. Documentation: all documents will be finished, translated and ready to be shipped
3. System Release Testing: the shippable product will be tested from scratch
4. 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

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

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

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

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?

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

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

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?

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

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:

1. 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.
2. Cluster all information and try to delete as much redundant or outdated messages inside each cluster - this will reduce the number of messages.
3. 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!