#CALMalpha…. What should I learn?

Next week is the #CALMalpha event. This will be a great opportunity to see how the experts in complexity organise a “Kids birthday party” for adult using attractors and boundaries. (As opposed to the command and control agenda that we typically see at IT conferences where all of the commitments are made before the event starts. ) It will be great to see how the faculty facilitates self-organisation and then hopefully we can incorporate some of these ideas into XP Day this year.

I hope it is a “pull” based event based on learning rather than a “push” based event where the faculty teach us what they think we need to know. I hope its about…

• What the Complexity Commnuity wants to learn from the Lean/Agile Community.
• What the Lean/Agile Commnity wants to learn from the Complexity Community.
• New stuff that comes out of the combined Community.

That is, each community presents the options that people can pull from it. People then pull in a self organising way. I’m expecting lots of “corridor” discussion from the get go rather than formal chalk and talk sessions.

I know a little bit about complexity but not that much. What should I look to learn from the Complexity and Lean/Agile experts? I would love to know what people use in the Complexity toolkit that I should learn. (Please leave comment)

This is my wish list for the event.

1. Sensemaking. I have heard a lot about the sense making tool and how the Singapore Government are using it to spot terrorists. I would love a hands-on tutorial and case study on the tool showing how it be used for this kind of thing. (Obviously it wont be possible to show the Singapore approach but something similar would be good).

2. Stuff I’m not expecting. Serendipitous learning. Hoping for lots and lots of stuff here.

3. WIFI that works! I am fed up of going to hotel based conferences where the WIFI only works in the lobby.

How to spot an expert.

The chap that sits next to me is pretty shrewd. “How do you spot an expert?” he said. The conversation lasted several days but he had known the answer all along. “Experts ask questions. They don’t give direct answers”.

Experts tend to have a model or framework of the domain for their understanding. They will ask questions to allign their model of understanding with the environment they find themselves in. They are adaptable so they will adopt the language of the environment for their model. They will ask questions to compare their domain model with the environment they find themselves in. They will be looking for subtle differences to help them learn new things rather than assume they are right. When they find differences they know that they could be due to an issue with environment or an issue with their model. They will not assume either is right, even if faced with an environment that appears to be undisciplined or uneducated. This constant search for flaws in their own way of thinking will mean that their knowledge will continue to deepen and be enriched.

A novice by comparison will have the answer. They will be rigid in their use of their own terminology, even though it causes confusion or misunderstanding. The novice may have many many years of exposure to the subject but it might be limited to academic study rather than practical experience, or it may be limited to a narrow range of experiences where they have imposed their own model on reality. Knowing that they are right will mean they will have missed many may opportunities to learn. Their knowledge will remain shallow and limited to the “language of the educated” rather than finding the language of the context. Sometimes the behaviour of the novice “Expert” resembles that of a teenager who has started the journey of learning and assumes certainty in their opinions. The novice will scoff at the un-initiated rather than support them and help them learn.

A novice may appear confident, like Colonel Kilgore in Apocalypse Now! “Charlie don’t surf!”. A man who risks lives for his own amusement.

The expert is confident enough to appear humble, like Andy Dufresne in Shawshank Redemption. “Do you trust your wife Sir?”. An expert in life who dug his way out of prison.

Novice may look like experts but following their advice may kill your project. An expert may seem unassuming but they may dig you out of a tight spot.

Take a look around you. Are people telling each other what to do, or are they asking each other questions?

Learning and Teaching

I have been interested in learning for many many years. Over that time I have studied pedagogy, androgogy and synergogy. Looked at learning styles like Kolb, Gartner and Bloom. My favourite is approach is “Situated Learning” or “Legitimate Peripheral Participation” as Lave and Wenger call it. Everyone else calls it apprenticeship.

I consider that the roles of business analyst and project manager are primarily roles where I help people learn. I provide training in the domain ( business analysis ) and training in the process of risk management ( project management ). Others can then do my job for me which reduces any key man dependency on myself. It also frees me up to do the most important thing of all…. Learn new things myself.

Over the years as I’ve studied learning, I’ve learned a few things and developed a few tricks. Here are a couple of them…

• Teaching is a commitment on the student and an option to the teacher. The teacher decides what the student needs to know and controls the agenda and the timetable. There is no real discussion with the student.
• Helping someone learn is an option to the student and a commitment by the “teacher”. They pull you in when they need to learn something.
• Too little emphasis is placed on holding the attention of the student. Too much emphasis is placed on delivering content. It is up to the student to stay engaged. Several years ago I decided to study Al Murray and Eddie Izzard as models for knowledge delivery. Both use real option based delivery (as most comedians do these days). As a result my primary focus is attention and engagement, Content delivery is a secondary consideration and option based. As a result I can run a session on financial maths for an hour.

I like to help people learn. I hate the idea of teaching.

I wish there was a word for someone who helps others learner. A learnee? Can anyone help? Perhaps there is a non English word we could appropriate. ( hopefully something Arabic like Caravan or Assassin ).

Real Options and the Cynefin Framework.

Next month I might join Karl Scotland, Simon Bennett, Steve Freeman, Jospeh Pelrine, Dave Snowden and others at the Complexity, Agile and Lean Mashup Alpha or “CALM” event. The event intends is to discover where Complexity Science can be applied to plug gaps that exist in Agile and Lean. I suspect the real reason for the event is to start developing material for a “Cynefin” course as applied to Agile and Lean. Anyway, I have purchased an option to attend the event but will wait to see how the Agenda (which is already written but not public) unfolds and evolves.

I first read the Cynefin white paper in 2003 and have been following it from afar ever since. It caused a big stir at XP Day when Dave Snowden delivered the keynote several years back. Cynefin contains some really cool ideas. The problem has allways been. “What do we use the Cynefin tools for”.

Yesterday Steve Freeman and I discussed the event and Cynefin.  Steve said the ability to classify things as “Simple”, “Complicated”, “Complex” and “Chaotic” with the associated rules for how you handle them is useful. One of the warnings in the Cynefin model is that things often tip from “simple” into “chaos”.

Now consider the Real Option “model” -

“Never commit early unless you know why.” – This guides me to avoid making commitments. Whenever I start a new role I always spend time sussing out the environment. From my experience, any environment that involves other people is never “simple” or “complicated”, they are always “complex” and/or “chaotic”. Once I think I have a handle on what is going on I start testing the environment in small ways. Based on the results of the small tests, I then try bigger and bigger tests. At any point I am conscious as to whether a test is reversible (upsetting someone who is forgiving) or not (upsetting someone who is NOT forgiving) . If it is reversible, I am aware of how long it would take to reverse the test if something goes wrong. At no point do I make the decision that this environment is “complex” or “chaotic” as I am aware it can easily and speedily transition between the two. As such I see little value in the ability to classify contexts.

At CALM I a hoping to learn more about Cynefin. How does it handle transitions? Even more exciting is the prospect of getting hands on end to end experience of the “Sense making” tool.

I hope that CALM will help me understand how to turn my theoretical understanding of Cynefin into something practical I can use and promote.

TDD and Real Options

A couple of days ago I watched the fantastic “TDD as if you really meant it” session by Keith Braithwaite on Infoq. I highly recommend it even if you are not a developer ( writer of code ).

I love the simplicity of the process that Keith tells the session attendees to adopt. It is a great exercise in emergent design that highlights how easily developers make assumption about the design rather than let it emerge.

The only thing I questioned was Keith’s suggestion that the developers start “anywhere”. As Keith said this my immediate response was “Start with the ouputs”. I commented on the InfoQ article as such.

I got the impression that a number of the people in the session started with the inputs. They soon ran into problems and started making assumptions about the design. This is exactly the opposite of the Feature Injection process which starts with the outputs. A colleague ( developer ) and I started going through the Tic-Tac-Toe exercise using pseudo-code. (I’m hoping to complete the exercise using C#).

As we worked through the exercise starting from the outcome ( Game Over ) and working into the functions ( isWon, isStaleMate ) generating Mocks as we went along, we suffered from none of the problems that the people in the session encountered. We had none of the desire to make assumptions about the design. More importantly, we quickly encountered the fundamental domain questions about Tic-Tac-Toe ( 3×3 Grid? 4×4 grid? 3 dimensional grid? ). How do we test to make sure the isWon works properly. Issues about inputs were not even discussed. Issues about display were not discussed. We had lots of options. We drove right into the riskiest part of the development from a domain perspective.

Previously I have never commented on TDD but it seems to me that TDD should also start with the outputs and work to the inputs. In effect, Feature Injection, should be injected into TDD.

I’m waiting for the flames!

Disclaimer – I assume someone else has already said this but I just am not aware of it.

I will post the code when I do it in C#

Pseudo Code: Code in red

Test 1 – isFinished is TRUE

iSFinished() return True

Test 2 – isFinished returns FALSE

isFinished() return game.Finished()

Create mock game.isFinished returns False

Test 1 Fails. Refactor test 1 to use Mock game.isFinished returns True

Test 3 – game.isFinished is TRUE

game.isFinished() return TRUE

Test 4 – game.isFinished is FALSE ( GIVEN NOT isStaleMate AND NOT isWon WHEN game.IsFinished THEN FALSE )

gameisFinished()

if game.isWon() || game.staleMate() then

    return TRUE

else

    return FALSE

2 Mocks game.isWon() returns FALSE and game.isStaleMate() returns FALSE

Test 5 – game.isFinished is TRUE, isStaleMate ( GIVEN isStaleMate WHEN game.IsFinished THEN TRUE )

2 Mocks game.isWon() returns FALSE and game.isStaleMate() returns TRUE

Test 6 – game.isFinished is TRUE, isWon ( GIVEN isWon WHEN game.IsFinished THEN TRUE )

2 Mocks game.isWon() returns TRUE and game.isStaleMate() returns FALSE

Test 7 – Test 7 – game isFinished is TRUE, isWon and isStaleMate ( GIVEN isWon and isStalemate WHEN game.IsFinished THEN throw exception )

2 Mocks game.isWon() returns TRUE and game.isStaleMate() returns TRUE

gameisFinished()

if game.isWon() || game.staleMate() then

    return TRUE

elseif NOT(game.isWon() )&&NOT(game.staleMate()) then

    return FALSE

else

raise exception (“Its broken because it should be possible to win and be in stalemate”)

The coding finishes when all the mocks are all implemented.

Coding to be continued…

Note that the GIVEN WHEN THEN calls out the Mocks to use. Mocks were the inspiration for the pattern.

Notes:

 

Tic Tac Toe ( Winning )
1	1			1			1
2	1				1			1
3	1					1
4		1		1
5		1			1		1	1
6		1				1
7			1	1
8			1		1			1
9			1			1	1

Display

 

1	2	3
4	5	6
7	8	9

 

How I use Real Options to play Tetris

Real Options have many applications. Any activity that involves making commitments can be studied using the lens of Real Options. One of my guilty pleasures is to play Tetris. It is a game full of commitments and options. It is a useful tool to study real options.

There are two strategies I use to get a high score in Tetris. The first is “Get a Tetris”. The second is “to stay alive”.

“Get a Tetris”

At the start of the game when the blocks fall slowly, I attempt to get a Tetris. That is where you guide a long thin block into a long thin gap and complete four rows in one go. Achieving a Tetris optimises your score for clearing four lines. As the blocks are moving slowly it is fairly easy to carefully chose the optimal place for each block. The success of this approach depends partly on the order in which the shaped blocks arrive.

 

One consequence of “Get a Tetris” is that you get high tower of blocks. These are easy to cope with when the blocks move slowly, but they cause trouble when the blocks start to move fast.

“Get a Tetris” is not really that interesting from a Real option perspective.

At some point (about 250k) in the game of Tetris that I play (on the iphone) the speed of the falling blocks increases to the point where they appear to teleport from the top of the screen to the bottom of the screen. “to stay alive” requires a different approach to getting a high score. Obviously the “Get a Tetris” strategy needs to be dropped. (See later). Now the only thing that matters is “to stay alive”.

“to stay alive”

We need to carefully manage our options and commitments. This is where real options really kick in.

There are two key capabilities in my version of Tetris. One is the ability to spin the block after it has landed. The other is the ability to move a block left or right after it has landed. However it is only possible to move a block in a direction on the same level or down a level. The option to move a block does not exist if it requires moving upwards.

“to stay alive” uses these two abilities. The ability to spin blocks is used to give more time to consider the target location for the next block. The block is then positioned according to where the next blocks should be placed.

In order to move a block it must land in a place that is higher or level with the spot it will be moved to. This has an influence on the target shape for the blocks. Given the speed that the blocks drop after a certain point, the following shape provides very few options…

Alternatively, it is possible to move the block in the following shape…

…Though only towards the edges. If you move the block one way and then discover you have made a mistake, you will find this shape has committed you to the move you made.

The ideal shape is flat so that you can change your mind after moving the block and move it back in the opposite direction.

In other words, the shape determines the number of options that we have and more options make it easier to play.

The towers that “Get a tetris” can create make it harder to survive.

So what does this really tell us about Real Options? I think it tells us that I need to stop thinking about Real Options so much.

Have a lovely holiday.

Chris

The Language of Risk

Last week I had an enjoyable chat with Janet Gregory about risk management. We were discussing how risk management is not one thing, rather it is an attitude or approach. The conversation reminded me why I started this blog.

Earlier this year the system I worked on was subject to a methodology audit. I spent several hours working with the auditor to explain the approach we were taking. At the end of the conversation the auditor said they wanted to use a kanban system to manage their audit process.

Why did the auditor like what I said? Because I explained everything we did in terms of risk. When they asked for a “process”, I explained the risk the process was meant to address. I then explained how our different process addressed the risk more effectively.

A couple of examples.

“Do you have stakeholder sign-off on your requirements to ensure they all agree on the priorities?”

reframed in risk terms as:

“How do we address the risk that we might be building the wrong thing?”

and we addressed as follows:

“Every week we present the status of the list of projects we are working on to the steering committee. The longest we can work on the wrong thing for is one week.”

“Where is your functional spec.”

reframed in risk terms as:

“How do we avoid the risk of building the wrong functionality?”

“We have a two page functional spec. Any more and the stakeholders will not read it. We also have a whole bunch of examples that the stakesholders have verified as correct, and a mock up in Excel so they have an idea of what it will look like. The key is to get quality feedback from the stakeholders rather than get a signature that means nothing. A signed off spec. sort of transfers responsibility from IT to the business for getting the requirements right… but not really. IT will get the blame if it does not work, even if they have it all signed in stone.”

For the fifty or so process audit points we went through each one doing the same kind of thing. Step one, agree the risk the process step is meant to address. Step two, explain how our team addressed it.

The language is important because it helps you think about the problem in the right way.

From my experience, middle and senior IT management respond well to this way of thinking, as do the business investors.

What is the purpose of The Software Craftsmanship movement?

Rather than an opinion, this is a question. What is the purpose of the Software Craftsmanship movement?

I heard the start of Bob Martin’s speech at Agile2008 in Toronto. I walked out because I wasn’t comfortable with the language. I missed the speech that launched the Software Craftsmanship movement.

Since then, there have been conferences and code retreats, and even a manifesto. I know some of what the software craftsmanship community do. I’m just not sure why? I’m not sure what problem it is trying to solve.

From reading the manifesto it seems the purpose of the software craftsmanship movement is to help the top X% of developers get better. This is not a bad goal, I am a member of the Agile community for the same reason.  (The few members of the movement I have discussed this with deny that this is the purpose.) If so, all is good and fine but it does not really help improve the software development industry.

As a project manager I’ve never had a problem with the top X%. They care about the job they do and want to get better at it. The problem for me has always been the bottom Y% who do not care and oppose learning new things. I would prefer a movement that pitched its level much lower and made it possible to address the problem at the bottom rather than elevate those at the top.

So what is the purpose of the software craftsmanship movement? Can anyone help me with this one because at the moment I don’t get it.

Many thanks

Chris

The risk of comments in code.

Many years ago I used to program. Received wisdom had it that we should put comments in the code to explain what was done. When a developer we worked with said that the others should read code like sheet music, we thought him a tad eccentric. A couple of colleagues would comment his code after he had explained it to them. They would complain the next morning that he had deleted the comments overnight. It was a tit for tat battle. Eccentric developer versus developers following best practice. As a manager I found it frustrating that he kept deleting the comments.

That was fifteen years ago. What about now?

When I learnt to code at university, it was common to see something like

v = h * l * w

Meaningless and totally unreadable. Comments were necessary to understand what is going on.

Instead, the variables should be renamed such that

volume = height * length * width

Totally readable and easy to follow. Now that the code makes sense, the need for the comments is reduced.

Sometimes you might find comments where the mental model of the domain is different to the one used to implement the solution. Often the comments are placed in the code when someone has to change someone elses code. Another way of explaining what is going on. An obvious violation of domain driven design principles. An exception to this rule is if the domain is complex which leads to complex code. (Thank you Dan. See comments)

The key thing is that comments indicate the presense of code that is hard to understand. They may indicate the presense of technical debt.

Some years ago I attended an XP Game involving Lego at XTC. It was my second or third visit to XTC. We had to iterate through the design of a lego car that we controlled with software built in a basic computer language. I had the great fortune to pair with Alistair Cockburn (said the Scottish way). I was numbering our versions of software as “1″, “2″… Alistair said we should name them “Go”, “Go and Stop”, “Reverse” and so on. My version names would have required comments.

Comments are needed when the name or symbol we ascribe to a thing is a name rather than a description of the thing. Changing the name to something meaningful allows us to remove the comments in many cases.

Not so many years ago I did some analysis to work out how you calculate the cash flows associated with Index Tranches (Exotic Credit Derivatives). I documented the cash flow generation using pseudo code.

Pool Notional = Tranche Notional / ( Detachment Point % – Attachment Point % ).

etc. etc.

I created thirty six examples based on the pseudo-code. A user spotted a missing condition and as a result I changed the pseudo code and added a further six examples.

The pseudo code spread to several pages and I was concerned that it was too difficult for people to follow. I suggested to the same user that I comment the pseudo code. He rejected the idea “If they cannot understand from reading the psuedo code I do not want them signing this off. There is a danger they will sign off based on the comments which may be different to the pseudo code in subtle but important ways.”

As a risk manager, comments act as a risk indicator. The presence of comments indicates that the code is possibly not clearly written. That a developer may make a mistake in that area of code. That the code is risky to change and care (automated testing) is needed.

Of course, an absense of comments does not indicate an absense of risk.

Thank you to Nat Pryce for inspiring me to write this post with your tweet the other day.

Red Bead Roulette.

Have you ever been to a casino? My parent took me a few times when I was younger. I avoided the card games as they seemed to require skills that I knew I did not have. I favoured roulette. That big wheel with numbers around the edge. The brief flash of the ball as it left the skilled croupier’s (?) hand, and the tick, tock, plunk as the ball decided the fate of the anxious gamblers and the fresh faced maths geek.

Now imagine a variant on the game. You get to run the game twenty times. Each time, you have to bet on black. You count up the number of times you win. This is your score.

Now run the game again. But this time make a change. Instead of one person placing the bet, get two, or five, or one hundred. Will it change the results?

Now try doing it standing on one leg.

Or with a glass in your hand. A glass containing whiskey. Now drink the whiskey. Drink lots of whiskey. Drink whiskey with ice, and whiskey without ice.

Do any of these changes make any difference to the score?

No!

The outcome of the game is determined by the inherent randomness of the process and the constraints placed on it (always bet on black).

This is Deming’s famous red bead experiment. It is meant to teach us that nothing we do will affect the outcome of the system. It proves that the system dominates. It ensures that by construction.

Consider an game that is more a production process in the real world. Imagine a casino where we could do whatever we like. the individuals playing the game might decide the take the ice cubes out of their whiskey glasses (there are a hundred playing so numbers count. whiskey with ice is needed) and block the red and white slots in the wheel. This would force the ball to always land on black.

That’s what inidividuals do. They change the rules of the game. They change the system.

Next time someone offers to play the red bead game, discreetly remove all the “bad” beads before one of the goes. That way, you can demonstrate to the people running the game that the system does not dominate and that individuals can have an affect bigger than 6%. Of course, expect them to be angry because they are the ones in control of the system.

I would like to thank Don Reinertson for inspiring me to think about the “Red Bead Con” with his keynote at Lean Kanban Benelux