We have moved

As of today we have moved our blog to http://peopleandleadership.wordpress.com

See you there!

The Authistic Organization

In his book Blink, Malcolm Gladwell tells a lot of stories about how too much or too litttle information and stress can hamper the human capability to make good decisions and cause the brain to enter an authistic mode. A lot of information gets down prioritized by our brains to prevent overload and the more stressful the situation is the more our brains filter out to keep our focus on what's most imortant. People involved in gun fights tell stories about not hearing the gun shots and seeing things in slow motion as their brain goes into overdrive to promote survival. In a stressed team you can observe the same symptoms. The more stress the team experience the less they will communicate and as the information flow decreases the quality of their decisions will decrease as well - the team goes authistic.
Being an Agile coach in large organisations in this time of financial crisis I see the same symptoms in managers. As the stress of financial survival increases a common reaction is to increase control and increased control most of the time means that someone has to measure more stuff and create reports based on those metrics. And all this leads to is an authistic organisation with loss of decision power as the result. A typical symptom of this is that meetings doesn't end in time and no real decisions are made.
The only sensible solution to this would be to provide the organisation with clear goals and make sure that everyone knows whats at stake - their jobs - and trust people to do what's best in every given situation.

Stay focused!

In a team that I am coaching at the moment a problem with focus came up as they got closer to the end of an iteration. In the retrospective the team talked about the loss of energy and motivation towards the end of the iteration and decided that they had probably undercommitted and decided to shorten the next iteration since it contained less work and the goal was to get the software released. They estimated that they would be done in a week.

As the estimated week came to an end they again experienced a loss of energy and motivation. We had a discussion about it. If the length of the iteration did not stop them from loosing focus at the end then what was?

If I look at a typical iteration it contains larger chunks of work at the beginning. Towards the end the chunks get smaller; defects, adjustments, updates to documents and models and new small chunks keep appearing as the team runs test sessions. The problem seems to be that the smaller the chunks of work becomes the more the team loses focus.

In this case we solved it by shortening the lenght between team synchronization, from once a day to twice a day and that seemed to solve the problem. A simple solution to a difficult problem...

You get the organisation you deserve

The other day I did a two day Scrum Master training and found to my amusement that there were a couple of managers attending. In my Scrum classes I tend to focus quite a lot on how teams work and the importance of building small successes. By that I mean that if you are going to change something you need to have happy, motivated people and one way of getting there is to make sure that the team actually succeeds and that the success gets noticed by the organisation surrounding them. One way that I do to make sure that my teams succeed is to make sure they don't over commit during the first couple of sprints. I make sure the Product Owner presents a clear, fully achievable goal to the team and keep the team focussed on that goal and nothing, absolutely nothing, else.
When I talked about this during the last Scrum training I received a question from one of the managers: how do you prevent the teams from becoming lazy? That is, what if they don't do as much work as they could, if they have hours left and don't fill those hours with work.
How do you answer that? I answered it with a question: what does greed mean to you and how to you think greed affects productivity?
I think that it is a result of greed if you always feel that by getting what you want you always want more and greed leeds to a situation where the people giving you what you want feel (a)bused and it provides a perfect growing ground for distrust and manipulation. If you run your business by greed you will get greedy employees and greedy people tend to be manipulative. Every parent knows that kids don't do what you tell them, they do what you do. The same goes for an organisation and in an organisation it is the management that sets the agenda and the culture - you get the organisation you deserve!
My advice for managers with lazy workers would be to stop whining for just a while and look at themselves and figure out what they did to make people lazy and then adjust themsleves and see what happens to their lazy crew...

The ubiquitous lack of trust

As an Agile Coach I see a lot of efforts to make the transition into the Agile paradigm. A lot of energy is put into figuring out how to do it and how they are going te get the job done - they because it is almost never the people planning the transition who is going to get the work done.
Weeks turn into months turn into years of writing detailed process descriptions on how to deal with defects, when to abort sprints and who is responsible for what and drawing unintelligible process charts with two billion arrows, boxes and toll gates. All done with hope of getting it right the first time...

The lack of trust between management and developer seems to be as strong as ever and comments like "we need to make sure that they do things the right way" and "you know how developers are, if you dont pressure them nothing will get done" or "developers just want to work with cutting edge technology" seem to float around in every management meeting I participate in.

So, with this attitude the Agile transition is planned for a couple of years and no one bothers to build in continuous improvement and no one seems to get that the most important accelerator is the empowered and self organizing team - this is 2009 and we are closer to 1984 than ever!

Teams, conflict and self awareness

Lately I and my team mates have been increasingly busy and it finally got to me. During the last two weeks I became more and more bitter, interpreting everything as personal critique, shooting down ideas from my peers and just really been in a downward spiral. I stopped communicating with my team mates and finally got angry with them because I felt they did not support me. When I finally realized that my anger might stem from lack of communication, I had waited so long with taking the conflict that I felt I did not have the time since other matters pressed. Then, yesterday, I finally erupted and confronted them. I blurted out my feeling in a crude and maybe not optimal way but boy did it feel good to get it of my chest. With one day hindsight I can honestly say that I could have handled it better, would like to have had more time since not everyone had time to speak their mind, and should by now have better self awareness then to end up in this kind of situations. But all in all, it has really helped me to move on and be energetic again. It is amazing how much it helps to be open and honest in your communication. And how terrible and devastating it can be to you as a person and your team if you're not!

Slow motion and a soundtrack of my life

All I really wish for at this moment is the ability to make the world move in slow motion and a soundtrack to go with it. How cool would it not be to have your own personal soundtrack for those action packed "bigger than yourself moments"! Like when you run for the bus (or enter an important meeting), everything slows down, you hear the soundtrack from The Rock pumping and as you step down in the water pool in the middle of the street you can see how the water spashes...

I have wished for this for a long time and at least gathered a library of soundtracks to accompany me. The latest in my compilation arrived last Friday: Echoes of War. Music from WarCraft, StarCraft and Diablo is now following my steps wherevever I go! Orchs beware!

The Art of Listening

During my career I have had the opportunity to work for a lot of different managers, project leaders and CEO's... unfortunately most of them were terrible leaders. One thing I have found that all of these terrible managers have in common is that they might listen to you but they don't hear what you are saying and the feeling of not being heard is truly a team killer.

So what is the art of listening then?

• Just listen
• Do not give explanations (unless they are asked for)
• Do not interrupt
• Do not go into defensive mode
• Confirm what you've heard and...
• Ask what you can do (don't offer help unless it's asked for)

That seems pretty simple, but I've met very few mangers that were proffiecent in the art of listening.

Vital play

Last month I wrote a post about game play and how I wanted work to be more like that. I've spent some more time thinking and recently stumbled across this TED video about play and why it is important. It turns out that not only is it stimulating and fun but also vital for our brain and perhaps even our survival! A under stimulated being will sooner or later be depressed and this actually results in a shrinking brain!! Ouch! 

Before we continue let me just clarify what play is. The state of play occurs when no particular purpose exists for our actions. If purpose is more important than the act of doing it is probably not play.

Now why is play important then? For one thing it is the medium to link our brain to our body, this is how we learn. And play can exist in many forms such as social play (the want to belong), ritual play (sports), storytelling, imagination etc. etc. But I also believe that it is in the act of play that we get as most creative. Where we let our constraints go and dream up new ideas. Without it, a small amount of depression enters and we stagnate in our development as beings. Most of my ideas pop into my head from nowhere and then tag along for a while. But it is when I interact with others and play around with the idea that it takes off and becomes something more. And I can feed off that energy for weeks! (and if you want a money making angle on it, that energy is fueled straight into my work).

So keep on playing! If not for us (mankind) then for your own sake, and for your brain… and because it’s god damn fun!

Keep you code nice and tidy

Just wanted mention a nice little post about TDD and what might happen when you don't keep your tests nice and tidy. Or as Wendy Friedlander puts it:

However, the moment the tests slow, the practices start to slip...

1. Writing code and verifying it works by launching the app, then creating the tests
   
2. Making the test pass before verifying it failed.
   
3. Not running all the tests before check in.
   
4. Not refactoring because it takes too long
   
5. It stops you from working close to 5 because you don't want to wait for the build
   
6. Not adding tests at all because you don't want to break the build and don't want to wait to find out
   
7. It ruins all the fun.
   

 

Check out the rest of the post at Wunda's World

Creative doodles

I just so happens that I have to team mates which doodle a lot (one just doodles, the other insists on drawing small people as in the picture below). Naturally they are, like me, highly creative people. Well, according to an recent article in Wired this might accutally aid them in remembering what I'm going on about. By doodling they distract the brain just enough to stop it from going off into...                  ... some daydream. I wonder if my habit of chewing on my pensils has the same effect. =/

Changes... to what, to whom?

I had a discussion with an old friend last evening, the kind of dicussion you should have over a pint or two. The subject was change and the question what; what do we try to change, behaviour or personality? (It might be obvious, if for no other reason then because trying to change peoples personality is morally wrong. Who are we to deem what is the right one.) According to my friend (and many others) personality do not change after the age of ten. I certainly remember some of my reactions from kindergarden which would be the same today. Thus, we change behaviour and by logic follows, that if behaviour can change, then we can succeed no matter who is involved. This also means that a person hiring do not need to hire the best, but rather make sure that the organisation promotes the type of behaviour we want and that the people inside lead by example.  

Another thing we discussed was if it was worth striving for building the best team, or if we should simply accept that we have what we have and try to create the best working conditions by improving processes and tools. Talking to a collegue today he put me straight. We never strive for building the best team or creating the best process. Instead, we take small steps, always improving to create a better team or process, because there is always room for improvement (and so for more consultancy ;)

Focus on the right stuff

Why is it that we, ok, I keep on focusing on the wrong stuff. I held a short 40 minute seminar this week on Team Dynamics and The Five Dysfunctions of a Team. Directly after I rated my performance as ok but not more than that. It could have been more passionate, I could have been more snappy and I could have been better... as always of course. Then I read the evaluation forms... I shouldn't. On a scale of one to four 25% gave me two, the rest gave me three or four. Which part did I focus on? The 25%! My "ok" took a huge fall down to "crap". Luckily, my team mates did not let me crash and burn and instead pointed out the fact that at least 75% actually got something out of the seminar. Thanks guys!

Gathering Data

The other day I was attending a strategic product development meeting at one of my clients and I decided to gather some data during the meeting. I decided that I was going to count the number of statements people made and how many questions went unanswered during the meeting. After the meeting I was asked for some feedback on how the meeting went and I decided to share the data instead of my conclusions. The result was amazing!
Instead of having a lot of people trying to defend themselves againt my conclusions I got a lot of thoughts and reasoning about what the data might mean and when I shared my conclusions I discovered that I didn't really have any but instead had a lot of theories about why the data might mean. All in all, it was a great experience for me in that it actually opened my eyes to the importance of actually observing and not jumoing to conclusions right away.

Personal Insight

I had the fortunate experience of receiving some fantastic feedback from a friend of mine the other day. This is a guy who I've known for a lot of years and a while back he became a project manager at his company. At that time he asked me a lot of questions and I talked about my views on leadership, not really thinking that much about it since it is something I talk a lot about.

This weekend he told me about his current project and how he managed it and he obviously felt proud about a lot of things and I listened to him and was kind of surprised to hear that we shared a lot of views on leadership. Suddenly he told me that most of his leadership style was inspired by me and my tips and tricks as well as some of the books I had recommended. He ended his heart felt feedback by saying something that really made me think, he said: you talk about things from your own perspective, there is always a personal experience connected to all the theories and models you share - that makes me listen carefully to what you say and it makes it easy to belive in what you say.

Of course it made me feel very good and I thought about his words all weekend and I realized that this is the way I learn about things... I find a problem in my own, personal or professional, life and apply the models or theories I read about to it. That makes it easier for me to understand it and it also makes it possible for me to decide if it is something worth keeping in my mind. It also gives me a vehicle to convey that model or theory to others, simply by walking through my own learning experience with them.

I probably need to think a bit more about this and see if I can wrap this insight in some neat model for others to use, maybe there already is one out there?

A Proposal Framework

I discovered the following framework for proposals (no not that kind!) while reading Marks and Meaning by Dave Gray. When making a proposal the golden rule is to keep it simple, brief and to the point. Here's the template Dave suggests:

1. Why should you care: Briefly describe the problem and why the "as is" state needs to change.
   
2. What you/we stand to gain: Briefly describe the "end state" you envision
   
3. What I propose: Describe what you want to do, with special attention what's unique or different. You might need to explain how or why it is different than things that have been tried before.
   
4. How it will work: Describe the resources you will need, and break down the entire plan into three easy-to-understand steps, complete with milestones and deadlines.
   
5. Risk considerations: Take a balanced view and do your best to define the risks, relative to the rewards, of proceeeding
   
6. Next steps: What specific action(s) fo you want from the person you're making the proposal to, right now?
   

As I jotted down this proposal I was reminded of an occasion a few months back when I excitedly shared an idea that I'd dreamed up with one of my colleagues. His response - sheer bewilderment. On reflection, I realise that I'd fast-tracked to Stage 3 and left him standing haplessly at Stage 1.

Sell the problem first before attempting to sell the solution. It's one of the cardinal rules of consultancy, i guess. If the customer doesn't realise that they have a problem then they're not likely to be too open to your solution, regardless of your tear jerking and heartfelt pitch.

3D: A Model for Learning and Improvement

If work was more like games and play

What would work look like if it was more like a game, and playing the game was more like playing in the sand with you pals at age four? My guess it that it would be more fun,  effective and stimulating than today. This is my reasoning:

• When we play a game, we readily, without objection, accept the rules of the game. No matter how ludicrous they might we, we simply accept that if we want to participate in this game we must obey to some laws that someone set up. And no matter how we roll the dice or upgrade our level 56 Blood Orch Mage we still accept these constraints.
• On the other hand, when we used to play in the sandbox at kindergarten, we would dream up the most amazing stories of dragons, beasts, cars etc. And the possibilities where endless. If we wanted the car to fly it could, no questions asked.

What if we could combine these two views, and take them with us into work. How easy would in not be to try out a new process or method? We just set up Scrum for example, agree on the rules and then play! And how magnificent would not our stories, solutions and conversations be if we would just allow us to dream as we once did?! I think we would be the most creative company in the world, and having a laugh doing it!

Waste of space! Or Why today’s electronic Scrum tools does not work!

I like computers. I like how they enable me to dream up things I could never have imagined, let me indulge in information from far and wide and communicate with my friends wherever whenever. I also like pen and paper (and whiteboards, coloured pens, index cards, post-it notes etc). And I like to communicate in real life!

As a coach in Scrum and team building I know what works for me in the small local team. We use all kinds of stickers, pens, flipcharts, post-its and what have you to make sure that information is radiant, free and flowing all the time. The ease of use and the unbelievable flexibility that these tools offer are probably endless. What I don’t like is stuff that interferes with this process, cramp it and my steal energy and time. Computerised Scrum tools are such tools! At least the ones I’ve tried so far.

I can understand why my clients wish their distributed organisations had the same flow as the single co-located team. I can also understand the problem with using my analogue tools over large distances. I can even understand, although I question this sometimes, the need to “document” stuff. But I can not accept the impacts it has on us. The tools often are extremely developer centric with all kinds of nifty features but not very flexible at all (also called waste in Lean). They force you into a, for me, unintuitive behaviour and after two hundred and forty eleven clicks I give up. It just takes way too much time to change a simple little number, add a special mark, or group a bunch of stories. Comments like “if froze for some reason and turned upside down”, “he’s the owner of that task but did not notice” and “the story is not in there, I can’t see it” simply never occur with analogue tools. If you add a story it’s there, right in front of you. You can touch it, change it and even remove it! And if you get short on time and need to rearrange, specially mark or add some info to a story it’s so intuitive that (believe it or not) someone without Scrum knowledge knows how to do this!

Don’t get me wrong, there is a need for digital Scrum tools. But it is not a trivial task to create them! I think we need to rethink how our Scrum tools work and which parts of the process it makes sense to digitalise. And we need to stop waste time, space and energy on repetitive tasks in tools that does not support agile thinking and behaviour! 

Look on the bright side

Since I wrote the post on appreciations I have had something tumbling around in my head, couldn't figure it out until I had a coaching session with a Product Owner the other day. We talked about the problems he saw in their organization and I pointed out to him that they had a lot of great things going for them and maybe it would be a good idea to use those to get even better.

So what I just realized is that if it is more efficient to give feedback about good stuff then bad stuff, maybe the same works for organisational problems? What if we, as consultants, tried to find the things that really work at our clients instead of focusing on what's really not working. If we could point out the good stuff and strengthen them instead of trying to get rid of the negative stuff I think we could generate a positive momentum and maybe even make change easier - now all I have to do is to figure out how to do just that.