Passionate about your development

In Kostenfaktor Angst setzen sich die Autoren Winfried Panse und Wolfgang Stegmann mit dem Thema Angst im betrieblichen Umfeld auseinander. Mir gefällt gleich am Anfang, dass sie erst einmal positive Aspekte der Angst hervorheben. Viele unserer Errungenschaften sind aus Angst entstanden. Zum Beispiel, wurde der Blitzableiter aus der Angst vor einem Blitzeinschlag erfunden. Aktuell könnten wohl auch all unsere Bemühungen um ökologisches Handeln unter dem Aspekt der Angst vor dem Verlust unseres Lebensraums betrachtet werden.

Schnell gehen die Autoren über, das Thema Angst aus verschieden Blickwinkeln zu beleuchten. Hier ist Ihnen eine betriebswirtschaftliche Definition wichtig. Die Autoren beschäftigen sich ausführlich mit den verschiedenen Angstarten, wie Existenzängste, Soziale Ängste und Leistungsängste sowie deren Unterausprägungen. Sie kommen zu dem Schluss, dass die Ängste im Unternehmen zurückgeführt werden können auf die Angst, Wertschätzung und Anerkennung zu verlieren.

Immer wieder lassen die Autoren auch Wirtschaftler und Führungspersonen sprechen. Dies verstärkt noch mehr die Bedeutung des Themas. Ausserdem belegen sie ihre Ausführungen mit Studienergebnissen und Kosten. Durch Ängste in Unternehmen, so schreiben sie, entsteht der deutschen Wirtschaft jährlich ein Schaden von über 50 Milliarden Euro (vgl. S.176).

In den beiden letzten Kapiteln widmen sie sich den Themen der Gegenmassnahmen. Dazu betrachten sie zunächst die zwölf wichtigsten Ängste in Unternehmen und konkrete Vorgehen, um diese Ängste abzubauen. Abschliessend widmen sie sich dem Thema der Führung, die Sicherheit geben sollte und es auch kann, wenn sie denn gelebt wird. Die Autoren gehen auf viele Aspekte der Führung ein.

So wird klargestellt, dass z.B. Mobbing aus Führungsschwäche erwächst. Sie fordern, dass Führungspersonen häufiger die persönliche Bedeutung und den Wert der Mitarbeiter für das Unternehmen hervorheben. Auch wird für eine gewisse Fehlertoleranz in der Unternehmenskultur plädiert. In einigen Bereichen gibt es Übungsorte, wo Fehler gemacht werden dürfen, wie der Flugsimulator für Piloten. Auch gehört der Umgang mit den Themen Krankheit und Gesundheit in den Unternehmensleitlinien verankert.

Führungskräfte, die ihren Mitarbeitern Zeit, Würde und Wertschätzung entgegen bringen, werden Ängste abbauen können und größeren unternehmerischen Erfolg haben.

Ich empfehle Kostenfaktor Angst jedem, der als Führungskraft bzw als Coach für Führungskräfte tätig ist.

Currently I have some presentations to prepare. So I looked at the word and I was curious as there seems something to be in it:

presentation – present – that’s a gift and also a state of mind and a moment in time and a location (pre = before)

So, a presentation, in my view, should be a gift and/or offering for those that come to see and listen, it should be engaging so people remain present at that moment and the speaker should be fully present in front of the audience.

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.

This is just a thought I want to keep: Investigate differences and similarities of Test Driven Development and Formal Specification. There is also a history of executable specifications – does this mean “tests”? Not sure I mix up a few things right now but I think it is worth to consider it a bit further. Also, recently Microsoft Research publishes more about SpecSharp (Spec#).

I am an active Google Reader user and today I thought ‘What does the “Discover” button do?’. Rather than thinking about it for too long I just pressed the button and guess what, it discovered a few really interesting blogs based on my reading habits. There you go…