Agile Games - Ball Point Game

With my companies developer conference coming up I wanted to find some fun games to illustrate some of the advantages of Agile methods and SCRUM to those not yet invested. During my SCRUM Master training I found the physical learning very beneficial.

One of the games I played and found detailed on the internet is the "ball point" game.

The setup

The game itself is pretty simple. You need a bunch of objects to pass from one person to another. The recommended object is a ball but which type of ball depends upon what is available to you. Tennis balls are good. If you can get half of the balls in one color and the other half in another that may help but it is not required. You will need 20 or so more balls than people in the group. Unless you like running around I would suggest one or two containers big enough to hold all the balls be available.

You will need plenty of room. Enough for all the players to stand in a circle.

You will need a white board or flip chart to record the scores.

You will need a timer, a smart phone will be fine.

The aim of the game is to pass as many balls as possible in the time allowed from one player to another until every player has touched the ball. The ball then scores. The time allowed is 2 minutes and you will get 5 goes. Before each go the team have 1 minute to plan their approach and give an estimate for the number of points they can score and note any significant changes to the process. At the end of the go record the actual number of ball points scored and any balls dropped.

The rules

Write the rules on a flip chart visible to all. These are the only constraints of the game.

1. You are one big team
2. The ball must have "air-time". It cannot be passed directly from hand to hand.
3. No ball can be passed to your direct neighbor
4. The Start point is the same as the end point
5. If you drop a ball it is out of the game
6. Each go, or iteration, lasts for 2 minutes
7. You have 1 minute between goes to plan
8. There will be 5 goes or iterations 

The impossible target

After the fifth iteration say that you have seen a team achieve 150% more points. Does this team think they can do that? ... 

What we take away

That we are following a Deming Cycle - Plan, Do, Check, Act much like SCRUM. With each iteration we learn and use that leaning to improve.

Depending upon the approaches taken we may learn that too much work in the system leads to mistakes, dropped balls, and is less efficient.

That communicating together as a group face to face allows us to rapidly adapt the process for quick improvements. Imagine if the planning/checking phase were done using e-mail?

What if we had a "star" player? Would we have scored more points?

During the impossible target round we should see the team fail. Either they will be stuck in the planning phase past the minute or they will leap into the task without proper planning leading to dropped balls. This teaches us that unrealistic goals lead to chaos and lack of planning and team work will reduce quality. Did the team have a clear agreement of what their process was before starting?

Did the team achieve "flow"? A state where everything was running nice and smooth and the points were flowing. How does the team think interruptions might have impacted the flow? 

Links

With a twist - unrealistic goal set

A more detailed explanation

Agile Games - The Penny Game

With my companies developer conference coming up I wanted to find some fun games to illustrate some of the advantages of Agile methods and SCRUM to those not yet invested. During my SCRUM Master training I found the physical learning very beneficial.

One of the games described on the internet is the "Penny Game". I thought I would record it here so I can share with the other SCRUM Masters in my organisation.

The setup

The requirements for the game are pretty simple. You need 20 coins. The values are not important but 80% of the total value should be held by 5 of the coins. If possible try not to make the high value coins too different from the others. If they are gold and the others bronze it will give the game away. This make up of values will be used later to illustrate a point. You will need a whiteboard or flip chart to write the results on. A piece of paper will do at a pinch.

You need 7 players.

1. The customer - his role is to collect the output of the process. The deliverable of coins.
2. The manager - his role is to write the results up and to time the process.
3. 4 team members - their role is to act as workstations.
4. SCRUM master - to facilitate the process and guide the team (this is your role)

The Game

The game is simple in nature. The coins are fed into the system by the manager in various ways described below. Each workstation turns each of the coins over if you are working on tables or flips them in turn if you must stand. They then pass the coins to the next workstation until all coins have been processed and the final station passes them to the customer. The manager times this from the point he hands over the coins to the first station till the point the customer shouts stop. The manager then writes the cycle number and the time on the white board or flip chart.

First Game Cycle

Each worker should sit apart on different desks within the room. If standing then they should stand apart with as much distance between them as possible. Explain that once they have processed the coins they must carry the coins to the next workstation and return to their original position before the next worker can begin the task.

Begin the game with the manager giving all 20 coins to the first workstation.

This is the baseline time. It should be the worst time.

Once the game has finished the SCRUM master conduct a SPRINT RETROSPECTIVE. He will ask everyone how well they think they did and what one improvement could be made to get a better time. I would anticipate that change will be in the list of other cycles below so make that one change and proceed with that cycle.

Co-located Game Cycle

Each worker should sit or stand next to each other so the time to transfer coins from one station to the next is reduced.

Begin the game with the manager giving the last used count of coins to the first workstation. If this is the second cycle this will be 20 but the game may run out of order, which is fine.

The time will be quicker than the previous cycle because we have taken out some process time. The time to travel between workstations.

Once the game has finished the SCRUM master conducts a SPRINT RETROSPECTIVE. He will ask everyone how well they think they did compared to the previous cycle. They will understand that removing the travel between workstations reduces the cycle time.

Make the point that the travel time between workstations represented a communications delay. Removing communications delays by co-locating the team reduces cycle times.

Ask the team what one improvement could be made to get a better time. If they have no suggestions of their own steer them towards varying the batch sizes. 5 is the ideal batch size but it may take some cycles to get there.

Reduced Batch Size Game Cycle

When they have decided on a batch size start the game. The manager feeds in the batch size of coins to the first workstation. Once that workstation has passed the coins to the next the manager adds another batch. The time begins after the first batch is in the system and ends when the customer has all the coins.

The time will be quicker than previous cycles and probably quickest with a batch size of 5 because we have improved the process flow. Other team members do not have to wait so long for work and we get more done in parallel.

Once the game has finished the SCRUM master conducts a SPRINT RETROSPECTIVE. He will ask everyone how well they think they did compared to the previous cycle. They will understand that reducing the batch size makes the process more efficient.

Make the point that reducing the size of the work allows each worker to be working on something sooner. The improved flow of work through the team makes them more efficient.

Ask the team what one improvement could be made to get a better time. Ask them what if the customer would be happy to accept delivery of some of the functionality to test with the understanding that the rest of the functionality will follow?

Reduced Batch Size Game Cycle

When they have decided on a batch size start the game. The manager feeds in the batch size of coins to the first workstation. Once that workstation has passed the coins to the next the manager adds another batch. The time begins after the first batch is in the system and ends when the customer has all the coins.

The time will be quicker than previous cycles and probably quickest with a batch size of 5 because we have improved the process flow. Other team members do not have to wait so long for work and we get more done in parallel.

Once the game has finished the SCRUM master conducts a SPRINT RETROSPECTIVE. He will ask everyone how well they think they did compared to the previous cycle. They will understand that reducing the batch size makes the process more efficient.

Make the point that reducing the size of the work allows each worker to be working on something sooner. The improved flow of work through the team makes them more efficient.

Ask the team what one improvement could be made to get a better time. Ask them what if the customer would be happy to accept delivery of some of the functionality to test with the understanding that the rest of the functionality will follow?

SCRUM Team Game Cycle

For this variation of the game the manager gives each team member an equal share of the coins. The timer starts when the manager shouts go and each team member turns over their coins. The game ends when every team member has raised their hand to indicate they are complete. 

The total time will be the fastest so far. Only the 80/20 game variation with a SCRUM team will be faster.

Once the game has finished the SCRUM master conducts a SPRINT RETROSPECTIVE. He will ask everyone how well they think they did compared to the previous cycle? It should be clear to all that the whole team working together is faster than the 'waterfall' like process of passing coins from one worker to another.

Ask the customer if he would be he be willing to accept 80% of the total value if he could get it quicker? The team should arrive at the next variation on their own but allow them a couple of cycles if they need it. 

80/20 Value Game Cycle

The manager feeds in the first batch of the highest value coins. This will be about 80% of the total value. For this variation of the game the manager stops the timer when the highest value coins reach the customer.

The time will be the fastest once the first batch is the highest value of coins. If working as a SCRUM team then each team member will only have to turn over one coin. This is the fastest approach.

Once the game has finished the SCRUM master conducts a SPRINT RETROSPECTIVE. He will ask everyone how well they think they did compared to the previous cycle. They will understand that delivering the highest value first obtains the fastest time to 80% of the features.

References

There are many references to this game or variations of this game on the internet. I haven't been able to discover it's origin to credit the creator. 

WinDbg - Debugging an x86 Managed application running on an x64 OS from a mini-dump

Crash Analysis using WinDbg

I am working on an a complex managed application that has locked up after performing a task. I am recording the steps I take here so I can recall what I need to do the next time. All my short term memory has been uploaded to Google these days!

How to get the dump

There are a bunch of ways to get the dump, we need a dump with memory to be of any use. The simplest way if you are unprepared is to use the Task Manager. On the context menu for any running process is Create Dump File.

There are smarter ways though and a dump can automatically be created if an application meets certain criteria such as becoming unresponsive or hitting a process use peak. SysInternals ProcDump

What tool to use?

Visual Studio can open a mini-dump file but unless the Managed application uses version 4.0 .NET or above you cannot debug a Managed application.

The best tool I have used so far is WinDbg. This is the real man's debugger for Windows applications. You can find downloads for the debugging tools here.

The next question is which WinDbg to run? There are two installed on a x64 OS. Should you run the WinDbg x64? That depends on if you are debugging a 64bit application. If not then run the x86 version of WinDbg.

Opening the crash-dump file

Run the WinDbg and from the file menu Open Crash Dump... <Ctrl+D>. When it opens you will get some information and some complaints about symbols. We will get to symbols later.

First thing you need to do is figure out some details about the application you are debugging.

lm vm appname will list the module information about the appname module. This will include the file version information. If you want to have an easy life ensure that version of the application is installed on your system rather than any other. To successfully debug from a dump file it is essential that the symbols you use match the code being investigated in the dump file or you will get misinformation.

There are two sets of symbols we need. The Microsoft symbols and our own application symbols. The Microsoft symbols we can obtain from the Microsoft symbol server. Out application symbols we can obtain from the PDB files we generated when the application was built. These will be held in our own symbol server. (Doh! - we don't have any of that!)

Our get out of jail for not generating the symbols and storing them during the build process is the wonderful news that JetBrains dotPeek can de-compile our binaries and generate the symbols for our application and can even simulate a symbol server to provide those symbols to the debugger. Phew.

Using JetBrains dotPeek as a Symbol Server

Open dotPeek and add the application installation folder to the paths. dotPeek will de-compile all the binaries in that folder. Enable the SymbolServer and the symbols from that de-compilation will be made available to the debugger.

Setting the symbol path

We want to set the symbol file path to use the Microsoft symbol server, the dotPeek symbol server and to cache the symbols from these servers locally to improve on load times. The command is as follows.

WinDbg Command

15. .sympath cache*c:\SymbolCache;srv*http://msdl.microsoft.com/download/symbols;http://localhost:33417/

More information can be found about controlling the symbol path here

Troubleshooting symbol loading

The symbols for an application are date and time stamped and a checksum is stored. The date and timestamp along with the checksum are used to verify that the symbols loaded match the binary image being debugged. This causes us a problem because we do not use a symbol store as part of our build process so the date and time of any binary we build will not match. We can get extra information on the problems with the loading of symbols using the following commands.

WinDbg Command

15. !sym noisy
16. .reload -f

It is possible to force WinDbg to load any symbols. This may seem like a get out of jail but there are problems with it. The symbols may not match the code being investigated and this can lead to miss-information about the problem. The only real use of this is when you re-build the application from source at a later date using the label in the source control system.

WinDbg Command

15. .symopt+0x40
16. .reload -f

Text goes here

Debugging Managed applications

We need some help debugging managed code. There are WinDbg extensions that will assist us.
There is some guidance on this here

Psscor2

WinDbg Command

15. .loadby sos mscorwks
16. .reload -f

Text goes here

Extensions to help with managed debugging

SOS

SOS is Microsoft's WinDbg extension for debugging managed applications.

SOSEX

SOSEX is a third party extension which can be found here. Download the 32 bit version and unzip it to the directory where the 32bit version of WinDbg is installed.

WinDbg Command

15. !load sosex

Debugging a hang (deadlock)

When debugging a hang in a managed application we may want to do several things but a good start would be to look for threads waiting on the various types of lock.

WinDbg Command

15. !sosex.dlk -d

The output of this command will tell us if there are threads that are deadlocked. If there are none then we may want to examine all the call stacks for all the managed threads

WinDbg Command

15. ~*e !CLRStack

We may wish to examine all of the Managed locks and which thread holds them

WinDbg Command

15. !sosex.mlocks -d

We may wish to see which threads are taking the most time to see which one might be hogging the system

WinDbg Command

15. !runaway

We may wish to see the names of the running managed threads

WinDbg Command

15. .foreach (address {!dumpheap -short -mt 725e4960}) { .if (poi(${address}+c) != 0) { .printf "%d ",poi(${address}+28); .printf "%mu\r\n", poi(${address}+c)+8 } }

Visual Studio 2008 fails to install redux

I wrote the other day about the hack I used to get Visual Studio 2008 SP1 to install. It was to overcome the problem with the VC++ run-time always failing to update.

Further research has revealed the actual root of the problem and a way to fix it.

The registry keys for the installer components for the VC++ run-time have the permissions borked. Fixing up the access permissions so I could read/write/delete them allowed the un-install and install to work just fine.

See:

• Similar issues
• using SubInACL tool to fix registry permissions
• Seems they are still getting this wrong

Visual Studio 2008 SP1 fails to install

Disaster! I Can't install VS2008 SP1

Every time I try and install it fails because of the VC++ run-time. What can I do? Oh what can I do?

As always, if at first you don't succeed... give up and throw a tantrum!

The Visual Studio 2008 SP1 always fails during the update to the VC++ run-time DLLs. The log file is not really helpful but since I have 2010 installed also and have applied all the updates to the Windows 7 I assume my VC++ 2008 run-time is probably more up to date than the SP1 anyway. How then can I move on?

I tried un-installing the VC++ 2008 run-time and reapplying the SP1. No joy. I tried using the installer cleanup tool to wipe them from the face of my machine. Equally unsuccessful. I even tried getting the most most most recent versions from Microsoft and reapplying the Visual Studio 2008 SP1 to no avail.

My eventual solution? Cheat.

The fix I applied is to copy the service pack to your hard drive and edit the file ParamerInfo.xml. This file seems to be the data driven configuration controlling the SPInstaller tool.

Find the lines in the Items group calling the VC runtime installers, there should be three sets, and comment them out.

  <Items OnSubFailureAction="Stop" DownloadRetries="2" DelayBetweenRetries="5">

<!-- The start of my commenting here

    <Exe Name="VC_x86Runtime.exe" [snip...] </Exe>

    <Exe Name="VC_x64Runtime.exe" [snip...] </Exe>

    <Exe Name="VC_IA64Runtime.exe" [snip...] </Exe>

the end of my commenting here -->

Once you have saved away the changes re-run the service pack install tool and it will skip the VC++ 2008 SP1 run-time installation and go on to successfully install everything else.

Remember you will still need to install the VC++ 2008 SP1 run-time for x86 and x64 but you can get a standalone installer from Microsoft downloads for these and they work just fine.