I am currently in progress of writing my first Agile book. It is basically a beginners Agile book targeted outside of the software development industry with a major twist.
If you would like to participate as a reviewer can you please contact me via twitter with an @AgileRenee mention and then I will send you a direct message to get your email address (if I am not already following you, otherwise just DM me). Alternatively you can email me at renee@theagilerevolution.com
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:
Also keep in mind general game building considerations that all games should adhere to (for more information checkout my Gamification and Agile slideshow):
In the case of Kanuzzle the answers to these last four questions are:
As part of my back to basics series I wanted to spend some time on the topic of Retrospectives, otherwise known as Introspection or Reflective Improvement sessions.
If the Stand-up is the bread, then the Retrospective is the butter. It is simply just one of the most fundamental elements of doing/being Agile there is. Alike Stand-ups, they are just as easy to be ineffective.
At its most basic process this is how to run a retrospective:
Let’s break these items down a bit more:
Get the core team together
It doesn’t have to be in a meeting room. It can be in the pub or in a park. In fact, the team don’t even physically have to be together – you can do retrospectives virtually using a tool like LinoIt. What is important here is that the team needs to feel safe to speak freely and that there is an environment where there are no elephants on the room. If you have a Project Manager or a Product Owner that will not be conducive to such an environment then you have a bigger problem here – re-focus the retro on getting this fixed!
Brainstorm for 10 mintues
There are five points I want to make on this sub-activity:
Group like thoughts together (affinity mapping)
Notice that I didn’t say how to do this? That is because your mileage may vary based upon your approach. The Scrum Master can do this once everyone has written their thoughts, or the core team can do it themselves – either one at a time or as a collective. You can read them out or get the team to quietly read it themselves, the options are really endless. My personal preference is to get the core team to affinity map themselves and then to verbally skim through the non grouped items and spend more time on the strongly grouped themes. Items under “What still puzzles us” should be answerable on the spot or may become a focus area.
Choose items to focus on and address
Usually I would choose the strongly grouped themes but there is a risk that you miss something important that can significantly improve your ability to deliver as a team. What is important is that the items you choose to focus on are the ones that will result in marked improvements for how the team will work together.
It is a rookie error to focus on ten things within a single retrospective. If you have two weekly Sprints, you ideally don’t want to focus on any thing more than three (five at absolute tops) actions. This is because you want to ensure that you are making changes and if you have too many actions then nothing will change and then you will loose all support from the team for doing this practice in the future.
Who makes the suggestions of the changes? The core team does. It shouldn’t be the Scrum Master who is imposing change on the team, it should be the team embracing an environment of continuous evolutionary improvement.
Make actions
So along with only having three actions you want to ensure that these actions address the root cause of the problem (ie you are not solving the wrong problem), that the actions have clear owners, dates (if possible) and value.
The best actions I have ever seen out of a retrospective are ones that the team writes as stories and then feeds the stories back into the release or sprint backlog – ie they get treated like everything else. Because they are treated like everything else they get a priority and estimate which means that they have to have value as agreed by the whole team in order to work on them in the current Sprint.
If you aren’t going to write them up as stories and add them to your backlog(s) then make sure the first step you do in your subsequent retrospectives is to review previous actions. It is a smell when actions get carried over from retrospective to retrospective – it is symptomatic of items that weren’t perceived as important or that the team feel that continuous improvement is not important.
Conclusion
Software development isn’t simple. The only way that we can improve in the complexity that we are working with on a day to day basis is the reflect and adapt. Sprint Planning and Sprint Reviews are the way in which we reflect and adapt the work we are doing. Retrospectives are the way we reflect and adapt how we are doing our work.
Can them what you will – Daily Scrum, a Huddle or a Stand-up, but whatever you call it a Stand-up is one of the simplest Agile (and arguably knowledge and service management) practices out there. Three questions are answered by the “core team”:
Simple right? Wrong!
These very simplistic set of steps have led many to believe that the key purpose of a Stand-up is as a progress report. To set the record straight:
The key purpose of a Stand-up is the opportunity to collaborate, share and support each other in the delivery of valuable outcomes.
For those that may not have heard of the above interpretation of a Stand-up’s purpose then let’s take the opportunity to understand it further. As each person answers the three questions what the rest of the team should be doing is listening and wondering to themselves the following questions:
If the answer is ‘Yes!’ to any of these questions then the team member should pipe up and respond. An effective Stand-up isn’t just the team turning up on time and answering the three questions – it is where teams work together to deliver and reach the delivery goals whilst always upholding the values and principles.
Another common Stand-up myth is that they should be 100% valuable to 100% of the core team 100% of the time. This is simply not the case. As we now understand what an effective Stand-up is you will be lucky to find these opportunities consistently and rarely more than three times in a single Stand-up. In fact, you might go through a few Stand-ups before such an opportunity arises – these uncommon instances of “I’d love to learn more about how to do that, care we pair?”, or “I’ve had a similar problem on my last project let me send through to you what we did”, or “I know that person well, let me talk to them and try to push the impediment out” are what make good Stand-ups.
We’ve all heard of tips like taking difficult conversations offline, ensuring everyone can be heard and timeboxing each person to no more than 2 minutes but here are a few tips that I would additionally recommend to make Stand-ups a little more effective:
Note: Astute Agilistas will notice the subtle changes in the core three questions. Primarily this is because I have seen effective Stand-ups that whilst they are regular and frequent shift away from the activity being daily. Additionally I like to tack on the “or may soon” to the last question because whilst the question focuses on issues the “may soon” is a focus on possible risks.
Jvonvoss at Minds.coremedia.com recently did a very interesting blog – A World without Burndowns: The Unified Taskboard. It was an interesting concept – use your done column to replace your burn down chart.
Normally a taskboard will look like this:
The done column is just a list of everything that the team has achieved. Colour may be used to denote expedites.
Using Jvonvoss’s advice a standard Iteration Wall would have the Done column split into each day of the Sprint:
In this example, whilst on day 9 we know with certainty that we wont get through all the cards within the next two days as we have been consistently achieving 2 cards per day.
In the above example knowing whether we would finish all the cards by the end of the Sprint would be harder to work out – but the interesting reason is why. We can very easily see that the daily throughput is spiking up and down a lot. There is a constraint in the system. You would likely be able to see this as well in a Burn Down chart but visually this would pop more for visitors or managers that walk by.
Using Kanban, similar concepts of visualisation within the Done column can be used to track cycle time. In the example above we can see some outliers, but a majority of the cards are being done within three days and expedites are getting done on the same day. Again this won’t necessarily replace other graphs but the transparency is more apparent.
Lastly, how could you use a wall to track demand over time within the service industry? Cafes commonly print orders on dockets and add them to a backlog of beverages to produce. As the Barista becomes available they take the next priority item in the backlog and begins working on this. Imagine that when done putting the docket up on the wall by the hour that it came through – what would this enable a cafe owner to do? You can see from the above image that the peak time is 8-9 – you would make sure the majority of staff were on at this time, between 12 and 2 you would likely rotate lunch breaks and you might choose to close down earlier than 6 given how few the orders are in that time slot.
What other ways could you think of using the Done column?
When I mentioned to some community friends that I was going to be reading Steve Denning’s Radical Management book a number of them looked at me as if I had contracted some form of virus. “Why would you read a dumbed down book on Scrum?” they said.
The answer for me was simple –
Within this book review I won’t be comparing this book to the other two (although I might do then when I review those), instead I want to focus on my thoughts as I read the book.
Firstly, focusing on my third point above I was not disappointed. For the most part I did continue to enjoy Steve’s writing style in this book. Most pages I felt engaged in and whilst the pages didn’t all fly by, certainly up to the end of Chapter 9 they did (from there it does drag on a little).
Secondly, for a manager that has absolutely zero understanding of Agile and has focused for most of their management tenure on traditional command and control methods, either intentionally or not, I feel that this is an excellent book… to start them on the mental journey.
Which brings me into my third point. It tries to give a practical angle of applying it but I couldn’t in all honesty give this book to a Manager and expect them to be able to do the practices effectively. In fact, in a number of instances there is no detail on how to do a practice. So what this book does really well is get Managers to begin to question what they do and how they do it, less so actually enact change. This could be perceived as quite a concern for many but I don’t think it is that big of a deal – the difficulty is in the mindset change and this book does address well why you would want to shift from being a traditional manager to a radical manager. Additionally the book is riddled with references so if you did read this book and wanted to find more than there are a huge number of useful references at the back.
Now for the negative bits (which I don’t feel outweigh the positive):
So it might be early days to know what book to give to a Manager to learn Agile (even if this was not the intent of this book and it’s intent was to be wider in focus), but overall I would give it a 7/10.
I have been pondering lately what the purpose of a Scrum Master or Iteration Manager is.
Many believe that it is a 100% full time role. Some are even concerned that there are formal positions springing up for this role.
Here is my stance (and work in progress model) on the role:
The purpose of the Scrum Master role is to create a self autonomous team through the usage of Agile.
So what, you may ask, does a Scrum Master do as their time with the team whittles down? They do what any good team member in a Scrum team should do – they deliver User Stories!
Last week Assembla posted the 7 things they hate about Agile. Here is my take on their seven things I hate about people that hate Agile:
1) My cultural norms are not your cultural norms
Apparently according to Assembla everyone that does Agile is old. Damn I have been doing Agile since I was 27. Apparently that means I am old. I hate that cultural norms are flouted as if they apply worldwide. In the southern hemisphere those following Agile are more likely to be under 40 than over 40.
2) see point 1
Assembla says that Agile is stagnated. Again, just because it has in your country doesn’t mean it is a worldwide norm (see last blog). I agree there is a risk that people want to do and not be Agile, but that has nothing to do with stagnation. I have argued many times on this blog that Scrum is stagnant, I won’t dispute that, but Agile !=Scrum. What Assembla is ultimately saying is that people aren’t learning of other approaches other than Scrum. Is it because they don’t want to, because they see little value in anything else or is it ignorance? I don’t know the answer, maybe Assembla does. When I think of this point it makes me ponder on why we replaced Waterfall with Agile in the first place – was it not because Waterfall failed to evolve and address the problem we were having. Where is it written that Agile must or cannot evolve? We are the community. We are the ones that encourage it’s evolution or not.
3) People that don’t value values
Assembla says that the values in the manifesto aren’t applicable. The examples that they provided were all of manufacturing or command and control environments. Last time I looked Agile was being used for knowledge work not manufacturing. Also Agile methods were used in WWII – in war rooms – where knowledge and innovation were critical. I agree that shared goals are important. I agree that if you can deliver your work and not have to talk to a single person (or even a customer) then values are not important, but I don’t know of anyone in software development that can get away with that excuse these days. You have to have values and goals when doing knowledge work. I am not saying the manifesto is perfect, hell I am enjoying the MoreAgile manifesto these days, but that doesn’t mean all values are useless.
4) People who don’t understand how complex it is to change command and control behavioural patterns
Assembla says that they hate the Scrum Master role and believe that SMs don’t do anything and need to get a real job. As someone that spends a lot of their time trying to re-wire behaviour away from command and control to enable environments where teams are empowered and autonomous I find this frankly insulting. We are taught to respect elders as children, to not talk back to authoritarian figures. Throughout our childhood and schooling we are constantly re-enforced with command and control messaging. And yet we know through many studies that empowered and autonomous teams are more productive and innovative. The Scrum Master is there to break down the old patterns and enable the team to do their job without interruptions. This isn’t something that happens overnight, it takes months of re-enforcement for neurological pathways to re-assert themselves to be the prime pathway. Does this mean that a Scrum Master role is full time – no! They will be helping to deliver when they have free time. They are just a normal in the person in the team who has chosen to step up.
5) People who think that Agile means you have to estimate/People who think that Agile means you don’t have to estimate
Assembla says… actually I am not sure if they are for or against estimating from their comments. Estimation really depends on the environment that you are in, the governance and financial models applied to get work started. Ideally work would be incrementally funded. Ideally all work would be broken down into roughly the same size. In this ideal Agile world estimation is not required (assuming you understand your cycle time or throughput of work items over a defined duration). If you don’t live in this ideal world you might need to estimate – at best a rough idea of the size of the project based upon relativity to other similar sized projects, at worst so you know your velocity if using Iterations.
6) People who assume a practice is 100% applicable 100% of the time and that common sense has no place
Assembla says that pairing all the time is not valuable and just to pair reviews. For me pairing for reviews is worst case scenario, it is a lag identification of problems. Would I recommend pairing all of the time – hell no! But if it was complicated business logic or a new architectural framework being implemented then I would recommend upfront pairing. Pairing is about quality, reducing rework, cross skilling and engagement.
7) People that think just because it is hard that you shouldn’t strive for it
Assembla goes into some points about Scrum and it’s poorly formed ideas. The first is about co-location. I am not sure exactly what problem Assembla has with being in a work environment that is fun (what people don’t enjoy an odd game of Foosball?!?). I agree that co-location is much harder to do these days, but does that mean you shouldn’t strive for it? There are mixed benefits in this field – co-location provides reduced costs to communication (Thomas Allen curve), but conversely co-location decreases engagement (by 0.2% assuming you are instead working from home, still the figure is fairly negligible).
The second point Assembla makes on this is that cross functional teams are unachievable. In large organisations maybe, smaller ones less so, it depends on your environment. Again it doesn’t mean you shouldn’t strive for it. A cross functional team in the long term is more productive. The purpose of a cross functional team isn’t to reserve talent (where did that one come from?).
The third point Assembla makes is in regards to capacity changing weekly. Discipline is hard. Yes unplanned things happen but onboarding/offboarding project team members every week is a severely dysfunctional Agile team and if this is the norm your organisation has serious problems regardless of Agile. This is why most Agile environments are shifting to product rather than project teams – that way the capacity and capability is always there.
The fourth point Assembla makes is that bugs will come up as you work and these impact your ability to deliver to a plan. Again discipline is hard. If you choose to use iterations, then understand your metrics of how much this is impacting you and add it into your planning process. Alternatively use an iterationless method and allow production defects to be handled as expedites. Or even better build quality in and don’t get bugs in production.
Conclusion
If Assembla is changing its developers every week, has bugs as a frequent occurrence found within production environments (hinting at lack of automated testing coverage and quality testing), has developers incapable of widening their capabilities, teams that are stagnant, old, without values and breathing each day in an innovationless command and control environment I am really not sure that I would give them my business.
And Assembla – if your response to this conclusion is “we don’t use Agile” then I’ll add my #8 hate:
8) People that hate on Agile who don’t even do it.
This is a back to basics post driven from a number of interesting conversations I have had recently.
Firstly here is my personal definition of Agile:
An umbrella term for the toolbox of light-weight methods, practices and techniques that are focused on working smarter, not harder.
So let’s break that quote down.
“An umbrella term” means to me that it is encompassing, or arching loosely over something.
“toolbox” suggests that there are tools within it. Like all good tradies (that’s Australian for tradespeople) they know which is the right tool to apply to the right problem. You won’t use a hammer to tighten up a screw.
“light-weight” I debated whether to use this in the definition or not – primarily because to some extent I believe that Agile requires greater disciple than ever before, then again, you can still be disciplined and have simple tools in your box.
“methods, practices and techniques” Most believe that Agile is just either Scrum or FDD or XP, but you are rarely ever using just one method (or model) by itself and in reality you are likely to pick and choose the methods, models, practices and techniques that apply to both your organisation’s culture, to the system, to the people and to the situation.
For me a practice is a repeated activity – stand-ups are good example of this, as are retrospectives. The line between practice and technique is where it gets really interesting. Let me give two examples:
So we can prioritise work in many ways – we can prioritise based upon value, based upon risk, based upon both. We can use MoSCoW, High/Medium/Low, we can have ordered lists – the techniques that we use to get to a position whereby we have a prioritised set of work are quite varied.
We can also plan our ability to deliver based on facts in a number of ways – we can pull in an iteration worth of points based upon the velocity of the last iteration, we can measure average cycle time and understand our variations. Again the techniques to get the answers are varied.
In both instances we want to regularly ensure that we are prioritising work and that we are planning (where needed) based upon facts.
In this context it becomes simple to argue that maybe Retrospectives, as an example, are not actually a practice and more a technique. In this mindset the practice would be “Evolve the way you do your work” and the technique would be “Retrospectives”. I could live with that. There are many different formats that retrospectives come in – deltas, sailboat, quadrants, timelines. You can also evolve how you do your work in many other ways.
This then leads to the debate about whether statements like “prioritise work” and “evolve the way you do your work” are more principles than practices. Ultimately, if you are regularly doing something that reaches that outcome in a repeatable way I would say it is a practice. I am happy to debated otherwise on this front.
“working smarter and not harder” Note what I don’t say in this definition – I don’t say that it is a software development approach. It can be used for software development, and works well for it, even was born from it, but it can be used for more – so why be exclusionary, spread the love! For this reason it isn’t about working software it is about working smarter. For me, working smarter means delivering value to customers in ways that have reduced waste, improved innovation and a very healthy respect for people.
So in conclusion – just to re-iterate, to me Agile does not mean Scrum. Scrum is just one single element of it. I like to think that methods, practices and techniques such as Kanban, Cynefin, Systems Thinking, Lean, Systemic Flow Mapping, etc all have a place in Agile.
Within Australia I have never seen us as an exclusionary crowd. We embrace better ways of working smarter. We like to absorb them into the Agile toolkit we have, a toolkit that should evolve and change over time as we better understand our world and what works and what does not. Most coaches I know don’t teach just one way, they teach a toolbox of ways and often subscribe to the Oath of Non-Allegiance. They have moved on from the Agile Manifesto and begun to embrace the MoreAgile Manifesto.
As always, all comments are welcome but I desperately desire feedback from the Australian Agile community – what do you think: are we embracers of evolutionary Agile or as a community we are stagnant?
Agile Forest 