My favourite and the best MindMap Software Tool Today

I don't usually walk around selling anything but today after years and years of using iMindMap for my Tony Buzan "proper mindmaps", and dozens of its other features...I am totally in awe and need to share.

I started using Microsoft (MS) Project in 1995. During my holiday (?) and spare time (??) I worked on a VB OLE project to integrate a packing scheduler algorithm for South Africa's biggest fresh fruit exporter with MS Project. Critical paths, Dependent tasks, Schedule compression, coloured, Start-Stop Dates, Split runs, Merged runs, Faster packing lines, Slower packing lines, More/Less expensive packing lines, Pallets per minute/hour/day, Breakages, Resource balancing, and a lot more was thrown at me, and I, in turn, threw the requirements into the algorithm and nicely displayed useful intelligence between a calendar view (before there was a calendar widget), an MS Access Database (ermmm), and MS Project. And allowed the human packing scheduler to move things around. What used to take him weeks and weeks locked away in small room every year, took a few hours of data entry, and then intelligent drag and drop to test different options at various stages of the year ahead. Power to the people! Power to the user! Organisational resilience was a key factor in why the client wanted this solution - the Planning Manager was getting very close to retirement and this was a massively complex job to succeed with, and critical to business success!

Now...after 24 years of acquaintance, love, hate and other feelings about MS Project (and project management in general, traditional, agile and other perspectives), and many of its competitors in "traditional project management" and "agile" spaces ... I have been settling for years now very comfortably into post-its, string, and/or magnetic whiteboards or cork boards.

Until now - finally a new tool is tickling my interest again in this space. Check out this video - Using iMindMap Time Map Feature - and let me know if you've ever seen any software tool better for planning dynamically and quicker than this! Yes, I will continue to collaborate and facilitate planning with a team using low-fidelity approaches...but then when it comes to digitising, I may take a photo, or I may take a backup photo AND upload the detail into iMindMap. "It depends" as always, on what the value is and to whom.

While you're looking at the Time Map video...consider the Bubble Web, Bubble Group and my current favourite, the Radial Map. It's the fastest way I currently have of converting all my random sometimes linear, sometimes non-linear, thoughts/ideas/memories/questions into something visual and then being able to make better sense of "it all". From essays/term papers I need to submit for my coaching degree, to notes from meetings, to possible options for various things. And especially notes to myself for my own reflections now, later, and much much later.

I don't have shares in iMindMap, but hope to (soon), or it's parent group Open Genius which also has an amazing charity to help youth of today be the leaders and saviours of tomorrow!

When my high school 16 year old best friend introduced me to mindmapping in preparation for our upcoming History exams, I really did not get it. I basically copied his the whole way through our studying together and had MUCH worse marks than him. Then in 2001 I bought


and it changed my world ever since. Slowly at first, but as I got better at drawing and creating something meaningful to me, so my memory of the things I was drawing and pictures I was creating for myself improved radically.

A 3 Minute MindMap On An iPad Notes! Not A Great Example But Return On Investment Is Good Enough For This!

Another 3 Minute MindMap - From iMindMap. ROI Is Good Enough IMHO. See Why I Need All The Help When Presenting My Ideas To Other Folks? :-)

Prior to this, I could never last minute cram for exams. Not that I recommend anyone to do so! But I have discovered that even in crisis of 2 full time jobs and studies on top ... mindmapping got me through and still gets me through a massive amount of work in a short space of time!

And in about 2009 I gave this

to a friend who was also studying part-time and it helped them pass their legal+finance course with its huge volume of content!

I bought these 2

to help my son in 2018. There is some overlap between the 2 books but it seemed like such a solid investment in his lifetime and it turns out he really likes mindmapping also!

My son is only 7!

7 Year Old First MindMap By Hand

My son loves working on computers ...so he HAS to use whatever I use (joys of being a rolemodel?), and so... he did this *quickly* as his first software mindmap.

His First Ever Software MindMap Version Without Much Assistance Or Training From Me. iMindMap Really IS Child's Play! This Took Him Under 10 Minutes

Many more happy mindmapping and learning days ahead! #happyparents #happykids

More Happy Days! When I bought the iMindMap Ultimate Plus edition of the tool, I also received a copy of Tony Buzan's business mapping book. Some food for thought in here also especially if you're new to business and/or management!



If you don't yet know who Tony Buzan is, it's worth checking out his  TedX Talk "The Power Of A Mind To Map" and bits from youtube for example YouTube video "Learn, how to learn" for some sense of where he is coming from.

Thankyou for reading!

My favourite coaching tools: SMART Acronym Another Update

What the heck!? The SMART acronym again?

SMART - 3rd Time Lucky?

I thought I had all this simple stuff figured out. By 2012 I was willing to post my original thoughts and approach to SMART Goals/Objectives in the original post: http://change-challenge.blogspot.com/2012/06/my-favourite-coaching-tools-smart.html. It had evolved from my own practice as a delivery team lead, management student, and, later on, my first 2 years of agile training classes, coaching individuals and teams, and supporting departments through successful transformations.

Through 2016-2017, after supporting more transformations and agile adoptions with much more variety I realised some useful nuances to this multi-purpose tool had emerged by working with it in so many different ways. So I put out my update - http://change-challenge.blogspot.com/2017/10/my-latest-smart-acronym-update.html and thought "that's done now!".

Silly me. When is learning ever done? And so it was again. Late in 2018 I was on a totally non-agile, non-software, non-management, non-"normal" experiential psychology course. As we approached the end of the course we were asked to come up with 1 (I really like 1, and only 1, "there can be only 1!") SMART objective to help us take the next 1-2-3 steps after the course ended.

Whilst I was considering my objective, something else clicked into place for me that I'd been overlooking. Well 2 things actually. :-)

1, The confidence-risk level could be assessed with the "A" for "How Achievable?".
2, The alignment to purpose/direction/bigger picture could be assessed with the "R" for "Really-make-a-difference-in-the-direction-we-are-going?".

The A

An achievableness on a scale of 1-5, from improbable to highly probable ... we get a sense of how much risk the individual, team or group is willing to tolerate/try move through. Often it's okay (great!) to "try" for an easy win with a 4-5 level of confidence. Sometimes it is better, for learning or even to save the company, to try for something harder to do (with a friend, coach or mentor especially to support!) in the 2-3 range. So many "it depends", so little time to elaborate experiences here! :)

The quantification of achievableness is important when considering the alignment of this objective/goal to the purpose of the individual, team or group. Sometimes we could do the easy thing which is highly certain, we are confident in our capability to achieve it, and it will have no,  negligible or insufficient impact on achieving our purpose.

Such highly certain successful outcomes could be a waste of the one thing we always run out of, that no money or anything else in this world can get more of: time.

Using the R to confirm that we're aligned with purpose is really useful. Yet being aligned with purpose could expose us to a context, circumstance, super-ego, mindset or organisation "change anti-bodies" - "historical baggage" often - that do not really make it easy for us to align our efforts to our purpose and pursue that wholeheartedly. And it's good to reflect on this before, during and after - there is so much growth possible by understanding this "stuff" deeply!

The R

Reality. Realisation. Becoming real. That which is real. Turning deep desires (especially one's purpose) described by abstract thoughts or ideas into abstract words and then into "real world". Something really shifted in me that day in 2018, and I don't know why or what the final effect will be. Essentially it was around my previous interpretation of "responsible person assigned".

I really believe something better can be done with the acronym here. I have seen "realistic" in many places in the past - as in "the goal/objective is achievable and realistic". Or "actionable and realistic".

SMART Objectives Aligned To Team or Individual Purpose Creates A Desirable Tension Around Potential Which Then Unleashes Huge "Action" Energy To Achieve The Change In The Real World

What shifted for me that moment was that it could be better used as "really aligned to purpose". This is imho much stronger / more energetic / more focussed. For any objective or goal. And if its a tough thing to change, we absolutely need to believe we're going through the tough bit to get to a better place, else we will give up. And that defeatedness because of giving up can be a really worse place to land up.

With Specificness (as per my 2017 SMART update), it's easy to include the responsible person there as an attribute/quality that makes the change even more Specific. Similarly with tight "Measured by" criterion set that matches that Specificness.

OKR's (Objective, Key-Results) try to approach this slightly differently. But there is overlap that I guess I will draw out in the future when my thoughts and experiences are clearer.

Einstein apparently said something along the lines of - given an hour to solve a problem he'd spend 55 minutes thinking about the problem [in detail, in depth, from multiple perspectives, etc] and 5 minutes attempting to solve it. That way you'd be more certain which part of the problem your solution addresses well or not as well, and what other potential things you could change or try with another attempt later if need be. The solution matches the problem. Often - because it is in our nature, society and expectations from others - we solutionise too quickly and what we come up with may be good, but misses the original problem. A great shot that misses the target...is just a great shot. Same time, same cost, same effort. Miss. Absolutely useless in the context that mattered before the shot was taken.

Thankyou! As always happy to hear your thoughts on the above! Be careful out there, AND don't be too serious - fun provides a lot of goodwill and positive energy to achieve goals!

How to get it done in organisations

I was attending a course during 2016. Attending were a whole bunch of people from many different walks of life, and many different organisation experiences and levels.

Out of the blue, one of my fellow trainees was explaining how they, in their role of working with many organisations on big business-to-business transactions, had discovered a very useful approach to getting things done in their own organisation, as well as client organisations.

"Want something done? Give it to a busy person"

This statement about "how to get it done" in large organisations drew quite a negative reaction from within me.

I realised the statement was right and wrong at the same time.

Busy people have figured out ways to give and to create more value to the organisation - by being of good service, they are asked to do more and more. They figure out ways to do more and more - usually alternative work practices that make them more streamlined / efficient. They become extremely knowledgeable across the whole organisation - knowing who's who, and who to go to directly and for what. Also importantly, they know which avenues to not even bother to try - saving everyone time and frustration.

So...the statement still makes me feel a bit ill, but I also recognise the truth in it. Many organisations I have worked within are literally functioning mostly as a result of these very busy network nodes.

For managers and leaders - look after your ever-busy people - they are busy keeping things moving in the right direction. You may not know what keeps them so busy - but perhaps that's where a little more curiosity and study will be quite revealing!

Agile In Four Or 4 words

I've been heavily reflecting on last week's post agile in 3 words and I'm not happy enough with it.

So this "Agile In 4 Words" is a response to that previous thought - to bring in a previous previous thought I captured in this older post Open question how.

I think the shortest summary to what is agile - other than "collaborative lightweight working practices" that means many different abstract things to many different people I've tried it on...and gotten nowhere with, is actually:

"How can I help?"

This one induces in the person asking out loud or silently to themselves the team working principles, the proaction, the learning, and more. That lovely "how?" question really opens things up more for everyone!

Especially in response to my earlier attempt "Can I help?" - a simple "No" would stop anyone in their tracks. And that "No" is to be expected when people are massively in a state of focus and don't want any interruptions.

The "simple" introduction of the "How" makes this an engaging question that any team member can get creative with by themselves and come up with more creative suggestions - even innovative practice improvements!

How do you think this is better or worse than the earlier version? Or...indeed..."How can you help?" :-)

Agile In 4 Words - How Can I Help?

Thankyou for supporting!

Agile In Three Or 3 Words

How many times have I heard the following from new clients and other coaches telling stories about their "difficult" clients? That's why I crafted this post!

Agile In 3 Words Is Easy

Actually explaining agile quickly, succinctly and simply for anyone, or any team or any organisation of any size is really easy, if you do the work (inspired by Byron Katie). It's simply you, and everyone in your organisation, and every supplier, client, consultant, advisor, regulator and customer around your organisation offering really often:

"Can I help?"

For agile in 3 words it is as simple as this! The implication is that everyone proacts to help each other all the time with everything from making tea to delivering the most complex system requiring 100's of people interlocking and aligning.

As an agile coach one of the things I look/listen out for when assessing the agile fluency of an organisation is how many times I hear the above line, and especially its followup which is highly noticeable in environments where there is a great deal of proaction - namely:

"Thank you!"

Now, go do the work! Thankyou for reading and supporting! :-)

My favourite coaching tools: Free online Kolb Learning Styles Assessment

Caveats:
As always when dealing with any kind of model that helps us communicate and understand the abstract world of our minds, our existence and relationships with each other, nicely summarised by George EP Box: "all models are wrong, some are useful".

This is a free assessment, and there are several others that you can freely download. I liked this one as it is a "1 stop shop" document that you print out, fill out, score quickly on the reporting sheet, and finally receive additional insights at the end. And anyone can complete this simply and quickly. 

Required:
Internet access
Printer and 8 pages
Quiet space
10-15 minutes

Step 1:
Give the link or 8 page print-out to the coachee: Kolb Questionnaire. Again I think the best time to do the assessment is in the morning, before work really starts.

Step 2:
When the assessment is complete, the coachee and you will have the coachee's 4 Kolb styles - Activist, Reflector, Theorist and Pragmatist allocated to very strong preference, strong preference, moderate preference, low preference or very low preference.

You now have material you can use to support the coaching goals and plans where learning is required. You also have the approach you need when explaining concepts to the coachee - a real time saver and much more enjoyable experience for you and the coachee as compared to approaching from the worst angle.

Personally, once I realised what my preferred/natural Kolb learning approach was, I realised how I could learn better and more quickly in the same amount of time.

The future no longer belongs to those who learn the fastest. The future now belongs to those who learn the right things the fastest. Kolb learning styles assessment is just another practical tool to help me and my coachees discover their best learning method, and give us some "Slack" to identify what are the right things. Really useful stuff!

My favourite coaching tools: Open Question How

I've been reflecting on a multitude of interactions over a number of years trying to improve my speech metaphors, better questions, less leading and less inference.

Along the way, learning about the simple Open Questions / Closed Questions model used a great deal by Business Analysts, as well as facilitators of new ideas and group consensus.

Open Questions are divergent - they cause the person asked to provide new insights from their own subjective experience or beliefs. Typically these are the Where, What, When, Who, How. And not the Why as it is too aggressive for the recipient.

Closed Questions are convergent - they cause the person asked to move forward with their ideas or their decisions. Typically these are the Yes or No, This or That.

Along the way I noticed is that most/all "Why?" questions can (and should) be reframed with the other Where, What, When, Who and How questions.

Further along the way I noticed that with a bit more effort most/all Where, What, When, and Who questions can be rephrased with How. And based on some stakeholders feedback, that's a very good idea as it seemed to unlock many more options and more possibilities in people's minds.

For Example:

• Why did you do that? Becomes
• What did you hope to achieve by doing that? Becomes
• How did you think it would turn out, and how did it turn out?

• Why do you think we should speak to xyz? Becomes
• What do you think we could learn from speaking to xyz? Becomes
• How does speaking to xyz help us?

There are 2 books which have been particularly useful to me, and I am sure there are multitudes others. "Metaphors We Live By" by George Lackoff and Mark Johnson, and "Steps to an Ecology of Mind" by Gregory Bateson - but more on these later! 

Agile In A Nutshell Part 4

About 1 year has passed since I posted my first attempt (Agile In A Nutshell), and very quickly after that one, the second (Agile In A Nutshell 2) and third (Agile In A Nutshell 3)!

And, along the journey this past year, reading through some more random bits of Alistair Cockburn's blog and Martin Fowler's blog (which I always find nuggets in) it occurred to me that Alistair mentioned during his Heart of Agile advanced agile training course a few things.

To the best of my recollection Alistair told the story of how on day 1 of the 2001 first meeting of the 17 folks who wrote the Agile Manifesto, Alistair was facilitating the choice of the word to describe what they were trying to describe. 8 people diverged, and then converged onto "agile". 8 people diverged and converged onto "adaptive".

I wonder now, looking back, what would have happened to the software industry if "adaptive" instead had won the final coin toss / selection process. Of course adaptive is a harder "sell" as it seems so ordinary and so ... common sense.

And that's my point. Yes, "quick and nimble" is the right word to describe what is desirable from any (not just software delivery) process. That would be awesome if all processes we encountered in our moment to moment experience was quick and nimble.

And people would totally freak out with happiness if the process was also adaptive to the specific context it was applied in, correctly by the people applying it.

And that's what the promise of agile is, adapative-quick-nimble. Able to move in a direction at speed, and change direction (due to an unanticipated target movement) without loss of speed. And, achieving that as a organisation of people where information is real-time communicated and hence looking at the organisation as a social organism, it becomes much more responsive to its environment it operates or lives in. That's where the challenge and the benefits lie. The organisation/organism that adapts fastest and best to its changing environment lives to see another day, and if it gets so good at being responsive that it actually achieves an insight into the requirements of the future, and achieves that before any competitor, then its thrives to outlive them another day.

Because marketing is a zero-sum game. Those who learn the right thing the fastest, lead, and then win.

For more nuts, see What Is Agile For! Thankyou!

My favourite coaching tools: The Mindset Works Online Mindset Assessment

Caveats:

A reminder that all my favourite coaching tools - free, online, or other - need to be applied with the sensible cautionary advice from statistician George EP Box: "all models are wrong but some are useful". Remember also that this is about "the other" and the other's perception - not you and not your perceptions! 

Some time after I posted http://change-challenge.blogspot.com/2017/03/my-favourite-coaching-tools-mindset.html a friend of mine put me onto this fantastic Ted talk by Eduardo Briceno during 2017. Since then I have only looked forward!

I highly recommend it to anyone and everyone to watch - more than once! How To Get Better At The Things You Care About packs a number of important truths and is well researched. 

Upon researching Eduardo Briceno a little more over the months after first watching this talk, I discovered his company Mindset Works, and their online mindset assessment tool: What's My Mindset? (amongst other good things like the courses they give, and their blog site).

And it's as easy and simple as that for this one - 8 questions later there is an easy to understand assessment and some advice to follow!

But why bother? Well...those with open and growth mindsets appear to be living happier and more fulfilling lives, and accomplishing more at work. It seems that's quite important given the speed of the changes we're experiencing, as well as the quantity of changes. Both appear to still be rising exponentially.
For extra insights into how mindsets work, and how to work with them, of all the books I have read so far, this one has 2 excellent chapters on the subject, as well as several other excellent chapters!

The Creative Manager (we could all do with one, work with one, or be one!)

My favourite coaching tools: SMART Acronym Update

So I've been using SMART/S.M.A.R.T. for quite a while (http://change-challenge.blogspot.com/2012/06/my-favourite-coaching-tools-smart.html) to help everyone understand the specific Task / Action / Goal / Objective clearly, so that success can be pursued by several people committed to achieving it together!

SMART Acronym Updated!

And along the way, I've come across Tom Gilb, and his 4 foundation rules for improving Specification Quality:

1. Every word, phrase, sentence and paragraph is clear to intended readers (RB: and lowest common denominator MUST be considered here: the newly joined member of the team)
2. Every word, phrase, sentence and paragraph is unambiguous (RB: so a glossary is a darn good idea, especially in abstract knowledge work, aka software delivery; note glossaries / data definitions / configuration libraries were a big thing in software since the 1960's at least)
3. All qualities are quantified (RB: so not faster/cheaper/better/blah...instead: Unit of Measure clearly defined, the meter clearly defined, the current state or measurement clearly noted, and then the future state survival and/or target and/or stretch and/or wish thresholds are expressed)
4. No solution language unless the document is specifying the solution (RB: keep the language in the problem domain/space ie common business layman's terminology)

And through Tom's teaching, Lord Kelvin's "To Measure Is To Know".

Thinking about all the lessons learned, and helping many individuals and teams move towards their desired future states, I've been modifying the SMART I use to mean the following these days:

    S - Specific (following Tom Gilb's #1 and #2 rules)

    M - Measured By (following Tom Gilb's #3 rule)

    A - Achievable (as a sanity check of the S&M against the R and T coming soon)

    R - Responsible person to agitate that this SMART is delivered is <...> (a single person is a must, if only to remind those who have to do the work, or even better, the person who is going to get the Task / Action / Story / Work Done!)

    T - Timebound on or before  

For Retrospectives

If this is a SMART Action that a team is generating from their Sprint or other Retrospective, as facilitator I encourage the Timebound to be on or before the next Retrospective (which the team commits to knowing and understanding what dd-mmm-yyyy that is!)

For Management Tactical or Strategic Objectives

Again the management team commits to the next planning date dd-mmm-yyyy for the Timebound element and we block out the calendars to ensure that happens! Nothing drains morale and energy than constant slipping of important - especially Strategically agreed important - Tasks/Actions/Objectives.

For Individuals or Delivery/Product Teams I'm Coaching

Exactly the same as Retrospectives or Management: we're all talking about changing the Current Reality to the Future Reality. Usually though, individuals are setting target states for the end of the current or next month - ie shorter windows in which to achieve shifts of consciousness and/or behaviours that impact or lead to the outcome they're trying to achieve.

Thankyou for supporting! Let me know how you do!

My favourite coaching tools: The Evening Review

The Evening Review is a great technique for increasing self awareness.

It is deceptively simple – but it is very powerful. The evening review puts the spotlight on all the kinds of vague impressions about how one's life is going so that one can encounter and understand more fully what is actually happening. 

Requirements:

I suggest keeping a diary/journal next to your bed.

The review method:

1. At the end of the day, preferably about 10 minutes before going to sleep, find a quiet place free from outer distractions.
2. Close your eyes, give attention to relaxing your body, quieting your feelings, and as much as possible stilling the activity of your thoughts - aka calm your "mind monkey". Your mind should be quiet and receptive, but remain alert.
3. Now, review your day in your mind, playing it back like a movie, but backwards, beginning with where you are right now, then the time of late evening, then early evening, then the dinner hour, and the late afternoon and so on until morning when you woke up - and even any disturbances of your previous night's "sleep".
4. Throughout the experience it is important to maintain as much as possible the attitude of an objective, detached, non-critical observer, calmly and clearly registering the events of the day, neither becoming elated at a success, nor depressed and unhappy about a failure. The aim is not to relive the experience, but to notice without emotion in your consciousness what were the patterns and their meaning for this day.
5. Finally, write down your general impressions of what happened and anything particular that you have learned.

There are many variations of the Evening Review. In the above form, it is very effective for gaining a greater sense of the whole of one's life.

After you have captured a few days (or many days, weeks, months or years) read through your notes and observe how they affect you. Usually people are surprised by what patterns they discover for themselves, once they just start to collect "the evidence".

And that's really what's required - once you have brought the unconscious into the conscious, suddenly you have greater awareness and from there, you have more choice about how you wish to proceed or act or behave differently - if you so choose. And hence you have more freedom!

Thank you for reading and your support!

My favourite coaching tools: Mindset Evaluation

For sure I was aware of, and thought I understood the meaning of the term "mindset" for a long time. It's only when I went a bit deeper, and upon a great reflective mediation, that I documented all (that I knew of in that moment) of mine. And there were quite a few...over 30.

Then, the hard, but most rewarding work really began.

Evaluating each of them on their merits and on their consequences...which is the first step towards freeing oneself from mindsets that no longer serve the intended positive outcome, but instead have become restrictive to the life that could be led.

As our facilitator told us, before proceeding with the mindset evaluation, look with kind eyes, and be gentle with your self and your mindset. It began its existence to serve a purpose - to protect you and guide you to the future. And it has done its job really well - hence you are alive today, and, if you are reading this and looking at your own mindsets, then it has somehow also guided you to this point where you are given permission to free yourself from this restraining pattern of being.

The 9 simple questions I use to use to evaluate a mindset:

1. How strong (on a scale of 1 to 10) is this mindset?
2. How long have I (or the coachee) had the mindset?
3. What behaviour does the mindset drive?
4. What feelings are behind the mindset?
5. How has this mindset served me (or the coachee) in the past?
6. How has this mindset limited me (or the coachee) in the past?
7. How does this mindset serve me (or the coachee) now?
8. How does this mindset limit me (or the coachee) now?
9. How would I (or the coachee) like it to be?

These question seem simple and innocent enough, but "Oh wow!" do they open up some serious thought and feeling provocations...and these of course lead to deeper realisations.

Interestingly I found some mindsets were much fresher due to a significant later life event, than most of mine which stemmed from childhood and teenage years, and in the fresher ones, I found limits, but I was happy with them as they appear to be healthy boundaries.

Also significantly I found this work incredibly exhausting - mentally and emotionally I was drained after evaluating sometimes just 1, but often no more than 3 in 1 sitting. Simple and innocent questions - I am just amazed what the right framed question does at the right time and place!

Also interestingly, several of my answers to number 7 were - "it does not!", and several answers to number 9 also converged on a similar pattern. I believe these patterns in number 9 were more indicative of my true self trying to be authentic - and hence I am doing this work, so there is quite a bit of synchronicity I believe in this exercise, if it is performed as intended: open heart, open mind, quietly and extensively.

Thank you for reading and your support!

Agile Principles 105

So... if I had reached nirvana state of finding "the 1 best method" to teach and learn the agile principles with my previous Agile Principles 104 post in this agile series...why is there an Agile Principles 105?

My thinking continually evolves as my experiences, perspectives, understandings and, most importantly, synthesising, across the variety of things I do and things I know continues. I never stop exploring the boundaries - and the beyond! :)

The muse for this particular approach came from the advice from Peter Senge's "The Fifth Discipline" on how to create a vision for an organisation that the people own and strive towards. Peter's description of the holographic view of an organisation by each individual employee was/is bind mending!

You'll see (I hope) how each of my previous posts, with alternative teaching styles and variety of learning outcomes, informs my next target state. Hence I try new and improved approaches whenever opportunity meets preparation.

In this case, even off the back of the successful approach to learning/teaching the Agile Principles 104, learners returned to their day job and forgot the goodness of their understanding and experience fairly quickly - unless there was a disciplined framework, a management mandate or a positively persistent coach (like me!) agitating them to remember, and to apply in their thinking.

This approach, I hope, causes learners to converge more collectively onto the same shared understanding of the agile principles by folding-in everyone's understanding recursively.

Its extremely beneficial that each team in the organisation evaluates themselves against the their own and their organisation's interpretation of applying the principles. By spending time as a team in "think space" (reflection) goodness follows "for free"/"semi-automagically". That's the beauty of having an aligned collective mindset - energy, thought, creativity and work flows rapidly and positively due to common understanding and knowledge of the "game rules", and in the absence of interference of any kind.

Agile Principles 5th Approach

• Timebox for 30 minutes
• Ask the learners to read, write (or complete pre-prepared sentence spines) the 12 agile principles onto index cards or similar, and to rank them from most important (at the top) to the least important (at the bottom). A single list - ranking decisions must be thought through and made according to the available knowledge everyone has at the time!
• Then ask the learners to self-organise into pairs and to read and discuss each other's rankings and understandings.
• Now ask the pairs to fold-in their lists. Together they must:
• Agree the most important principle  and record why
• Then agree the least important principle and record why
• Then they need to sort through the remaining 10 to create their own agreed ranked list, similar to Agile Principles 104, and write down Why
• Then ask the pairs to self-organise into groups of 4
• Now ask the groups of 4 to fold-in their 2 lists into just 1, and to tease out (and record) the consensus "Why" for each decision they reach
• Now it becomes recursive - sub-groups keep folding-in together until the entire group of learners is once again 1 group and there is 1 list they all have participated in creating.
• ie, 4+4 = 8
• 8+8 = 16
• 16+16 + 32
• Yes, as the groups get bigger the fold-ins can take longer, but often there is an emergent consensus pattern that helps the fold-ins stay quick, energised, and positive so in my practice I don't see things slowing down, I see improvements in communication and negotiation emerge rapidly!
• Any "odd" numbers just fold-in the next round so if you started with 6 in total, you then have 3 pairs, 1 pair observes whilst the other 2 pairs fold-in, and then merge in the final round the 4+2. It is critically important to fold-in 2 lists to create 1, as this speeds up the event and deepens everyone's shared understanding and personal sense of ownership of the final ordering. 
• Trying to do more than 2 lists at a time, eg 3 lists and 3 groups into 1 creates too much complexity too quickly and often causes people to disengage. There's just a little (too much) friction in the group dynamics that causes energy loss.
• The final outcomes of this approach are
• A shared understanding and ownership of the most important to the least important agile principle as understood by the group
• Clarity and understanding of why the ranking decisions were made
• Practice in avoiding group conflict by smart structuring of group work which is known to create conflict as everyone's personal perspective is a factor when working with knowledge, experience and mindsets.
• 2 Artefacts that can be referenced and reviewed inside the office as-and-when the need arises - typically retrospectives (reflection), and escalations (crisis)

• Now, do the same recursive process for ranking from easiest to hardest to achieve in the organisation.
• The final outcomes are the same 4 as above, but you have also now agreed a backlog of work that needs to be done for the organisation to become more agile.
• WIN!

Whilst this approach is similar to the previous, there is something truly amazing about the folding-in of people's perspectives aka consensus. As well as Peter Senge's book, Sam Kaner also describes the diamond of participation model of group consensus that is incredibly useful and insightful!

For more thoughts and approaches to learning or teaching the agile principles, please read my collector post at What Is Agile For. Thankyou!

Agile Principles 104

After trial and error, doing and studying, reflecting and more reflecting from my experiences of teaching the agile principles as described in Agile Principles 101, Agile Principles 102 and Agile Principles 103, a flash of insight came to me after running some facilitated workshops with clients.

One of the reasons I love to teach is because I get to meet so many inspiring people! Another reason is that I learn so much more, and so much quicker as well!  So teaching the agile principles to 1000's has also helped me learn them, and learn about them in so many ways I could never have appreciated the first time I read them!

Anyway, back to this story! I had been facilitating collaborative sessions with different people in different workshops for a few years. One of the great things that work well in collaboration sessions with any number of people, is breaking up the big group of people to work in sub-teams. Depending on the objective, carefully selecting sizes between pairs/triples/quads/pents/6's produce good results, or better results.

I came across the excellent Training From the Back of the Room and The Ten Minute Trainer by Sharon Bowman who puts these kinds of insights across extremely well!

        

In these books and in her training sessions, I learned the new teaching paradigm - "the person doing the most talking is doing the most learning". 

Talking causes us to formulate abstract experiences in our memory into concrete communication efforts - which means we need to more fully understand those vague things we think we know. It also allows us to get validation and/or corrective feedback from others we share with.

For this learning objective, sub-teams of 4 work best. 

The even number causes much more thought, talking and strong consensus by all sub-team members on any range of logical points discussed, as well as greater emotional impact than other sizes.  These sub-teams cause everyone in the entire session to fully engage in the topic because everyone has a voice and much more likely to be heard. It's true! (and it's common sense...) :-)

I mentioned this approach to one of the younger agile coaches I was working with at the time, and he tried it in his next training session. He came back with positive results. In the glow of the successful moment - he also mentioned this approach to a few other agile coaches...and now it is spreading organically. Nice! :-)

I explained this approach to another 1 of my long-term agile collaborators and he has been using it ever since. Chris C convinced me to blog this approach so that everyone gets the benefit. And now I have. Enjoy!

The method

• Timebox the whole module to 30 minutes
• Ask the trainees to self-organise into balanced groups of 4 - they need to discuss and figure out what balance means to them. Sometimes it is gender, age or role based, or combinations of all these and more. Balance is always good thing to discuss and dive deeply into.
• Ask them to self organise the writing of the 12 agile principles down on large super sticky post-its, in a 3 minute timebox. They need to coordinate and work fast together.
• Ask the teams to rank the agile principles from the most important (at the top) to least important (at the bottom) in single list, in a 5 minute timebox.
• Ask each team to number each post-it with eg a black pen so that we can know later what the ordering was.
• 1 person from each group then volunteers to give the entire group a 30 second pitch timebox about why they chose the order they did - highlighting the decision making as well as perhaps any contention in the team.

Agile Principles Explored By Team

Post Mortem 1: Much deeper understanding of what is important and why to the organisation and how that is reflected in the ordering of the agile principles that cover people, process, technology, customers, market, culture and pretty much every other "lever" an organisation has

• Optional, fold-in
• Get each group to pair with another group and then combine their orders into 1 consensus ordering of the 12
• Repeat until all groups' 12 principles are folded into 1 single consensus list and the big group is whole again. Any odd number group waits until the next round when there will be even number groups again.
• Update the post-its with their "global" ranking

Now, ask them to return to their original sub-teams in front of their own post-its. Take all the post-its off the wall to reset the next round of ranking.

• Ask the team to now rank the agile principles from the easiest (at the top) to the most difficult (at the bottom) to achieve in their environment, in a 5 minute timebox.
• Again number them, this time in a different colour pen eg green
• Again ask for a group's volunteer to tell all the others what their ordering is, and why, in a 30 second pitch timebox.

Teams Come Up With Different Agile Principles Priority Orders Based On Their Context and Interpretation

Post Mortem 2: Much deeper understanding of the art of the possible in the organisation as people disagree from their own experience and perspective what is easy and what is difficult. This can be a heated conversation when senior managers are involved but, in terms of creating that shared understanding of reality, invaluable to bring on and manage the friction!

• Optional, fold-in
• Precisely as before, "pair" the groups and get them to create a single consensus list of easy to difficult
• This one will probably require much more time as people generally have totally different perceptions, but this is also the beauty of transparency and shared understanding.

The Final Post Mortem

Deeper ownership, accountability and understanding throughout the aligned trainees - win! Also, the opportunity to use this output to create the initial backlog to become more agile - i.e. transformation begins with everyone on the same starting block/page. Ie, win, win, win!

Many people - myself included - had horrible experiences and/or horrible feedback from our time in school or post-school education. As a result, some became uncomfortable at voicing their opinion or knowledge in front of others. Groups - especially large ones - intimidate most. 

This approach helps everyone to connect with fewer people and share+receive a lot more as a direct result. Hence the learning that happens actually is deeper and hence more useful and usable for trainees. The optional fold-ins suggested, though they take a little longer, cause deep alignment amongst attendees. And you can use this approach for many other topics, and not just for training modules - workshops too!

Definitely this is a great approach, if not the best approach, to teaching and making the agile principles much more "sticky" in the learners' hearts and minds.

For my full collection of hard ground, hard sought, and deeply dug pearls on agile mindset f0undations - please read What Is Agile? Thankyou!

Agile In A Nutshell Part 3

Okay... I don't know if you noticed... but it is really really hard to really curate an agile in a nutshell post that is quick to read, grasp and move forward. This is partly why I avoided much agile postings over the past decade - it's a very very long piece of string (or rope to hang oneself with)!

:)

The previous 2 attempts at this (Agile In A Nutshell and Agile In A Nutshell Part 2) I like and I teach fluidly. But I also add the following nugget when I am teaching.

Where did these agile manifesto, the 12 agile principles, and especially those 10,000 odd agile practices (half of them technical/technology focused like pair programming; and half of them people/organisation/management/process focused like standup meetings) come from?

Well it's clear where the agile manifesto was written and by whom in 2001 - 17 world-recognised software engineering consultants, coaches, managers and all importantly - practitioners.

And it's clear as well where the agile principles were written and by whom in 2004 - the same experts that formulated the agile manifesto.

But what about those 10,000 agile practices?

The agile practices have been observed by team members, team managers, coaches, consultants, and other observant people ... of high performance teams. These observers have then documented them online, or in books, and have presented them at conferences as well as internally. 

This means that we're still discovering practices all over the shop/place that help organisations become quicker and nimbler.

In my opinion, the smartest organisations are recognising their own unique practices that are giving them competitive advantages, and keeping them secret. The even smarter organisations are making their unique practices transparent and world-wide accessible because they realise others may contribute small tweaks that give even better performance - ala open source.

They also recognise that thinking is really hard to replicate and their organisation as a whole organism is thinking differently and hence behaving differently. Behaviours are easy to observe and replicate, but does not mean you will get the benefit.

Countless stories abound how GM documented all the things Toyota was doing in their factory in Japan and tried to replicate in the US - but failed. And we see that quite a lot industries - competitors hire people from the other organisation (or the same consultancy!) and then try to copy what worked elsewhere - and it usually fails expensively, spectacularly, and hurts a lot of employees, shareholders and stakeholders.

The simplest way to deeply understand this is a story about a piano made by a world famous piano maker. A wood furniture carpentry company decided to move into the piano manufacturing business as they had the same required tools, they could buy the same materials, and they thought they had the same skills required. So they bought a piano and dismantled it, making notes and designs about how to assemble. Then they assembled it back. But once it was back in "1 piece" there was a problem. It did not sound like it had. So they tried to manufacture a new one from their instructions. And they succeeded in making a pretty good replica of a real piano, but once again there was the problem - it did not sound right. So they got out of the piano making business (wisely). They lacked the "secret sauce" of being musically minded and aware how all the complexity of sound generation, amplification, transmission integrated with the different moving complicated parts of a piano.

And that's also what agile is - the practices help - in the same way that knowing what the keys of a piano are what notes. But playing a piece of beautiful music on a piano is differently from knowing things about music and piano operations. Yes the analogy does stretch to "practice is required, and feedback" to get them right.

But more importantly it is the secret sauce - it is the agile mindset that causes these agile practices to evolve into something unique for the organisation and its context. Some practices are individual targeted (like disciplined arrive on time to meetings), some are pair targeted (like pair programming to create, quality assure, reflect, learn, and make better realtime), some are team targeted (like whole team planning game), some are larger organisation targeted (like town hall meetings), some are senior management targeted (like go-and-see/use-your-legs reporting walks). And on and on :)

It is much more important to be agile than to do agile!

For more and deeper thoughts about agile check What Is Agile For You What Is Agile For Us. Thankyou!

Agile Principles 103

So I was frustrated with both my previous 2 methods as described in Agile Principles 101 and Agile Principles 102.


Suddenly! I found myself with a group of complete agile newbies and I realised I had the opportunity to experiment with a 3rd method to try and help them understand these really concise pearls of modern management wisdom - the agile principles. By this stage in my career and experience I had convinced myself that the agile principles were just as relevant for software as for any other knowledge work taking place with large numbers of unknowns and lack of certainty. The plan-do-study-adjust collaboratively is remarkably effective in all conditions and circumstances where we're doing something new (more than 10% different from previous experience)!

My third approach involved the learners reading them, leaving them on screen, and then asking targeted questions. I was hoping that by causing all the learners to think and reflect on their own situation, using the principles as some kind of wise "flashlight", they would have flashes of insight!

Questions that I asked:

• Which agile principles were they achieving in their work 100%?
• And why?
• Which agile principles were they not achieving in their work 100%?
• Why?
• Which principles were they achieving between 0-50%?
• Why?
• Which principles were they achieving between 50-100%?
• Why?
• Would you be agile if you followed 11 principles 100%?
• Why or why not?
• Of those that were not 100% in practice, which 1 putting fully into practice would bring the most benefit?
• Why?
• Which would bring the second most benefit?
• Why?
• Which would bring the third most?
• Why?
• And which would bring the least benefit?
• Why?

Typical answers that I received

A lot of concerned faces, puzzled frowns and a handful of the class beginning to figure this stuff out. Reviewing these responses made me cringe - I am sure often my look of disbelief crept past my ability to control my responses. Reader beware!

Which agile principles achieving 100% and why?

• Retrospectives (the last one) - because "our Scrum Master makes us".
• Delivery of working software - because "that's what we're here to do". (note, no mention of trying to deliver quicker - with an emphasis on the shorter timescale)

Which agile principles not achieving 100% and why? 

• Business people and developers did work closely, but not everyday - because "the business people were too involved or important for the business to operate without them".
• Sustainable development - because "our company encourages a good work-life balance, and we only come in for the weekend once per month, or work late nights 1-2 nights per week".
• We do welcome changing requirements but not near the deadline - because "then we would never finish".

Which principles achieving 0-50% and why?

• Technical excellence, best designs, and simplicity - because "we don't have time to improve".
• Build projects around motivated people and support them - because "we hire professionals and they have to adapt to our ways of working".
• We think we do satisfy our customers of our business - because "we don't know them and are not allowed to talk to them" or "knowing - that's someone else's job"

Which principles achieving 50-100% and why?

• Communication is good, we do face-to-face whenever people are close - but not if they are on a different floor, different building up the street, in another town, a different country or timezone - because "travel is expensive and wastes a lot of time" and "we need email trails for audit/regulatory purposes" or "we need emails for our monthly, quarterly or annual appraisals".
• We like software showcases, but we have a lot of reporting on the side/top of that - because "governance is required" or "regulatory" or "comfort factor for senior managers" or "good publicity for the good work we're doing"

Would you be agile if you were only achieving 11 agile principles out of the 12 - why or why not?

"Yes! Because that's pretty good, it's like 91-92%!" - note, no mention of which one is not being achieved! Just a simple, naive response to the a multi-choice answer sheet. No deeper thinking evidenced.

and

"No! Because there would not be 12 principles if following 11 made an organisation quicker and nimbler!" - note, although this answer is better than the "Yes", this is still insufficient/a bit naive as the principles are a set of cause-and-effects that together create the synthesis required to be quicker and nimbler. It takes deep thought and putting into practice for some time to fully "feel" agile.

Which principles should be our top 3 to put into practice ASAP, and why? 

The only typical responses I got from this question were that there were no patterns. Every organisation has a different context, with different problems (and size of same problems), prioritised differently and solutioned differently. This is expected. Asking the "Why" for each did cause good conversations between the trainees and really helped people clarify their assumptions and perspectives. So too was the conversations around benefit, and benefit to whom. Good stuff!

Which principle would bring the least benefit and why? 

Again, a total myriad of responses - the only pattern being that everyone fell for this "trick question".

Yes, like most agile things, with teams being in unique contexts, "it depends" is always the right answer. But that helps no one quickly!

Once the trainees had convinced themselves of 1 least beneficial principle, I always constructed a causal model that showed they had picked the most beneficial principle to them. Why this complete opposite approach? I was trying to highlight all the other ways of thinking about things, and highlight that they needed to learn more than their default model in order to achieve agile for their organisation and for themselves.

Benefits of this teaching/learning approach

Was better, slightly, than the previous two attempts.
There was some good discussion going on.

Consequence of this teaching/learning approach

The causal model for the 1 principle they believed would bring them least benefit seemed to cause hostility. Just because Copernicus had a model that proved the planets went around the Sun, did not win the hearts and minds of those who believed the Sun and the planets went around the Earth, especially not those with their own thinking and being models based on the incorrect one!

Several folks dis-engaged from this - I suspect because it is such abstract stuff and it is hard to think about abstract things with people who have different contexts entirely. It's hard enough to make sense of things with people who are on the same page with you let alone from different teams/streams of work!

Post mortem

This teaching/learning method also did not work as I had hoped. Despite many nods, smiles and hope-filled looks that seemed promising, nothing happened after the training session.

I did not see changes in thinking patterns, problems stated, solutions proposed or behaviours. There was no increase in flow of value nor deepening of team trust, no sighting of a high-performance shift or team. No one was picking up the seeds or threads and putting any of the collective wisdom onto the agenda and getting faster.

I had to keep researching, thinking, reflecting and trying different things as no one is really talking or writing about this stuff - how to reach critical mass across the whole world! To see what I have tried, tested and concluded so far, read further: What Is Agile For You, What Is Agile For Us. Thankyou!

Agile Coach Interview And Selection Questions

Years ago I was hiring agile coaches, and working closely with a hiring partner who was really really (!) good at finding talent. I had no time, he had some time and was keen to help me in any way we could figure out how. I knew agile, he knew recruitment. I knew coaching, he knew people.

The first round questions that I designed then still hold true today. I was inspired by Joel Spolsky's 12 questions candidates should ask their potential employer before deciding to join back in 2000. It may be a little old in some circles by today's standards, but it is still insightful imho:

The Joel Test:

1. Do you use source control?
2. Can you make a build in one step?
3. Do you make daily builds?
4. Do you have a bug database?
5. Do you fix bugs before writing new code?
6. Do you have an up-to-date schedule?
7. Do you have a spec?
8. Do programmers have quiet working conditions?
9. Do you use the best tools money can buy?
10. Do you have testers?
11. Do new candidates write code during their interview?
12. Do you do hallway usability testing?

The neat thing about The Joel Test is that it’s easy to get a quick yes or no to each question. And that's what I needed from my first round interview questions that anyone, even a non-agile-skilled or non-agile-knowledgeable person could use. So I came up with 24 quick questions, and we got some truly great candidates making it through the face-to-face screenings.
One of the most (perhaps THE MOST) important things about an agile coach is their experience. Money can't buy experience. Reading about other people's experiences, or attending courses based on other people's experiences is not the same as having the direct hands-on "did the best I could with the information and knowledge I had at the time, and nothing worked...until...after much persistence and many failures something worked!"

All experience is relevant. I am wincing at how arrogant I was when I was younger thinking that attitude mattered more than experience. They are equally important - it all depends on the problem space and time! The thing about people without experience in a particular space, is that they don't know what they don't know. My 24 questions highlighted things that were relevant for the different openings we had going at various times. A quick 10 minute Yes/No followed by a few initial typical HR availability, package suitability, location, role etc matching minutes and wallah - 1x effective initial screening for very cheap!

The very few who made it to face-to-face interviews which were experiential and enjoyable for both the coaches and the candidates highlighted the right candidates each time! Happy daze! (especially compared to traditional candidate screening processes and pains)

Rob's Agile Team Member or Agile Coach 24 Question Assessment:

1. Do/did you use source control?
2. Do/did you not use source control?
3. Can/could you make a build in one step?
4. Can/could you not make a build in one step?
5. Do/did you make daily builds?
6. Do/did you not make daily builds?
7. Do/did you have a bug database?
8. Do/did you not have a bug database?
9. Do/did you fix bugs before writing new code?
10. Do/did you not fix bugs before writing new code?
11. Do/did you have an up-to-date schedule?
12. Do/did you not have an up-to-date schedule?
13. Do/did you have a spec?
14. Do/did you not have a spec?
15. Do/did programmers have quiet working conditions?
16. Do/did programmes not have quiet working conditions?
17. Do/did you use the best tools money can/could buy?
18. Do/did you not have the best tools money can/could
19. Do/did you have testers?
20. Do/did you not have testers?
21. Do/did new candidates write code during their interview?
22. Do/did new candidates not write code during their interview?
23. Do/did you do hallway usability testing?
24. Do/did you not do hallway usability testing?

After you have all the "yes" and "no" responses to these, you will know the level of "modern" and "old" styles of developing and delivering software. Now you get to decide how to direct the rest of the experiential based interview if you decide to let the candidate through to face-to-face more investment round(s).

I advise experiential interviewing during the face-to-face as it is a case of "under stress, we regress", and a lot of coaching can be quite stressful as very little is under the control of the coach who is at best influencing the situation! And any coach who has not mastered conflict management and resolution skills, personal attacks, helping people overcome their own anxieties etc can be quite damaging to your organisation.

f you're more focused on a coach who's technical background is less interesting, you could take a look at the coaching levels and the types of coaching and design similar Yes/No questions to try and understand the tangible hands-on experiences a personal, executive, soft skills, etc coach has.

I suggest at the beginning of the face-to-faces to do some spot-checks to check that whatever Yes/No questions you screened with were correctly interpreted, and that the candidate's response was accurate before proceeding into the simulation(s). Some people, you know, will say anything to get a role! :O

After the simulation assessment(s), ensure you and your assessment team form and document your own, subjective, fact-based, Delphi-style, assessments of each candidate.

My final question for the candidates: Ask each candidate face-to-face what their opinion is of the other candidates. You'll be or not surprised how many candidates know, or know of, the other candidates, and their face-to-face opinions can be quite informative! Also insightful is how they react to those coaches they don't know or know of.

So hopefully by now you have collected all the minimal data points to make a more informed decision about finding the right candidate - a round peg for a round hole / a square peg for a square hole - for your people's (!!) needs. Remember, past performance is no guarantee about future performance. But also remember this is a critical role to match the right person to - as any change agent will by the nature of the role be disrupting people's comfort zone(s). Including your own often.

Good luck with your search and selection process!

Lastly, please let me know how it all works out for you and your organisation. Remember the most important (top) line of the Agile Manifesto reframed is a bit like "we're doing it, and by doing it we discover new and better ways of doing it, and we share with others what we have learned so that we all benefit". That's "agile"!

Thankyou for supporting!