Archive for May, 2012

For a while now I have been discombombulated. The cause of my confusion and desperation has been around the issue of management. 

I am not talking about Leadership. Leaders are people (whether in a position of hierarchy or not) that naturally foster an environment of collaboration, understanding and consensus. No, what I am talking about is the ability to influence creatively or constructively criticise the status quo to a person considered your “superior”. I want to use the term superior loosely knowing how much people will hate it, to represent an authority figure in a command and control environment. After all, Managers who aren’t getting the message about Leadership really do think they are superior (how many sweeping generalisations can I put in one post?).

I have come to the conclusion that a good number of employee frustrations are systemic from the culture; a culture which is powered by management. It is incredibly difficult to change culture from the bottom up. It can be influenced from the bottom up but there is a point where it cannot stretch anymore without management buy-in to the culture change. Failing senior management or C-suite buy-in to seriously throw money into changing a culture (yes culture change costs currency) I have been pondering how it may ever be possible for this problem to fixed in any way.

The C-suite don’t get it. Either they weren’t educated in it, don’t want to be educated in it or are too busy improving shareholder value. They are the Lords of this day and age, and how much did the Lords ever care about their serfs? Middle management are the Courtiers. Lower management are the cooks. Everyone else is working in the field.

Groups like STOOS believe that they can solve this problem through conferences targeted to the C-suite.  It is an interesting approach, but the sort of C-suite executives that will attend are the ones that I think for the most part are already on the journey or starting to question their belief system. It will make some in roads but I fear it won’t cross the chasm and I desperately ache for this chasm to be crossed. More needs to be done.

Others believe that they need to be right-shifted. I am admittedly still looking into this but have yet to get into significant enough depth to see if there is a mechanism to induce the chasm crossing.

I have been relaying this story a lot recently -

When a new person joins your team watch them closely. Watch how they learn and what they say. Watch how people react to what they say. Start to gather a pattern. What you will find is that when people join an organisation they are highly motivated. This is called the “Honeymoon phase”. The organisation is a veritible field of endless possibilities. They have been sold a dream by a HR department and manager.

The new person will listen for a while, enveloping themselves in the culture, trying to best see where they fit. They will start critically thinking early. They will ask questions like “Why do you do <insert task> that way?” They are trying to frame the task around their mind-map of how they have done it before and are judging it for efficiency and common sense. Failing a suitable answer they will delve further. Naturally they will gravitate towards the 5-whys, despite never hearing of Lean.

Eventually their critical thinking will be blocked by the “Monkey and the Banana syndrome” response. A root cause is not met and the first brick on the wall of critical thinking resistance is placed. As their first few weeks progress the same scenarios occur. Their brick wall begins to get higher.

When the wall reaches their knees self doubt sets in. Naturally they try to fight it, but in a different way. Rather than taking a critical thinking approach they will try a different tact. They will try the innovation path – providing suggestions of how they have seen it done elsewhere and the benefits that they had in doing it that way. They will get more Monkey and Banana syndrome responses or “We have tried that before, it didn’t work because <x> and <y>”, then the new person is back to the same lack of response to critical thinking. Innovation bricks now get added to the pile that is up to their knees.

After a few months their wall is up to their eyes and they can no longer see over the wall. There is no vision. No hope. The organisations culture is now embedded in them.

Sometimes I am asked what the Monkey and Banana syndrome is (usually younger people who haven’t heard it before). For those unfamiliar with it this is how it was told to me about fifteen years ago. I haven’t ever read the internet version so it may be a little different for those that have read it:

This is a story based upon a scientific experiment. A scientist puts into a large white room a metal ladder with a finger of bananas hanging from the ceiling. The middle step of the ladder is rigged to set an electric shock through the metal floor of the room. The scientist then lets in five monkeys. The monkeys excitedly see the bananas. One scrambles up the ladder and gets to the middle step. An electric shock is sent through the floor and ladder with all monkeys get shocked. The second time the monkey hits the middle step the other monkeys begin to get the picture. On the third attempt the monkeys pull the hopeful monkey on the ladder down and beat him up.

Subsequent attempts to climb the ladder result in beatings. The scientist then takes out one monkey and replaces them with a brand new monkey. This monkey sees the bananas and proceeds towards the ladder. He only gets two steps up before he is pulled down and beaten. He never knows why but after the second attempt he knows that if he tries to get up the ladder his peers will exert physical pressure.

The scientist continues to rotate the original set of monkeys out one by one and replace them with new monkeys. Eventually the room is filled of monkeys that have no understanding about why they are not allowed up the ladder but that if someone ever tries they should be beaten up.

“That’s just the way we have always done it around here.”

So you can see by my thought process that unlike some other thought leaders, I actually don’t think the ability to critically think is a lost art despite many years of behavioural conditioning supposedly beating this out of us. I believe critical thinking is a subconscious ability that we all have and continue to have despite command and control overriding it almost every single day. It is there. We have just given up trying to use it because no one is listening.

To get out of this endless rut I see a few possible solutions:

  1. Managers get better listening skills. Right now that you are done laughing, what are the other options.
  2. People get better persuasion and communication skills. On a scale of 1 to 10, 1 being highly unlikely to work and 10 being certain to work I probably rate this a 3.
  3. Have scientific metrics that prove empowerment, innovation and critical thinking are advantagous to the bottom line of an organisation. I am pretty sure the information is out there, but this depends on solution 1, and well, there goes that idea.
  4. Revolt. This is essentially option 2 but done on a less individualistic scale and more ganging up. This does happen naturally in teams but this method seeks pre-emptive goal setting. Despite being able to do this it will only work for one level above the team and from there will fizzle to get any traction, unless you get many teams to revolt at once and that is getting beyond the realm of possibility. Someone suggested to me that as an analogy it is like the monkeys ignoring the ladder and hopping on top of each other to form a monkey pyramid to get to the bananas.
  5. Teams get better facilitation skills and all team sessions have a pre-set, well skilled facilitator. In a team environment I give this a 5 to work, but outside of a team environment we are back to the original problem. That said you could encourage an environment where all suggestions of process change and innovation are raised through a facilitated team environment (sounds very Agile doesn’t it?)
  6. Enable a way to give a singular voice a pedastal. I am toying with an approach for this. I don’t think this will realistically happen inside of an organisation but I wonder if there is a means to force more social pressure for the C-suite to change their belief system.

What do you think? Are there other options to open up the eyes and ears of management?

Read Full Post »

It all started with a problem with the way we were doing software development. Projects took years with “phases” such as Requirements, Design, Development and System Testing taking six months each. We used to create thud factors where our value was determined by how much the table shook as we laid down our documents that we laboured over for hours on end. There had to be a better way, and as it turns out, there was: Agile.

People often talk about how Agile has failed or not solved anything. But even if Agile had not come along the world of software development would have had to have changed. In a market when speed is important, in a market where delighting the customer has a direct impact on sales, we would have had no other choice then to look at solutions such as continuous deployment, automation and suped-up customer collaboration.

But Agile didn’t solve everything. Some teams found it incredibly draining to apply it to their environment. They described it as trying to fit a square peg into a round hole. They were teams that had large backlogs of work not a “project”, they were not date driven and sometimes they had specialisation. In essence they were operational or maintenance teams. So they sought other approaches that would suit their needs, methods that were more supple to their workflow but still had elements of agility. And they found Kanban.

There are still teams doing work who haven’t had their problems solved. These teams have a different problem again. They have a set date for an outcome to be delivered, high specialisation or domain specific knowledge and variable demand based upon the stage and breakdown of the work.  This doesn’t normally happen in small organisations. This is a problem for large to massive enterprises. Neither textbook Agile nor textbook Kanban fit well in these teams. Primarily this is due to the fact that a stable velocity or lead time cannot be achieved – simply put, the team is too variable. The variability of the team changes based upon the story being delivered.

Let’s take a look at the work for such a team:

  1. Feature A
    Story 1, Priority 8, RPSI (P – Fred Flintstone, S – Barney Rubble, Bam Bam, Ken, R – Bam Bam, I – The boss)
    Story 2, Priority 6, RPSI (P – Fred Flintstone, S – Wilma Flintstone, Betty Rubble, R -,  I – The boss)
    Story 3, Priority 1, RPSI (P – Fred Flintstone, S – , R -, I – Betty Rubble)
  2. Feature B
    Story 4, Priority 2, RPSI (P – Barbie, S – Ken, R – Ken, I – Matel)
    Story 5, Priority 3, RPSI (P – Barbie, S -, R – Ken, I – )
    Story 6, Priority 5 (P – Ken, S – Fred Flintstone, Bam Bam, R – Bam Bam, I – )
    Story 7, Priority 9 (P – Barbie, S -, R – Barbie, I -)
  3. Feature C
    Story 8, Priority 4, RPSI (P – Ken, S – Betty Rubble, R – Betty Rubble, I – Bedrock)
    Story 9, Priority 7, RPSI (P – George Jetson, S – Barbie, Betty Rubble, R – The Thunderbirds, I – )
  4. etc etc

You will notice that there is an attribute attributed to each story that normally isn’t there for Agile work. This is a modified version of a RACI and RAPSI, which is a roles model for processes and activities and a role model for deliverables respectively. The example above predominantely uses the RAPSI model, but some work would benefit from the RACI more. A RAPSI normally stands for “Reviewers”, “Approvers”, “Providers”, “Supporters” and “Informed”. The provider is really the owner of the story, the person accountable. Supporters help the generation by answering questions and providing input. Informed receive the output but for information purposes; sometimes people believe this means they are the end consumers but that is not the intent. The “Approver” has been taken out as it isn’t the intent of an agile process to have heavy approvals – the assumption is reviewed is enough.

Some stories don’t have corresponding names against the roles. That is fine as long as consideration has gone into whether such a person(s) exists and why this story doesn’t require such roles.

It could be argued – when is a team no longer a team? But despite this the work needs to be done and the team does need to collaborate – not on a daily basis possibly, but on a story basis.

Trying to plan for this variability of when certain people are needed in the team could be potentially chaotic. If we tried to work in priority order and ensured that all of the cards were roughly the same size how could we potentially plan out resource needs in advance? The simplest solution is to give a weighting to the RPSI elements. As an example Providers would be ’4′, Reviewers would be ’1′, Supporters would be ’2′ and Informed is ’0′. Lets look at the resource usage for the first five cards in priority:

  • Fred Flintstone 6
  • Barney Rubble 0
  • Wilma Flintstone 0
  • Betty Rubble 3
  • Barbie 8
  • Ken 12
  • Bam Bam 3
  • The Thunderbirds 0
  • The boss 0
  • Matel 0
  • Bedrock 0

So Ken is very heavily focussed at the start of the work, despite being the provider of only two cards. We are hardly using Betty, and not using Barney or Wilma at all. If the team takes the assumption that there is a maximum threshold for a person and that value is 12 for any person for a week then this week is full and no more should be pushed into the weekly plan. So what does this mean for the under-utilised team members? Surely they would go back to doing their other work until the project is ready to pull them?

What has this method done – it has taken into consideration the constraints of the team, the constraints of the story and created a framework to plan week by week without ever having to estimate. It considers the maximum limit of the team and the variability of how they may be involved in a day to day basis. What it doesn’t do too well is drive for efficiency and assumes that lighter or dead time is spent elsewhere.

This approach could be called “VSM” or Variable Systems Method, but someone else took that acronym. It is a different method for a different problem. The Variable Resource Method.

Disclaimer: This is not a method I have been using on software teams, but it is a method I have had to entertain for Agile in the Business. Your weakest link is your busiest resource.

Read Full Post »

When massive multiplayer online gamers work together as a team (called “Raids”) to defeat fantasy targets (called “Bosses”) they are repeatedly performing the steps of a Lean Startup – Build, Measure and Learn.

For raiders, “build” is working together to achieve the desired outcome of defeating the boss. They have a meta hypothesis – that the boss can in fact be killed and that once killed an item of superior value will be earned by one or more of the raid members. In the Lean Startup world there is also a meta hypothesis – that you can make a revenue generating business. In both cases it is possible to fail at this meta-hypothesis and disband the team never to try again.

But the incremental hypotheses is where it gets really interesting. Raid teams generally know how to operate together as a group. They have their own specialised roles. Additionally some people are able to be multi-disciplinary and can take on the roles of others. When first placed against a boss (who in business terms is a potential revenue generating customer) they will be armed with an initial hypothesis. It may be something as simple as what is called “tank and spank”. In a gaming world this means taking a standard stance of having one person taking the bosses attention, a few healers helping top him up and the rest of the team doing damage to take the boss down. In a Lean Startup world this would be starting off with a homepage and seeing who rocks up to the site and seeing what areas of interest they click on. For a very easy boss (or customer who has infinite time and interests) this might be a suitable strategy, but for a majority it will fail. What it will tell you though is some very basic information, potentially enough to start a new hypothesis.

You may have learnt that it will require another specialised “tank” role or that you need to reposition the team. In Lean Startup terms this would be a feature potentially being searched for very often but not implemented yet. This new hypothesis is then implemented. The team look at the results of their work. They use observation and actual data to determine where to improve and what to try next. Actual data for raids is obtained through tools such as combat logs and parsers that aggregate and display graphs of what is happening as the fight, or user experience across multiple customers for Lean Startups, is occurring.

For raiding teams it can take dozens of hypotheses before they defeat a boss. It takes a lot of analysing the data and re-execution of the fight in order to know whether you are on the right track or not. Teams may have a strategy built on multiple hypotheses that will consistently get the boss to 10 or 15% but never go past that amount. Ultimately they haven’t crossed the chasm. It is at this point in time that the team will need to pivot, drop their strategy and a large number of hypotheses and take a completely different tack. Only then is it possible to succeed. This is a very hard thing for a raid team to do. They have been pushing this set of hypotheses now for several hours. There is emotional attachment to the strategy. There is blame. There is tiredness. To change is hard when so much has been invested.

But if they do change, and they do succeed the rewards are sweet. There is a pride in having achieved the outcome and finally getting the hypotheses realised.

Interestingly raiding isn’t for everyone who games. The effort of having to work together as a team, of almost constantly being defeated, of looking at the metrics and not having a clue what tactic to take next – these are things that a lot of people just don’t have the guts for. They would rather sit on easy street and take on items that are immediately achievable, they don’t have an element of failure. That is fine, small risk reveals small rewards. For those that want to take risks there is the chance of bigger rewards.

Thinking you are suited to kickoff a Lean Startup? Maybe you should take on raiding within online multiple games and see whether you have the drive, committment and guts to keep failing before succeeding.

Read Full Post »

I wrote a little while ago about Gamification in Software Development and how it relates to Agile.Planning poker

Within that blog I said that I would get back to explaining Achievements more. And so here it is. Well, actually there it is.

When I originally started to write about Achievements and just how powerful they are in instrumental cultural change for Agile I realised that it wasn’t going to be short and wanted to promote it further. I asked Peter from Agile Scout if he was interested in publishing it and gratefully he said yes. Then as I wrote it I wanted for it to last longer in prosperity and consequently turned it into a whitepaper which you can download from the site.

And whilst we are on the topic of software and Gamification I recently found this thrilling TED talk (a few years old).

Read Full Post »


Get every new post delivered to your Inbox.

Join 920 other followers