Agile

Last weekend I had a great time at the Agile Coach Camp Germany 2011 in Rückersbach. I met so many great people, all interested in improving the way we build software. The ACCDE is an unconference which basically means that the program is created by the participants at the conference.

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.

My colleague Marc Bless and I will be leading a workshop at Agile2011 named “Fear Driven Impediments”.

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.

In my opinion, one of the most influencing factors in motivating people is to show gratitude. Unfortunately, I often see that this is hardly applied. Often we hear what we could do better instead of an honest “thank you” for what has been achieved.

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.

Today I read the post by Mark Levison on story slicing. It made me think of an issue I have been carrying around for a while – how to explain to ProductOwners what it means to slice features in a meaningful way. The standard answer is that each slice needs to provide business value. But what is that? I work mostly in large companies that have long release cycles (three month to one year). Sometimes the customer wishes so, sometimes to have meaningful releases it takes time to develop and test the software thoroughly. Business value is in features that are bigger than one sprint.

So, what can we gain in one sprint? Joseph Pelrine answers this in his ScrumMaster classes: information. So the V in INVEST, i.e. the value of a user story, is to provide us with information and this information can then be used to inspect and adapt our efforts towards reaching the desired business value.

We work on two levels of learning. On the one hand, we gain meaningful information, when the customer can inspect the result and tell development whether it is what (s)he intended. On the other hand, we want to gain information on our process, tools, and interaction. Thus we need to fully integrate the solution, test and document it. (Hm, maybe the “I” can also stand for “integrateable”?)

I hope this to be a helpful insight as it might offer Product Owners a new view on how to slice features into user stories that are fit for one sprint.

Marc Bless and I initiated a session on “Overcoming fear at the workplace” during the Open Space at XP2010. I’d like to thank everyone for participating and contributing to make it such a fun and inspiring moment of the conference.

Last week I conducted a two day in-house agile/Scrum training in Slovakia.

I enjoyed it very much apart from the few people that clearly didn’t want to be there and thus didn’t make an effort to contribute. One agile principle is to build your project around motivated individuals and trust them to get the job done. It is frustrating to realize that the project might fail because of the selection of people.

Contrary there was also a rather motivated group present. They started their agile project three weeks ago and had lots of good and detailed questions.

I also learnt a lot again. I need to extend the time for Q&A from 30 to 60 minutes although I answered questions along the way anyway. I think I will shorted the “User Stories” part. Frankly, I think it is not so important to have user stories if the requirements are given in another way. It is important to know the who needs what and why though and to have clear acceptance criteria. This can all be mentioned when talking about the product backlog anyway. I also need to improve the introductions to the Scrum form Hell and The Agile Hour exercise.