Agile Forest

The biggest failure mode of management today: Listening

Renee Troughton

May 23, 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:

Managers get better listening skills. Right now that you are done laughing, what are the other options.
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.
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.
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.
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?)
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?

Variability with resources and Agile

Renee Troughton

no comments

May 21, 2012

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:

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)
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 -)
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 – )
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.

Defeating raid bosses is like a Lean Startup

Renee Troughton

no comments

May 10, 2012

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.

Gamification Wrap Up in Agile

Renee Troughton

no comments

May 2, 2012

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

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).

Moneyball quotes

Renee Troughton

no comments

April 26, 2012

Moneyball has been credited within the Lean Startup community as a classic example of some of their principles.

I thought for those who haven’t had an opportunity to watch it that I would note some of the more powerful statements made in the movie. Some are slightly modified to apply outside of baseball so that you can potentially better relate it to your own environment:

The first guy through the wall always gets bloody.

This is threatening not just their business, this is threatening their livelihood. It’s threatening their jobs, it’s threatening the way that they do things.
And every time that happens, whether it is a government, or the way they do their business, or whatever it is, the people that are holding the reigns – their hands on the switch, they go bat shit crazy.

Anyone that’s not changing – they’re dinosaurs.

There is an epidemic failure in the system to understand what is really happening. This leads people who run their teams to mis-manage their teams.

They are asking all the wrong questions. If I say it to someone I am ostracized. I’m a leper.

Product development is not the same as software development

Renee Troughton

no comments

April 25, 2012

There is a growing trend within the Scrum community that believe when they are doing software development that it is actually product development. This is not the case. Software development is subset of work that is needed to be done to support product development.

In small organizations the deviation between software and product development might be small but the greater in magnitude an organization, generally gets the wider the difference gets.

Scrum believes that you must have a cross-functional team that can get the Story/Task to “done”. Commonly this means that the team has the skills to be able to start the card with a meaningful conversation, develop it, test it, and deploy it. Often this results in Storywalls/Taskboards having headings like “Sprint Backlog”, “Analyse”, “Build”, “Test”, “Done”.

But what a lot of teams forget is that the software is only a smaller part of the organizational whole. Lets take a look other non-software components that are often involved in large scale product development:

Legal
Sign-off of publicly exposed content to ensure that the organization is not opening itself up to liability; xtra-product only
Marketing & Sales
Promotions of campaigns related to the product; xtra-product only
Training
How users will use the product to perform their job; more commonly intra-product only
Communication/Change Management
How impacted stakeholders and users of the product will be informed of what is happening with the product development and rollout; more commonly intra-product only

xtra-product denotes a product that is sold to the public; intra-product denotes a product that is internally used within the organization

It is for this reason that I think Scrum’s label “Product Owner” is poorly named, or maybe more importantly has two few responsibilities associated with it. How many Product Owners have you met that have also taken on either the work listed above or the co-ordination of the above effort. They should. But if they did that and their standard Scrum duties they would be severely overburdened.

The cost of these extra activities are often just as large as the software development itself. Sometimes more, especially for COTS/Software as a Service implementations. Do you have Stories or Tasks in your Release Backlog for these activities? Why not? They have to be done and if are not aligned with the work that the software team are delivering then you are potentially opening yourself up to benefits realization risk. It’s all well and good to have the software on time, but if the change team haven’t been kept in the loop regarding when you plan on delivering minimal marketable features then they might be communicating that you are delivering them earlier than expected. Sometimes the success or failure of a product is never down to the software itself but how it was communicated and “sold to” someone; or how well they were trained in it.

How do you know that these other components are on track? Shouldn’t their work related to the product be fully visible and flow through from Sprint to Sprint?

If your product requires any of the above think about how you can incorporate them more into your environment and more importantly into your flow. Should the story/task be “done” if it hasn’t passed through these flow states. It doesn’t have to mean that every single story or task has to go to legal or through to training but it is a trigger – “will the training material need to be updated to reflect these changes?” If not, move it to done, otherwise wait until the necessary changes have been made before shifting it to done.

Value, growth AND revenue hypotheses in Lean Startup

Renee Troughton

10 comments

April 17, 2012

I have just finished reading “The Lean Startup” by Eric Ries for the second time and have been spending some time working with a team using the model. Joyfully it has made me think about opportunities out there and if I ever had my own push to be entrepreneurial what exactly I would consider.

As part of considering what sort of Lean Startup I would consider I wrote my ramblings down and then noticed that I felt something missing.

I would formulate the idea using the Gaddie Pitch:

You know how most…{existing commercial environment}?

Well what {Lean Startup idea} does is {how it breaks the mould from a value proposition perspective}.

In fact, {more value proposition information}/{recent success}

As I fleshed out the ideas further I considered the depths of what their value hypotheses and growth hypotheses were.

But it was missing something.

I wanted to know how the Startup idea also would create revenue for the business. After all, commercially, what good is a product if it has thousands of happy customers, a high and continual increase in customers but no means to make any revenue?

Eric Ries defines a value hypothesis as

Tests whether a product or service really delivers value to customers once they are using it.

and a growth hypothesis as

Tests how new customers will discover a product or service.

But what about the hypothesis that you will actually make money? Surely this is something that needs to be tested too.

Organisations are growing the Generation Y mindset

Renee Troughton

10 comments

April 13, 2012

I have been pondering since reading Steve Denning’s on Fighting the Kool-Aid of Stock Based Compensation and Umair Haque’s Harvard Business Review’s The Economic Roots of your Life Crisis about perilous journey that we might be on. Take a step back for a moment and consider some cause and effect.

When my parents worked it was pretty much considered a job for life. Most of my friends around the same age had similar experiences for their parents.

When I entered the permanent workforce in 1997 this mentality was beginning to peter out. Big organisation after big organisations that I worked for all went through regular retrenchment periods. Some were as short as every six months, others in two yearly cycles.

They called them different names – offshoring, outsourcing, departmental restructure, voluntary reduced hours; but the intent was always the same – cut the bottom line.

Thankfully I have never been directly impacted by such acts but it has led me to a feeling of constant insecurity. I have never felt safe in a job.

Does anyone else think that this is crazy? What is the point of ever being a permanent employee if you cannot feel safe (naturally excluding performance issues)? At least a contractor knows when their date is going to end. The rest of us that were after secure jobs to pay our mortgages and support our tribe of kids wanted something that we could depend upon. But we cannot depend upon it. We are like a character of “In Time“, our clock is ticking down, but we have no idea when the timer is going to reach zero.

Because of my parent’s experiences within companies I was raised with the belief “You look after your company because your company will look after you.” Extra hours was sometimes part of that deal. Towing the company line as well. But what I was experiencing was something considerably different. It didn’t appear like the organisations cared about its most long term employees (they were commonly the first ones to go). It shattered my illusions. It left a void in my belief system.

I am not the only Generation X person who has been left feeling like they are in the Matrix. Companies no longer care about their people, they care about the almighty shareholder seemingly above and beyond any other competing priorities.

So as anyone with a dysfunctional belief system does, they find a new belief to fulfill this empty hole. We believe that if the company doesn’t care about us then we need to care about ourselves. What behaviours and patterns emerge from this?

We appear selfish. It is all about what we can get right now. We want recognition right now. We don’t feel obliged to have to stay at an organisation for too long (especially if the organisation loves to retrench frequently). We see no problem with being headhunted. We see no problem with doing the work for the hours that we are meant to be paid and no more. This makes us look lazy.

Does this sound familiar? Take a look at the wikipedia definition of a Generation Y:

Studies predict that Generation Y will switch jobs frequently, holding far more than Generation X due to their great expectations.^[70]The UK’s Institute of Leadership & Management researched the gap in understanding between Generation Y recruits and their managers in collaboration with Ashridge Business School.^[71] The findings included high expectations for advancement, salary and for a coaching relationship with their manager.

Is this singularly minded focus on shareholder value turning us all into Generation Y thinkers?

Gamification in Software Development and Agile

Renee Troughton

6 comments

April 5, 2012

When people think of the term ‘gamer’ it engenders ideas of pasty white teenagers living their days in a zombie like state in the basement of their parents house spending over forty hours a week with their eyes glued to the pixels on their screen smashing keys on their keyboard. Despite this stereotype, 72% of American households have at least one digital gamer in their family (up by 5% from 2010) and with the introduction of small games on the iPhone and iPad and through social mediums such as Facebook, the digital gaming door has been re-opened to a whole new audience. Growth of the gaming industry is only expected to rise.

Most of us have actually been gaming ever since we played our first board game, at an age when we didn’t know how to read or write. In our early teens we turned to a different form of game, the physical version, sports. In our adult life we have been playing an entirely different and often less motivating game, the political and strategic game, work. If you add up all the time playing the ‘work game’, the ‘sports game’ and the digital games on our PCs, smart devices and consoles we are all spending a good portion of our life playing games, some engaging and fun, others less so.

Is work a game?

There are four clear conditions that determine whether an activity is a game or not:

There are clear and defined goals or outcomes that needed to be achieved.
There are set rules in place to limit how you can go about achieving the goal. By limiting obvious approaches to receiving the goal you are forced to think creatively or strategically.
They must provide feedback telling us how we were progressing or when the game is over. Even if we lost they provide us with feedback so that we knew how close we got so that we are further motivated to get there.
They must be voluntary. No one forced us to play them.

How board games, digital games and even sports fits against these four conditions is quite easy to see. But to see how work fits against these criteria can be a push. No one forces us to work and yet many of us aren’t motivated to the same degree of digital games. Is it because our hour to hour, day to day activities at work poorly fit against these gaming conditions? We go to work voluntarily but commonly the reasoning is ‘to get paid’ or ‘to pay for the mortgage’. It is a fiscal or consumerism motivation that forces up to get out of bed and begrudgingly go off to work? Everyone knows that you should do a job you love but with 70% of American works under engaged or actively dis-engaged it is suggestive that many of us are only there for the pay packet and not because we love it. This is not a simple problem, this is an epidemic.

At work we will usually have goals but they are set at the start of the financial year and they span twelve months. Consider a game where you get given a set of ‘quests’ or objectives once a year, I doubt it would be the type of game you would be interested in.

Feedback on our successes or otherwise is similarly as poorly done at work as it is for the setting of goals. Performance reviews are at worst never done, on average done half yearly and at best quarterly.

Imagine playing a digital game whereby you get recognition of achievement once a year – no one would play it.

The rules at our workplace are ill defined and often built into the culture and the political environment. Jane McGonigal writes in an excellent book on gaming and its relationship to business and life that “Reality is broken”. She believes it so strongly that she named the book after the belief stating that people are flocking to games because the reality that we live in day to day is not sustaining and motivating us to the same extent as digital games. “Compared to games,” she says, “reality is too easy. Games challenge us with voluntary obstacles and help us put our personal strength to better use.”

It isn’t that reality is too easy. It is that the rules are not fixed or that the goals are unachievable against a shifting landscape. Imagine playing a game where when you pressed a button you weren’t quite sure whether the cause and effect were stable. You would press the letter ‘1’ expecting to swing a sword in a fantasy role playing game, for example, and instead would jump in the air. The next time you hit ‘1’ you would wrap a bandage on your arm. We need a world that is stable and consistent, where the rules are known, clear and unchanging, a world where we can win.

How does this apply to software development?

This depends on the framework and approach that you take to craft and deliver your software. As a framework, Agile allows for the greatest support against these gaming conditions. Agile at it’s utter core is a reflective improvement framework. At frequent, regular and defined intervals you inspect and adapt two things – your software and your software delivery process. All of the Agile methods provide a mechanism to reflect, inspect and adapt – in Scrum it is done daily through Burn Down Charts and across iterations through Burn Up Charts, in Kanban it is through Cumulative Flow Diagrams and in eXtreme Programming software craftsmanship is gauged through tools such as code coverage, test case coverage and build statistics. Additionally these methods and ones such as Feature Driven Development inspect the process frequently using techniques such as retrospectives or deltas. Actual output of work is discussed and inspected through Daily Stand-ups, automated testing and end user acceptance testing as each story is rapidly released.

When using an Agile method such as Scrum, work will be broken into commonly two week iterations or sprints. At the start of these iterations there is a clear expectation set of which elements of the software need to be delivered through the stories that are pulled into the iteration. We know that this expectation should be achievable because the amount that was pulled in was derived based upon our previous delivery rate, or in Agile terms, the planned velocity is set to the average velocity achieved of the last three iterations (or simply just the last one). In this respect Scrum highly supports the gaming condition of clear and defined goals or outcomes that need to be achieved, but for other Agile methods it is more of a stretch. In Kanban, for example, the goal moves away from story completion and more towards reducing the time that it takes on average to get a story through the end to end lifecycle of define, design, build, test and deploy.

The rules that are in place for software development are very interesting. Within Scrum some of these rules are in place, in fact Jeff Sutherland and Ken Schwaber define a simile between chess rules and Scrum. The strong rule that an iteration is a fixed time container that should not be disturbed is a very important and key rule, one that should be considered a limitation imposed, and for good reason as it’s intent is to provide a safe, unchanging environment even if it is for only a few weeks. Kanban also has rules that are imposed beyond normal software delivery such as limiting work in progress and allowing change through only one (expedite) at a time.

You could say that a Waterfall development method or process also has goals, rules and feedback but it’s cycles are too long to be considered engaging – the average gamer would be turned off by it’s lack of real time responsiveness.

Whilst all Agile methods will likely have rules, goals and feedback approaches it is the rapidity and formal regularity of these practices that will always create more engaged developers because of the fact that Agile as a method aligns more often with gaming conditions.

Regardless of the Agile method or even software development approach that you choose to use to develop with – all of them are falling pretty behind on a few aspects of the game conditions. Firstly none of them are truly voluntary. Yes you voluntarily do your job but the story or the task that you pick up isn’t chosen by you, nor is the project that you are working on – most developers are assigned to the project. Secondly the rules of politcal culture within the organization are poorly considered. Despite working inside of a container or having some rules in place to handle change – person or process introduced interference will always impede to some extent. Things won’t always go to plan and then more rules are put in place to handle this. Organizational ‘value’ statements, social contracts and Lean’s relentless focus on removing roadblocks are good examples of techniques and methods being applied to resolve this gap.

Can more be done to apply game conditions to the art of software development?

Yes, a lot more. From the way in which we train people, to the way in which we re-enforce desired behaviors or practice compliance we can use gamification techniques more. Gamification is the techniques and mechanics used to solve and engage people through game-like conditions or environment.

The easiest, simplest and most fun gamification technique that you can add are achievements (more on this soon in a future post).

Gamifying the software that you are developing

Along with gamifying the way in which we are working as team we can also keep in the forefront of every software developers, business analyst and product owner’s mind the question “How can I build a product that not only meets the needs the business’ outcomes but also enables the customer to feel like they are playing a game, that there is fun and a sense of achievement built in?”

The marketplace is growing quickly with internet applications that are taking in elements of gaming such as social networking, team-based cooperative play, strategy, role playing, achievements or competitive score boarding. One great example includes Red Critter Tracker which allows you to manage your business’s projects within an in built organizational and project social network engine, achievements and reward. Another great example is Rypple, a people performance management tool, which enables a similar set of gaming features as Red Critter Tracker but focuses more on the person than the project.

It isn’t just the small-medium or start-up companies that are looking into this. Big organizations such as SAP are trying to enter the foray by literally trying to build games into the software.

Authors Note: This article was originally published in the Software Developer’s Journal in January 2012.

Scrum evolution over time: Part 5 – What’s missing?

Renee Troughton

2 comments

March 24, 2012

Over the weeks we have had considerable deep dives into Scrum and how it has evolved over the last ten years. The first week we looked it at a high level, then we had a look at the roles, ceremonies and artifacts.

Now we have the opportunity to see how it has not evolved. It is important to note that Scrum is a Project Management Method (purists might argue it is a framework). It is not, nor has it ever said it was a methodology. Nor has never said it was a method for improving the capabilities of software developers.

It was created and in use prior to the name “Agile” ever being associated with it. It was one of the many “light-weight” methods that were contending for attention away from Waterfall. When Jeff Sutherland, Ken Schwaber and Mike Beedle joined fourteen other signatories in Salt Lake City there was little that they could agree with other than the manifesto. Despite this, the manifesto propelled the light-weight methods into the limelight and was a vocal enabler for a new future.

Some IT people have never experienced Waterfall or even RUP. They don’t know what it was like in the old days. Maybe the problems were due to commercial issues rather than method issues, but even with all the hoopla over Agile or Scrum not working or dead I remember what it was like in those days and we are certainly better off for those signatories creating the manifesto and propelling our focus.

But like Waterfall not being a comprehensive methodology Scrum certainly is not. This means that when people are trying to apply Scrum they are only applying a single piece of the puzzle. Many believe that Scrum = Agile. Those that know better are left in a minefield of information overload having to gleam which other methods they need to apply and how it will correlate with their existing process. In essence, Agile is like a toolbox. There are many tools that you need to use to fix the problems you have. Some tools won’t be the right tools for your problem. Arguably if you have no problems then don’t use any tools… as long as you aren’t fighting Ostrich syndrome.

Scrum has just a few of these tools. Over the last ten years it is evolved minutely to the problems and the new tools that are required in our box. Evolution did include the addition of retrospectives, intellectual property that was owned elsewhere. Even the origin of Daily Stand-ups was IP from elsewhere. Nothing is new, concepts are just re-played and re-packaged. Some might argue that the reason Scrum did not evolve was primarily due to IP concerns. But maybe, if the upper echalon of Scrum had listened to the voices of the community they would have had the opportunity to incorporate these new ideas and thoughts.

So what has evolved in the Agile community over the last ten years that Scrum has ignored:

How to apply Scrum to teams that have multiple customers that additionally have to support (ie potentially hotfix) production environments
How to identify constraints in the flow of the system
How to ensure that the work the Product Owner comes up with is the right work
How to incorporate feedback loops in order to verify benefits realisation
Stories, Epics, MMFs, MVPs, Themes, Parking Lots/Feature Progress Charts, BDD
How to estimate (eg planning poker)
How to understand what is more important – scope, cost, time or quality? eg Rob Thomsett’s Success Sliders
How to create a backlog in the first place
Who has the money and what visibility should they have?
Mastery practices, arguably owned by XP, eg pair programming, TDD, Continuous Integration; or even simply where design and architecture fits in
Where management, leaders, Project Managers and Business Analysts fit in
Where business cases, governance, procurement and commercial reality fits in
What tools to use to support the cultural change that goes along with implementing Scrum
How to create effective walls and other visualisation techniques
How to deal with the distribution problem (this is huge and only going to get worse)
How to apply it to anything other than software development
How to scale it to large organisations where team members are working on multiple projects at once or significant dependencies exist
How to get any form of metrics on effectiveness of the change including temperature checks of people’s comfort levels of the change
Incorporating all elements of the project and not just thinking of software development only – ie communications, training, process re-engineering

Maybe I am just asking too much. Methodologies seem to be dead, disparate ideas spread everywhere seem to be the norm. If complex systems are so hard why are we making it harder as a community to find the answers?