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

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.

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:

Display