Registered people can download our presentation. I like to thank all interested participants for their questions.

I prefer questions. So I decided to reformulate the statements into questions:

1. Have you ever used a similar product?
2. Were you ever annoyed by the limits of the existing product (competing or not)?
3. Do you understand more than the high level basics of the needed solution?
4. Can you answer almost every question regarding the product yourself?
5. Is your Product Backlog filled with horizontal and technical items?
6. Does feedback mostly come from stakeholders during Sprint Reviews?
7. Putting your foot down sounds like a feather hitting the floor?
8. Are you able to quickly and convincingly state the Vision of “your” product?
9. Do you call meeting after meeting and then a few more meetings with your development team when Mr. Stakeholder 2 overturned the request of Mr. Stakeholder 1, and then back again?
10. Do you have a budget?

Bonus :
Do you have that twinkle in your eye when you talk about “your” product?

If you are a Product Owner (or Product Manager), how did you answer the questions?

Agile Stories Project Ralph Miarka from Manoj Vadakkan on Vimeo.

Katharina Fritz (Agfa Healthcare) and I will present at the London Scrum Gathering. The title of our presentation is “How to Evolve From Specialized Individuals to a Co-Working Team: An Experience Report”. The following is a part of our submission:

During our Scrum transition we realized that without major changes we might not be able to finish our stories according to their priority and that work could be left undone when specialists drop out. We provide insights on how a group of people changed from specialized individuals to a collaborating team. We present initial worries, like: Does everyone have to know everything? We introduce a coaching system, its values, principles and practices. We show how the team charter played an important role and how the team evolved it. The team felt that motivation, collaboration and quality increased.

It can work to get away from specialists behaviour to team collaboration. We offer one approach that worked for us to overcome specialization towards collaboration. The audience can take away several ideas on how to approach one aspect of a transition to Scrum.

We look forward to meet you in London.

I’m now at the airport in SLC after a week packed with information and new people. First and foremost, I’d like to thank all the organizers for their support. It was fantastic. I hope the final glitch will be resolved soon and all material will be available for download.

Marc Bless and I run a workshop on Fear-Driven Impediments (handouts). The participants were great. They discussed a lot of issues around fear. We had two comments on improving the workshop: have a role play and give us more input on how to deal with fear.

I enjoyed talking to a lot of people and I also attended some sessions. The program was packed and it was difficult to decide where to go to. I liked the following sessions:

• Applying the lean startup model to the Enterprise: Jez Humble
• Making the Entire Organization Agile: Stephen Denning
• Narrative Coaching: Scott Dunn
• Design Thinking: Mary Poppendieck
• Continuous Delivery: Jez Humble
• Tests as a Means of Abstraction: Brian Marick, Michael Feathers
• Lean Startup: How Development Looks Different When You’re Changing the World: Abby Fichtner

Abby Fichtner’s sessions was clearly a highlight as it challenged so many assumptions on product development. In the context of Lean Startups Agile development needs to go a few steps further. For example, while most teams struggle with the “Definition of Done” as something being developed or deployed, for Lean Startups “Done” means that ideas have been validated by customers. Learning is key, not working software.

Mary Poppendieck’s stated in her session that user stories are already design decisions. It is more important to understand the problem a customer wants to solve. Also, Mary clarified that the Product Owner in Scum projects carries multiple roles depending on the complexity of the project. The PO can be a Software Designer, Systems Architect, Business Analyst, and much more. My conclusion was, that a PO needs to work in a team of people.

The keynotes by Barbara Fredrickson on Why Care about Positive Emotions? and by Linda Rising on The Power of an Agile Mindset were both informative and inspiring.

It was also interesting to see and meet many of the signatories of the Agile Manifesto and to hear some of the background stories.

There were many talks, tutorials and workshop on coaching and fewer on the technical side of the Agile adoptions. I’m happy to see that Functional Programming becomes a topic for Agilists as I have a background in Haskell.

I look forward to apply some of the learnings in my work, to keep in touch with some of the participants and to meet them again, either next year at Agile2012, the Scrum Gathering in London October 2011, the XP2012 in Malmö or even at the XP2013 in Vienna.

Die Veranstaltung ist ausgebucht. Ich bin schon sehr neugierig, wie die Verteilung der Teilnehmer ist und welche Fragen den Teilnehmern am meisten am Herzen liegen.

I facilitated a session on the role of agile coaches and how to handle the different roles we often have. The outcome of the session is:

The different roles of an Agile Coach:

• Trainer – say how it works, has experience
• Mentoring – a mix of being a trainer and coach
• Consultant – analyses issues and implements solutions
• Facilitator – supports the team in different meetings
• Coach – does not have to have domain knowledge, is a guide for a thinking process

During the discussion we identified the following ways for an Agile Coach of handling the different roles when working with teams:

• Transparency
• ask the coachee which role (s)he expects
• design alliance: Ask: What do you expect from me? Tell: What you can do… Do this with sponsors, management, teams…
• remember: every case is different
• establish coaching contracts
• Do you want my solution or do you want to find your solution?
• when giving a solutions, then ask “How do you feel about that? What would you do next?”
• Prepare selling – ask what advice would help?
• provide options to choose from
• client/coachee needs to take ownership of solution
• form an attitude of not knowing
• exploring side effects of knowing/not knowing “what would be/happen…?”
• I advice you to try…experiment => safe-fail environment (acceptance of my fail)
• safe-fail environment to be created by teams, coaches…
• coaching-like trainings (i.e. apply coaching practices in training)
• client need to recognize own problems and what his/her acceptance criteria are for a solution
• suppose we are doing something useful here, what difference would we see? What would you do differently afterwards? – ATDC “Acceptance Test Driven Coaching”
• demystify “coaching” – show you can make mistakes and learn

I’m sure there are many more ways to ensure you wear the right hat in the right situation and that the team/coachee knows which hat you are wearing. Also be aware that the coachee doesn’t give you a hat without you knowing. I’d like to thank everyone that participated in this session.

I also attended sessions on “The four evil root causes: Ignorance, Fear, Indolence, Apathy” facilitated by Marc Löffler and “Systemic Structural Constellations” facilitated by Klaus Schenck and Christine Neidhardt. Also I had great talks with participants in-between sessions and butterflied around otherwise.

Marko Seikola (@mseikola) and Kjell Lauren (@klauren69) provide a great summary of most of the session on AgileInc On-The-Road.

In many cases fear is a reason for impediments of an agile team and can cause many effects: resistance to organizational change, procrastination of decisions, inability to surface the real issues in retrospectives. To successfully remove such impediments, the fears of all involved individuals must be understood. If fear is a reason to fail, it should be dealt with as fast as possible.

This workshop arose out of an Open Space session at XP2010 and was further refined at the XP Days Germany 2010.

During my coaching intensive training at the E.S.B.A. – the European Systemic Business Academy - I learned the following appreciation exercise, which I like to call “a shower of appreciation”.

The exercise is done in triads. People need to have a good understanding of each other, best by having worked together. The three participants sit together, two facing each other and the third person sits in a 90 degree angle to the conversation, looking away (something like this: >^<). The two people then talk about this third person for some time (I tried 1min as well as 3min rounds). There are two rules: you are only allowed to say positive things and nothing that was said can be reduced in meaning by anything said afterwards. This is performed three times so that each person sits in the shower seat.

When I participated in this, it felt great. I have run this exercise with a group of 42 people and a heard about an experience that this was used with a team of 12 people. Every time, the participants reported that they felt great, appreciated and this gives a huge boost to motivation and trust.

I hope you can use this exercise too. I would be happy to hear from you.