I recently talked to a friend about an issue where a colleague of his had made a switch from one type of consultancy work to another (from coaching to development). My friend interpreted this as a sign that coaching assignments was hard to get and simple assumed that the consultant had been forced to change. Even more troubling was that my friend had planned to ask for a switch in the opposite direction (dev to coach) but now hesitated since, in his world at least, coaching assignments are scarce. I advised him to talk to his superiors anyhow arguing that it is always better to let those who dictate your future know what your goals and ambition are. Sure enough, his superiors listened and outlined what my friend should concentrate on to pursue his new found path. In addition, it turned out that the colleague who made the switch was doing it on his own will and not by some assignment drought.

In conclusion, open and honest communication won yet again over the evils of guess games and rumours. Keep on talking folks!

Jag träffade en vän förra veckan på Softhouse lunchseminarie om Kanban. Sedan vi sågs sist hade hon skrivit klart sin C-uppsats och nu väntade det sista årets studier. Vi pratade lite om teambyggande och då hon även varit på mitt föredrag i våras, The Five Dysfunctions of a Team och iterativ teamutveckling, berättade hon till min stora glädje hade hon använt sig av modellen under uppsatsskrivandet. Det var jätteroligt att få höra hennes feedback och jag skulle vilja delge er denna succéhistoria.

Min vän skulle skriva C-uppsats tillsammans med två andra studenter varav den ena hon inte samarbetet med tidigare. Hon var dock osäker på den nya studentens nivå och ville inte gärna vara en av de grupper som får ägna de sista veckorna i panik för att få klart sitt arbete. Med tankarna från lunchseminariet färskt i minnet valde därför min vän en ny approach. Innan de accepterade den tredje medlemmen gjorde de väldigt klart för honom vilka villkor som gällde och hur de ville arbeta. Därmed säkerställdes en gemensam bild av spelreglerna inom gruppen.

Kommunikationen inom gruppen spelade också en viktig roll. Genom att vara öppna och ärliga i sin feedback, alltid relaterad till målet, minskade friktionen och byggdes tillit. Det i sin tur tillät teamet att ge varandra frihet i individuella uppgifter eftersom man satt upp ett gemensamt mål och det var resultaten som räknades.

För att undvika det klassiska misstaget med en uppsats som innehåller lika många språkstilar som författare tog de fasta på metoder såsom iterativ utveckling och gemensamt ansvar. Varje kapitel samskrevs genom att de skrev en sida vardera och granskade alla texter tillsammans. Samarbetet stärkte vi-känslan och resulterade i en mycket högre kvalitet där de bara i enstaka fall var tvungna att gå tillbaka och skriva om. Eftersom alla kände till alla delar av texten undveks upprepningar och alla kunde ta på sig att hantera alla omskrivningar. Med tiden lärde de sig också vem som var bäst på analys, transkribering osv. vilket innebar att då det fanns olika arbetsuppgifter som gick att lösa parallellt kunde de optimera på flödet med målet att möte deadline.

Slutresultatet blev en välskriven och väl hophållen rapport med en tydlig röd tråd. De tre författarna var klara i förtid, och medan andra grupper slet dygnet runt de sista dagarna kunde min vän glatt peka tillbaka på arbetsdagar på max åtta timmar och en jämn arbetsbelastning.

”Aldrig har en uppsats känts så lätt och snabb att skriva, så här ska jag alltid arbeta” avslutade min vän sin historia med. Och så känner även jag. Oberoende av domän finns det alltid vissa saker med team som är konstanta, och det är behovet av kommunikation, samarbete och äkta teamkänsla!

The last four months or so I have had the incredible pleasure of working with one of the most dedicated and hard working teams I have ever met. Unfortunately not full time. I’ve been trying to balance two assignments at the same time, one being as a project leader for the team and another as an Agile Coach for a large scale Agile transition. During these months I have made some really great decisions and unfortunately some less great. One really crappy decision I made was to keep the two assignments separated by days, i.e. one assigment monday and thursday and the other tuesday, wednesday and every other friday. Seemed to make perfect sense to me way back then (four months ago), since I have had bad experience of working with multiple projects during the same day. What I have learned is that it is totally different being a leader for a team and being a part of a team when it comes to dividing your time between projects. I have experienced the loss of commitment and the transition from an appreciated leader to an annoying manager during those four months and all due to that fatal decision to keep assignments separated by days.

Being sick on the wrong days resulted in me being away from the team for two weeks and it doesn’t take the mind of a genius to realize that it causes problems. My hard earned learning from this is simply that you cannot lead by remote control. You have to be there every day, meeting the team and the customer face to face. if you have to be a part time leader make sure that it is a part of every day, letting it be a part f every week simply isn’t enough.

Last weekend me, my girlfriend and two of her friends played a game called Orangino. The game is about self-awareness where one player draws a characteristic card and score him or herself against it. The other players do the same and you then reveal all the votes to see if they match. Fun and simple eh? Naturally you end up with many funny (or daunting) situations where yourself perceived level is right on the other side of the scale from how everybody else sees you.

But I also found that it was a great way to build trust between people. I’ve met the two friends (a colleague of my girlfriend and his girlfriend) a couple of times by I don’t know them very well. We were however comfortable enough to be honest in our markings of ourselves and others. By the end of the night, I had learned more about the others in two-three hours than I usually do in… well in a long time.

I am now keen to try this out in my current team at work. It would probably not work for a completely new team since you need to be comfortable enough to be honest about who you really are. But I think the game has the possibility to generate more trust and team bonding than let’s say a personality test. This is because by playing the game and discussing the results people open up and get feedback about how they are viewed by their peers rather than to cement their own picture of themselves.

I keep coming back to Doug DeCarlo’s book eXtreme Project Management from time to time. It’s a little discussed book and in my oppinion it deserves to be on every project managers or Agile coach’s table. I have kept it with me as a source of inspiration for the last five years or so. Lately I have revisited the book to find a basis for explaining why some organisations fail when trying to do Agile development and I think that Doug DeCarlos idea of two world views could explain it all.

The Newtonian world View

• Stability is the norm
• The world is linear and predictable
• It’s controllable
• We can minimize change
• Increase rigor to increase security & probability of success

The Quantum Worldview

• Change is the norm
• Uncertainty reigns
• Look for reasons to change
• Relax controls to increase security & probability of success

Most large organisations I have worked with tend to have a Newtonian world view and an Agile adoption more or less requires a Quantum world view. So adopting an Agile way of working is not just about new methods and processes, it has a lot to do with changing your way of thinking. This causes a lot of stress, or cognitive dissonance, on an organisation and it’s individuals. What I typically see happening is that organisations try to pick the cherries out of the Scrum/Agile pie without realizing that they are mixing world views – just because cherries are great in pies doesn’t mean that they work equally well in a french onion soup.

I use the world views to explain some of the difficulties ancountered in an Agile adoption as well as a tool for myself to identify problems and solutions. If a problem originiates from a certain world view I believe that the solution should come from the same.

Ever met someone who rolled their eyes at you when telling them about the fallacies of waterfall or laughed when you told them that they could increase propability of success by decreasing control and trusting people to get the job done instead? Well, there’s a perfectly good reason for this and it is called cognitive dissonance – the discomfort of having two contradicting ideas (or cognitions) in your head at the same time, especially when the ideas have to do with who you are. Take smoking for example. Everyone knows that it  is dangerous and that it will kill you, still people do it. The contradicting ideas “I am smart and rational” and “I am deliberatley killing myself” give rise to cognitive dissonance and there are two ways to deal with it. Either we find excuses to justify our contradictory behaviour or we  change our entire belief system. Finding excuses is fairly simple and changing our entire belief system is a really tough job since it requires a paradigm shift and a normal human being can endure but a few paradigm shifts during a life time.

Prior to a new experience, be it in the run up to an important client presentation or facilitating a retrospective for a new team, I can find myself fending of attacks from the “What if… ?”-ghosts as I attempt to cover all possible worst case scenarios. While it’s wise to have a Plan B tucked away there’s a need to balance effort taken and value added.

What is Fear?

According to wikipedia, fear is an emotional response aroused by impending threats or danger, real or imagined. It is a basic survival mechanism occurring in response to a specific stimulus, such as pain or the threat of pain. Fear always relates to future events, such as worsening of a situation, or continuation of a situation that is unacceptable.

A Strategy for Coping

Identify a trigger that works for you. A kind of tell tale sign; an early warning. I use “What if… ?” as a trigger to jiggle me. If I catch the phrase popping up in my inner dialogue or preparation work I take a step back and run it through Gerry Weinberg’s FEAR filter.

According to Gerry, FEAR is an acronym for Fantasy Experienced As Reality. First remove the fantasies from the equation and then take steps to reduce whatever of the real risks you can take off of your list.

It seems that there are a lot of  Scrum Masters having trouble with their Retrospectives, either they don’t get any real commitment from the Team or they seem to think that they need to have all the answers (which of course is not true) for any questions that might come up during the session.  The simple advice would of course be to read the brilliant book Agile Retrospectives (by Esther Derby and Diana Larsen) to find laods of inspiration and great activities to use during your Retrospective. Another way could be to use the Retrospective as an opportunity to excercise your coaching skills and use the T-GROW model to guide the Team through the retrospective. I have tried it on a couple of occassions and it has worked really well. I think it is a good thing to try different things out, to avoid boredom as well as to learn new stuff.

T-GROW stands for Topic, Goal (for the session), Reality, Options and Wrap-up and is commonly used as a structure for a one-on-one coaching session where it is the coachee who brings a topic to the session. Here’s how I have used the model to coach a Team during a Retrospective:

Topic
The first thing you need to do is to establish what the Retrospective will address. In a Team coaching situation I let the Team do some initial brainstorming to find a common topic they think we should be focusing on (see the post on Creative Processes). Simply let the Team bring up a lot of ideas (divergence) on sticky notes and have them put dots on those they find urgent or interesting (convergence). Another way of doning this could simply be to suggest a topic if you have noticed some problem you think would be important to find a solution to (this is not done in one-on-one coaching). Make sure that the Team really agrees with your observation though, otherwise you risk ending up in a blame game situation.

Goal
The Goal for the session, that is what result do the Team want after the retrospective. It might be a simple goal as “we want to understand why we have so many defects”, “we want to find a way to increase team morale” or simply “we need a better way of writing requirements”. The important thing is that the goal is something that is achievable in the amount of time you have for the Retrospective and that it is something that the entire Team agreees on. I simply ask the Team for suggestions instead of doing a brainstorming session.

Reality
This is where you ask the Team to describe the reality as they understand it, the aspects of the problem or the effects of it. The purpose of it all is to get a common understanding of whatever the Goal aims for. Sometimes I chip in here, but I always try to share observations not conclusions. The role of the coach here is to ask clarifying questions and make sure that everyone is heard and that any disagreements about anything are solved vefore moving on.

Options
What options do the Team have to achieve the Goal of the session, to change their reality according to their Goal? There might be different parts of Reality that could be changed to achieve the Goal or there could be different approaches to change the same part of Reality. The coachs role here is to help the team find out what they themselves can change and what they might need help with from the organisation. This is also a creative process, go for a lot of solutions and then reduce the ideas to a manageable amount.

Wrap-Up
This is where you get a commitment from the Team – of all the options they have, what are they willing to try out? If it is a complex solution you might need to detail it a bit further before closing the Retrospective, you want to iron out all the wrinkles before you’re done.

You might want to read up on the T-GROW model before trying this out, just remember that it is not a real coaching session and that you are allowed to make mistakes and ask your Team if you get stuck!

Most Scrum Teams I encounter as an Agile Coach experience difficulties with the Sprint Planning. I think there are a number of reasons for this, but one of the major reasons is that there seems to be a large misunderstanding about what the Sprint Plan actually is and what it is good for. Scrum simply states that the Sprint Planning is where the Team turns the selected Product Backlog Items into tasks and most Teams seem to do a very backlog item oriented breakdown, i.e. they look at the selected backlog items one at a time and discuss what tasks they need to perform to implement it. A typical task breakdown of a backlog item might look like this:

• Design
• Code java
• Design database
• Code UI
• Write tests
• Testing

Some questions that come to my mind are: is this really a plan? When is Code Java done? What happens if defects are found during testing? How does the team collaborate around those activities? Teams that use this form of Sprint planning seem to be living with the misconception that they have to develop things in the order the product owner prioritized the product backlog to ensure that they can remove items from the bottom of they discover that they can’t meet the Sprint Goal. The Sprint Goal in these cases is typically stated as “do the ten top prioritized backlog items” or “develop nn points of backlog items” or even “do as many backlog items as you possibly can”.

So what is the problem with this type of planning then? Well one thing is that it doesn’t promote collaboration or interaction, another is that it is totally devoid of system design and yet another is that it is based on the assumption that the Team will need to remove things.

The solution to this problem starts at the Product Owner and his Release Plan (or road map or whatever you want to call it), it absolutely must contain clear goals! This gives the Team an overview of the evolution of the Product and it enables them to make better design decisions. Next step is to keep the Team close to the product backlog, they need to look at it frequently and work together with the Product Owner to get an understanding of what is to come, why the he wants it and how the Team need to solve the problems they are facing to prepare for the future (careful not to introduce any waste though).

When the Team has had a look at the road map and understand why the backlog items are important to the Product and the Product Owner it is time to prepare for planning, time to create the Model. The Model could be in UML or any other available modeling language or it can simply be a lot of boxes and circles – it doesn’t really matter as long as the team it! It is the blueprint of the Product and guides the Team to what should be done and what the Increment will look like after the sprint. If you don’t have a Model you need to create one, it is important that it represents the product as it looks right now, what level of detail is, again, up to the team.

During Sprint Planning the Team looks at the Model and the selected Product Backlog Items and have a discussion on how the model needs to change in order to meet the Sprint Goal (might be a good idea to have a look at the Robustness Analysis of the Iconix process). When this is done the team identifies the things they need to produce during the Sprint, the Results, and in what order it is most beneficial to develop them and creates the lan. The plan might not be anything else than the annotated Results on the wall in an ordered sequence. The important thing is that the team knows what to do, how to do it and how it will look when it is done and that they have considered the Definition of Done.

The major benefits of the Model Driven Sprint Planning are that the design and architecture becomes the business of the entire Team and it promotes knowledge sharing. It also forces the Product Owner to collaborate with the Team to be able to prioritize the Product Backlog in a good way. It also forces the Team to take their commitment seriously since it is more difficult to remove Product Backlog Items mid Sprint to push down the Sprint Burndown Chart, instead they have to use problem solving which is a great team exscercise.

The last couple of months I’ve learned that an important part of the creative process is the concept of divergence and convergence. They are the two modes of thinking needed in a creative process. Divergence is an important part of ideation, the process of coming up with as many ideas as possible. In the divergent mode you blurt out ideas no matter how crazy they might seem and keep an open mind, a crazy idea might send your mind of in a completely different trajectory and new interesting ideas come up. Convergence is the exact opposite of divergence, it is the process of selection and reduction to find a few (or even just one) great idea to develop.

It is incredibly important to keep the two modes separate, it kills creativity to come up with an idea just to have it shot down by someone five seconds later. That creates an environment where people censor their own ideas and that’s exactly what you don’t want. It is important that it is crystal clear to everyone involved in the creative process what mode is expected of them and that everyone takes responsibility for keeping everyone on track. Don’t allow convergence and divergence at the same time, keep the modes completely separate in some ingeniuos way. Have two separate meetings or have the divergent phase in an informal environment (sofas are great for that relaxed mode needed) and move the team to a formal (such as a meeting room).

I have been somewhat prejudiced in my view towards people and creativity in the past since I have thought that some people simply are not creative at all. That would be those who try to find all caveats with any idea proposed or simply don’t come up with any themselves. I have now come to the conclusion that I have been the problem, not them. I haven’t had the divernet/convergent concept in my toolbox so I haven’t been able to create an environment sutitable for creative work unless it has been with “creative” people, that is people that thinks and acts just like myself. I’ve been a moron…

It is important not only to tell people what mode they should be in, but also create an atmosphere where they feel safe enough to share the wildest ideas and engage in unfiltered, passionate debate [Patrick Lencioni] to find the greatest ideas. Again it boils down to trust and creating that environment where people become empowered [Jerry Weinberg].

In Scrum, for example, there is need for convergence as well as divergence when creating the product backlog (writing stories), sprint planning and in the retrospective where it is essential to ensure its success. Have a look at your next meeting and try to identify who’s in divergence when convergence is called for and vice versa, see if you can identify what mode is needed and facilitate people into the appropriate mode – even if you are not the meeting facilitator. See if it makes any difference at all, it sure has for me!