Archive for the ‘Games’ Category

This blog is in response to a number of requests about creating Agile games. I have spent the last two years creating a number of Agile games and whilst I certainly wouldn’t declare myself and expert next to the amazing machinations of @lukehohmann of Gamestorming I do try to make games that are fun, educational, simple and easily repeatable.

In today’s blog I want to describe the journey and thought processes that I took to build a game that I call “Kanuzzle”.

It started about two years ago when Russell Healy first introduced Kanban to me through his amazing getKanban game. Russell spent considerable time, effort and personal expense to produce this high quality, repeatable instructor toolkit. I enjoyed the game and found it quite educational but did have difficulty with the setup time and the time it took to instruct on how to play the game. Taking that aside I felt the participants in the room were able to pickup the concepts embedded within and the competition levels were high which increased the fun factor of the game.

When I returned to Australia I tried to find some interest for Russell’s game but there was a perception that the game costs were too high (for an instructor to purchase). I was personally less concerned with this as I understood the investment Russell had made, but was more concerned about the maintainability of the game once purchased.

As time went on the needs that I had for a Kanban game grew away from getKanban. I needed a game that was less software focused and was easily digestible to business specialists who were using Kanban outside of software development. I also needed a game that was quicker to kickoff and one that could be maintained an enhanced. Production costs were an issue and management ideally wanted games that costed little more than paper and pens.

So given these new constraints I went about building a new game. To overcome the production cost issue the board I created was printed on A3 and laminated. Tokens and any other artifacts went through a similar production method. This resulted in kits that cost a little more than a few dollars. Additionally I wanted to build in more “chance” to the game and brought in a design concept directly off Monopoly  building in “wildcards”. When a wildcard was landed on it represented the real life occurrence of an event that was either positive or negative to the team’s ability to deliver. The set of board steps was also fixed as opposed to getKanban’s varying cost to deliver a story. Using colour themes similar to Monopoly’s “set of hotels” I had colours that represented a number of board steps for a particular non software role.

Teams were given preset WIP limits for their board which was setup to deliberately be dysfunctional. After a few two person practices, I released my new “Kanbanopoly” game for training. The first few sessions resulted in some instructional tweaks but overall the exercise went well – I cut the exercise time down from 2 hrs to a 45 minute game. The game was run in three rounds (split among theory). The first round was the dysfunctional one. The second round the team were able to change their WIP limits as they saw fit against an overall resource constraint, in the third round they could change the WIP limits again. Team’s rarely got the WIP limit right by the second go but always did by the third.

But a few things concerned me about this variant. Firstly it was still taking too long for people to understand the instructions, especially the Cummulative Flow Diagram. Secondly people were having trouble making the leap between the game and what they were doing on an Agile basis from day to day.

So I did what any good game designer needs to be open to and totally scrapped it. My new requirement was that the game be runable within 30 minutes with similar production costs and a five minute instruction time.

What I wanted was the ability to have a massive wall and for the team to stand at the wall to do the exercise, in this respect it would be more closely aligned to what they were used to. But the problem was that they couldn’t deliver software in the classroom and I didn’t want them to do a manufacturing based game as I wanted to highlight the knowledge work element strongly. So I toyed with the idea of a game within a game and created “Kadoku”, a Kanban Sudoku variant.

Children’s Sudoku puzzles (of varying difficulty) were printed and a value was attached to them. They were then cut up and placed on the wall with a pre-setup WIP limit. Roles were given out and metrics were kept. The WIP limits were setup for success but deliberate defects were put into the puzzles to force certain roles to hit their limit and cause a flow issue. The game went fairly well as far as the lessons learnt. The instruction time was certainly reduced and the costs were even lower. Additionally it felt more familiar and transposable to the participants. But there was a serious issue. Defects took too long to resolve and the Sudoku execution itself was taking longer than expected with each puzzle taking between 8-10 minutes to get out. Simpler puzzles took too short a time being doable in under one minute.

So that variant was re-adjusted. I scrapped the Sudoku puzzles due to their complexity and went with simple kids puzzles that should be achievable by 7-10 years olds. The game was renamed to “Kanuzzle” and re-run. This game has now been running for about eight training sessions without further issues and is now considered final. The cost is about 20 pieces of colour paper and blu-tack. The setup time is about fifteen minutes to cut out the puzzles, blu-tack them and setup the physical board. The instruction time is about 3 minutes and in game running time is about 15 minutes. The design intent from a learning perspective is to get a feel of the Kanban concepts with a particular focus on WIP limits, managing flow, pulling work and handling expedites. People won’t be experts by any stretch, but they will be informed enough to now give it a try and self-adjust.

So lets take a look now at the things that you need to consider when building your own Agile game:

  1. Who is the audience? What will they know? What won’t they know? What terms may be unfamiliar for them?
  2. How much time do they have to play a game?
  3. How much time do you have to run a game in the context of the rest of the training?
  4. How much time will it take for you to preset/reset the game? Is this something that you can afford?
  5. How much time will it take you to instruct in the game? Is this something that can fit into yours and your participants training time?
  6. How much time does the game and any post-retrospective debrief take? Is this something that you can fit into your and your participants training time?
  7. How much do the physical gaming materials cost? Are they re-usable?
  8. Is the game maintainable? Can you adjust it and re-run with adjustment costs being minimal?
  9. What key messages do you want to get across? What agile practice(s), principles or values are you trying to re-enforce?
  10. What would be nice to get across if you had time?
  11. Can participants easily relate this to their work?

Also keep in mind general game building considerations that all games should adhere to (for more information checkout my Gamification and Agile slideshow):

  1. There needs to be clear and defined goals or outcomes that have to be achieved
  2. There must be a set of rules in place to limit how you go about achieving that goal
  3. The environment must provide feedback to tell participants how they are going or whether the game is ended
  4. They must be voluntary

In the case of Kanuzzle the answers to these last four questions are:

  1. Achieve the most value. Two teams compete against each other. By default the puzzles are ordered according to sequence and not value, part of the design intent is to get them to spot that the backlog is not value prioritised and then to re-adjust it.
  2. Limits are enforced by WIP limits on the board and through rules for handling expedites and roles for the game. Roles are loosely set so ideally by the end of the game no one cares about their role, they are just focused on the flow. Additionally by forcing an error into the flow early it forces the team to deal with flow issues and understand what it feels like and the impacts that it has.
  3. Feedback is provided via timing each puzzle and through provision of graph tracking. Instructors also give feedback on game end time.
  4. They must want to learn and participate in training

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 »

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:

  1. There are clear and defined goals or outcomes that needed to be achieved.
  2. 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.
  3. 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.
  4. 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.

Read Full Post »

Game storming book review

Gamestorming, a playbook for innovators, rulebreakers and changemakers by Dave Gray, Sunni Brown and James Macanufo is a great composition of a number of games and techniques out there to reach collaborative and innovative outcomes; well worthy of a read for all Agile coaches.

The form, for the most part of the book, describes the game, the objective, number of players, duration of play, rules, the strategy for facilitating it and kudos to the originator of the game.

It wasn’t that every page for me was a gem, in fact there were probably only a handful of things that I felt I didn’t already know that I could take away and apply on a situational basis. But a handful of things – is a handful more than I had and for me that is still saying something. So lets take a look at the concepts and ideas that made me think:

  • Page 21: Every time I group a set of like themed post-it notes on a wall it actually has a term – ‘affinity mapping’, go figure.
  • Page 39: The airplane metaphor. This reminded me somewhat of the sailboat retrospective technique. The back of the plan is ‘where we come from’, the port holes ‘who do we deliver value to’, the propellers ‘what gives us the power’, the cockpit ‘how do we steer’ and the horizon or front of the plane is ‘where are we going’.
  • Page 65: Empathy map. I actually just appreciated being reminded about this fantastic idea from XPlane. Furthermore I had the fun opportunity to put it into action today which for the most part I felt worked well for the workshop I was in. Looking at the Anti-Problem (on page 80) made me wonder if these two techniques could be effectively applied to demonstrate a customer view/perspective that you want to avoid.
  • Page 113: Pie chart agendas. I hate writing agendas with a passion (the ultimate waste – documentation of a future waste event), but the option to demonstrate in a visual format how much time is being spent on particular activities is a creative approach that might have me doing them with a little more motivation. The full circle of the pie is the total time of the meeting, you basically slice it up into pie pieces of the time proportionately you will be taking for each topic.
  • Page 131: Trading card avatars. Used as an icebreaker this game has the added boon of also generating avatars for the story wall. Basically each person creates their own trading card with a hand drawn picture of themselves, their nickname and  little known facts.
  • Page 165: The Elevator Pitch. Not a new concept to me but a nice format structure – “For (target customer), who has (customer need), (product name) is a (market category) that (one key benefit). Unlike (competition), the product (unique differentiator).”

If you are new to facilitating, Agile coaching or Scrum Master then I would definitely recommend taking a look at this book.

Read Full Post »

The Car Change Game

Why is it so hard for software development groups to adopt a different approach or methodology? Why is it so hard for managers and leaders to transition out of the command and control mode?

Because we hate change.

This is a game that you can play at the beginning of a training session to allow people to open their minds that what they are about to learn isn’t easy. It is hard to change and they need to consciously go into the training that it isn’t just a matter of ‘change your way and you will succeed’.

To prepare this each participant needs the following (or have available on the table within reach):

  • two A4  pieces of paper
  • scissors
  • colour pens/crayons/pencils/whiteboard markers
  • voting cards (eg 1 to 10 or 1 to 5)

Show them a A4 piece of paper with the exercise template on it. An example of the template right here:

Exercise template

The exercise doesn’t have to be about a car, you can choose anything, but this is just an example.

Explain the following rules:

  1. With your A4 piece of paper draw a car for yourself. It should fill up at least half of the page.
  2. Your own car doesn’t have to look like the one above, you can be as creative as you like
  3. But… the headlights need to be coloured in yellow and the car needs to be coloured red.
  4. Once you have drawn and coloured in your car then use the scissors to cut it out.

Inform them that you will be timing how long it takes to do the car, but that it isn’t a race. When they are done put their hand up to signal end of time for them.

Let them start and start the timer. As each person signals write their time up on the board.

When the group has all finished their car do a quick demo of a few of the more interesting designs. Here is an example of my finished car:

Initial crafted car

Talk about the quality of the solutions, how closely the cuts are against the lines and the evenness of colouring in. Then ask the group to vote using their cards how comfortable they felt doing the exercise (for example 1 is extremely uncomfortable, 10 is extremely comfortable). Write up the comfort scores.

Now explain that the activity is going to be repeated again – but this time do not use the same hand that you used the first time. For example, if they are right-handed and used their right hand to draw and cut the first time this next time use their left hand.

This second car should be a duplicate of the one they created in the first instance. Explain that they will be timed again and start the exercise.

Write up the times again. Before walking through the results ask the group to use their voting cards and to rate how comfortable they felt doing the exercise this time. Write up the scores.

Now take a look at some of the designs and give a walk-through of the differences. For example, here is a comparison of my cars (the original is on the left):

Car Comparison

Using my own cars as an example here is what we can observe:

  • The sizing is vastly different. Scale and proportion are beyond what is probably tolerable.
  • The cut out is more jagged and nowhere near as close to the line.
  • The colouring in is less intense and has considerably more whitespace in it.

Then have a look at the time differences. The second car will likely be 50-100% longer to do despite having a template and no longer requiring innovation.

Then have a look at the comfort levels. They would have dropped but it is likely that there was still a lot of laughter in the room (until the scissors had to be used).

Get the group to consider what it would be like if you used the hand that you used for the second car every single day for the next three months and then attempted the exercise again. Ask them to re-vote what they think their comfort rating would be after the three months. Write this up.

Facilitate them through an introspection/reflection regarding what they have learnt about change. Common results will include the following:

  • Adopting a new change (be it methodology or leadership style) won’t be easy;
  • in fact it will feel very uncomfortable
  • but if we stick at it for a while then we will get better at it and consequently feel more comfortable.
  • It is highly likely that adopting this change will actually result in it taking longer to do things for a while
  • and that quality out output might also degrade
  • but bit by bit we will get faster and better until our results are comparable.
  • After that we might even start seeing some benefits of doing the change

Now that you have prepared the group with the frustrations they will receive by change it is a great opportunity to start asking the question “If it is so hard, then why should we change?”


Read Full Post »

Ideagoras. A beautiful word, but even more beautiful when you get to the substance of it. In Greece, 600BC an agora  was an open place of assembly where trade occurred. In today’s world trade is big business and the growing trend of this business is shifting to the Internet at break-neck speeds. The agora was the political heart of Athens. We cannot wholeheartedly say the same of the Internet today but opinion is debated and freely open for anyone on the internet with a decent download speed. 

Don Tapscott and Anthony D Williams first created the term ideagoras in Wikinomics to refer to the online idea marketplaces (amongst other terms such as Marketocracy and Prosumers) but don’t limit yourself to the internet on this and certainly don’t limit yourself to ideas. Think of it more in terms of crowd sourcing. When you consider Seth Godin’s work there are strong links.

Using ideagoras we can create better models of climate change or with the addition of gaming elements discover breakthroughs in genetics.  But what does this mean for the world of Agile?

For me ideagoras and crowdsourcing goes so much wider than the tantalising treats that Don gives us. Tied to Agile it is a beautiful model for decision making, swarming and must make us re-evaluate how we motivate, listen to and lead people in the business world. Let us take a quick look at how ideagoras can revolutionise an organisation.

Decision Making

Large organisations don’t just have a few or a dozen projects on the go. Commonly they have hundreds of projects on the go. Many are undercover and hidden from upper levels of magic, pet projects of their creators with little return on investment when you look under the covers. Lean Startups have sparked a resurgence in the importance of working on the right work not just doing the work right. They promote the concept of taking the idea and then testing the market with a mockup or prototype solution to first confirm that you are on the right track to get the most bang for your buck (my words not theirs). Using ideagoras we can take this to the next plateau. Rather than go out to the market with a mock-up or prototype first get the idea list filtered out through crowdscourcing. The idea in the first place should come through this mechanism. Have a feature on your website to be able to have your own customers add requests for improvements on the systems that you provide to them. Enable them to vote up (“like” or “+1″) the ideas that they would want to see implemented. Let your employees do the same using the same website. In this respect employee innovation can be recognised and encouraged by your own customers.

Now there are obviously down sides to this approach. Firstly, like most things in life it can be ‘gamed’ and there would need to be care taken to limit this, but there are a number of technological solutions to reduce this risk. Secondly, and probably most importantly these brilliant ideas are now exposed to your competition. The fastest implementor will be the one that wins the business. But this is not a bad thing – it is a great encouragement to ensure that we do follow through using Lean Startup principles to make sure we are on the right path and then Agile to rapidly develop the solution. A truly nimble and versatile organisation that focusses on rapid delivery, feedback and excellent customer relationships will be the winner in this future business war.

Think of the Fortune 500 companies – how many of them would stand up to the agility required to pull this off? Ten percent? Bureaucracy and red tape will drag them down and the small and medium businesses that can move quicker will continue to draw in the dissatisfied consumers.

Swarming and Motivation

If you have taken the first step to including your customer in your decision and idea generation process then you need to make sure you have the right team to follow through on the job. This is where swarming comes in. Most organisations throw their ‘resources’ about from project to project with little thought as to whether the person is actually interested and passionate about that type or project. Additionally they do it with little thought  of true speed and its relationship to return of investment.

In the future of speed to deliver innovation is going to the be determining winner for customers then swarming will become a natural reaction. You need to make that baby in one month. Governance processes will need to dramatically change to allow for this to occur. Estimation processes as well. We will need to be able to trust gut instincts on how hard it would be to fully deliver the idea and accept some failures of poor estimations. We will need have governance processes that kick off projects solely based upon votes received and the gut estimate. A safe to fail culture is critical here.

To resource the work we need passionate people who will focus on this idea like it truly is their newborn baby. To do this we can leverage ideagoras again. Employees interested in being part of this work should be able to sign up for it and be able to be immediately released to follow through on it. Potentially they could also be ‘socially approved’ as suitable for this role by their peers within the organisation. Again gaming of this would need to be careful.

Swarm the motivated people quickly onto the project to realise the benefit into the marketplace sooner.

Leadership and Customer Satisfaction Rating

What if the business world we lived in was like Survivor and you were able to vote someone off the island? 360 degree reviews  and anonymous employee satisfaction surveys are a very poor form of this. The better solution is to use ideagoras again to rate leaders. Let anyone rank or ‘rate’ anyone else in the organisation (again watch out for gaming the system). Do you think this would change Leader’s behaviour? Hell yes. Do you think they would be scared by this? Hell yes. There would be nowhere to hide. It would force many to leave. But think about it. Would the sort of person that you want to retain be threatened by this? No. Would the sort of person that won’t make it in this new age world be threatened by this? Yes. This is an amazing filtering system for getting the right culture.

Think of the scenario to yourself right now – think of all the bosses you have had over the years. If you pretended for a moment to be a CEO and have their resume’s on your desk how many of them would you hire? Which ones wouldn’t you hire?

No one knows better than the employees underneath a manager as to whether they are a good leader or not. Why not ask them to rate your leadership team?

Take it further. Take it to your customers. eBay has for an incredibly long time had the concept of rating the seller. A transparent feedback mechanism of trust from the consumer to the supplier. Sound familiar? Organisations that feel that they want to be leaders in customer service need to be able to demonstrate in a transparent, easy to access way their customer’s feedback. Social networking is improving this but organisations can help this along even further by enabling transparent feedback and visualising the comments (the good, the bad and the nasty) to everyone. Nothing will drive customer service better than knowing every single customer is freely given the right to publicly chastise or support you on your own website. I would love to see a feature added to Facebook that allowed you to rate an organisation’s service, ultimately providing a repository of this information outside of the organisation itself (for all those not courageous enough to do it themselves).


This is a wake up call. Large bureaucratic organisations I am talking to you. Without Agile, Lean, Lean Startups, Crowd Sourcing and other emerging frameworks you will fail. Now is the time to invest in yourself for the future. Inspect and Adapt. Listen to your customers and your employees not just your shareholders. Trust, respect and respond to your customers and your employees first and foremost. Your shareholders will as a consequence be happy because your organisation will be succeeding in a world when many are not.

Read Full Post »

Most people in the Agile community are now familiar with the Marshmallow Challenge where the primary purpose is a lesson in collaboration and communication (according to the website), but for me the key takeaway is the need to prototype and fail early.

In one of the post events in Agile Australia 2011 Thoughtworks took a different slant on the game and applied a twist of seeing what happened if you distributed it. Rixt Wiersma was the co-creator of the game and I was lucky enough to have a talk to her before and after the challenge.

Taking what was used in that event and then adapting it even further creatively I have an advanced version of this game whose sole purpose is to teach to distributed teams the impact on communication rules and outcome. The result of this is below.


Time required: 20 minutes actual game play, 10 mins setup/explanation time, 5-10 minutes debrief.

Participants: Six teams of preferably four, but can be scaled up. If you have less than 24 then reduce team B and then D.

Materials: In addition to the standard Marshmallow materials, a notepad with removable paper and a pen is required. Team E will require two working mobile phones.


  1. Read the standard Marshmallow rules. Additionally;
  2. Inform the teams that the point is not to learn about prototyping early, it’s about learning the impacts of distribution. As such they need to feel comfortable to use the Marshmallow early in the challenge.
  3. Teams A-E are split in half, the first half is called ‘Alpha’ and second half ‘Beta’. Change the names to cities if you want.
  4. Setup varying distribution limitations on communications:
  • Team A: No collaboration even at minute 0. Beta is removed from the room immediately. No crossover time allowed, no communication allowed on switch overs.
  • Team B: Alpha and Beta are invited to collaborate for the first 2 minutes and then Beta is asked to leave the room. No crossover time allowed, no communication allowed on switch overs.
  • Team C: Alpha and Beta are invited to collaborate for the first 2 minutes and then Beta is asked to leave the room. No crossover time allowed, communication on switch overs is allowed but only via notes.
  • Team D: Alpha and Beta are invited to collaborate for the first 2 minutes and then Beta is asked to leave the room. The teams are allowed to talk for 30 seconds at the beginning of switch overs.
  • Team E: Alpha and Beta are invited to collaborate for the first 2 minutes and then Beta asked to leave the room or move to the other side of the room. Alpha and Beta are allowed to observe the other team via other communication methods – this can be done either via a video/tv hookup or simply by letting them stand at a distance and listening in over a phone.
  • Team F: Alpha and Beta are never split.

Timings: Switch overs between Alpha and Beta happen at minutes 7, 12, and 17. At minute 17 the team being swapped out can observe the outcome of the last 3 minutes (in silence).

The crux: Introduce a requirement at minute 10 to not just have one point with the marshmallow on top but to have a second point at a similar height (ie two towers as part of a single structure). You might need to up the spaghetti sticks to allow this to happen from the norm.

Read Full Post »


Get every new post delivered to your Inbox.

Join 920 other followers