Showing posts from 2017

My favourite coaching tools: SMART Acronym Update

So I've been using SMART for quite a while ( 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!

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

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)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)All qualities are quantified (RB: so not faster/cheaper/better/blah...instead: Unit of Measure clearly defined, the meter clearly define…

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:At the end of the day, preferably about 10 minutes before going to sleep, find a quiet place free from outer distractions.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.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 morn…

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 p…

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 p…

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/qua…

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 wer…

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 principle…

Agile In A Nutshell Part 2

Okay, so I tried (really really hard) to capture the essence of the vast topic "agile" in my Agile In A Nutshell post earlier ... but something is bothering me.

So I hope you don't mind if I give a second dimension to this massive multi-dimensional concept.

Agile as a mindset and a movement started out in the software development and delivery space. But my first brush with "agile" as a concept was when I was studying business management in South Africa around 2003. The South African management textbook that mentioned "agile companies" stated that the future of businesses relied on them becoming more agile to keep up with customer needs. Although this was after we had implemented much of eXtreme Programming (XP), it was still before (because South Africa has/had very slow internet connectivity, and expensive imported books were scarce) the big software movement really got going worldwide.

I reckon it is likely that the line in that South African manag…

Agile In A Nutshell

By the dictionary definition:

agile - quick and nimble

This is totally normal for a gymnast or a professional athlete in a sport like basketball, squash, surfing - one has to be in a constant state of dynamic balance. Able to go in a direction at speed, and also to change direction without (much) loss of speed.

What this means for a person in an organisation - not much. It's not so useful to be the one dynamic balanced player in an organisation where no one else is. The capability is usually lost in the inertia of the group that is not thinking, deciding, and moving in the same way.

But, for an organisation that is truly agile - like a high performance team - the benefits are great. The whole organisation is quick and nimble - able to chase market opportunities, and able to shift product, features, target new markets, respond to customers, manage crises well and innovate constantly because everyone is playing the same game together.

That's what people are after. The agile mod…

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 insightful still imho:

The Joel Test:
Do you use source control?Can you make a build in one step?Do you make daily builds?Do you have a bug database?Do you fix bugs before writing new code?Do you have an up-to-date schedule?Do you have a spec?Do programmers have quiet working conditions?Do you use the best tools money can buy?Do you have testers?Do new candidates write code during their interview?Do you do hallway usability te…

Agile Principles 102

So, I was looking around for how to make my teaching of the agile principles much better than my and the class's experience of them as per "industry standard" captured in my earlier post: agile principles 101.

Somewhere along my many readings over the years, I came across an article describing changes to the teaching method for fire fighter training used somewhere in the US (to the best of my recollection). I've hunted for the reference but have not found it again (yet) unfortunately.
The fire fighter training story went along the lines of teaching trainees by having them watch videos of fire fighter crews operating in various scenarios and then facilitated debriefing of the elements that made each crew successful. Apparently this change to the previous training method was marginally better as there was a minor percent improvement in successful rescues / blazes extinguished / fire fighter injuries and deaths.
Then someone discovered that a small change to the conten…

Timebox Rules For Better Time Management

For many years I studied techniques and practices of time management. Partially for my own sanity, and partially in an effort to help my team or the organisation I was consulting or coaching become quicker and nimbler (aka "agile"). I picked up lots of cool one-liners like "survival of the fittest" is incorrect in modern management philosophy - these days it is about "survival of the ones who learn only the right things the fastest".

So on my journey I realised I also had to study prioritisation theory and practices. Surprising to me at the time, time management and prioritisation are 2 sides of the same coin effectively - especially in light of what it takes to survive (let alone thrive)!

Although there is a good Timeboxing writeup on wikipedia, I found it was too theoretical and not usable for people who had not tried many different options, nor did they want to read all the references to understand how to implement!

The below rules I came up with for …

Agile Principles 101

So I spent the first few times teaching the Agile Principles in the way that I was ?taught? on a very expensive public certification* and it was the way I saw all the other agile coaches and trainers doing it. Peer pressure - even for an agile coach or agile teacher - is a tough thing to deal with! 

So too is that excruciating inner desire of wanting to teach all of the things (especially the things that took me a long time, and I learned the hard way)! But you only get a few minutes, hours or days in the lives of those whom you wish to help and there is a limit to how much of an impact you can make in those few short moments of time!
So 1 MS PowerPoint slide would go up, and the class would read the slide and the words silently. (How did I even know they were reading? Or were they just pretending to read so they could go home earlier?)
I would timebox this reading exercise to 6 minutes, as there are 12 of them. And everyone can read and understand complex phrases within 30 seconds, righ…