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!

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!

Book Crossing Is Cool

Towards the end of 2016 I was at a course and 1 of the attendees mentioned "Book Crossing" and explained it as leaving and retrieving books people have placed in all kinds of places.

Finally I got around to actually researching what I had heard around September 2017. Since then I have have placed 46 books out there and am hopeful that eventually people will begin to enter reviews, or at least little comments of some kind on my bookshelf (http://www.bookcrossing.com/mybookshelf/agilecoachrob).

http://www.bookcrossing.com/about does a pretty good job of explaining what this is all about really. I think one of the most fascinating things that will emerge from this social experiment running since 2001, is the way the membership (http://www.bookcrossing.com/findmembers) will change, and some kinds of insight that will emerge of where and when books are released, and then where, when and how will those books travel to their next release point. Maybe even luckier some kind of "pure" trend about which books are more popular really / unbiased by reviewers, publishers, book sellers, prizes or any other kind of "public persuasion".

Who knows - but I am still hoping that people will pickup one of those 46 and update the locations, leave their own reviews, etc and continue this fantastic social experiment! Thankyou for supporting!

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!

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 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 Principles 102

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 content produced much better results. Instead of showing the trainees scenarios that were successful and then debriefing, they showed unsuccessful scenarios and then debriefed the errors. 

Scenarios where fire fighters in their rush to save took personal risks, overlooked snagged hosepipes, did not operate the hosepipes and ladders effectively as 1 team, etc. And the result of these individual, and at first glance, minor errors, rescues failed, blazes were not extinguished and fire fighters were injured or died. Debriefings of these failure scenarios caused the trainees to learn (a lot) more, and (a lot more) quickly, which was quickly demonstrated by these new crews having much higher percentage success rates, and most importantly, fire fighter injury and death rates!

Similarly in the UK, I've heard that people who've had driving points deducted from their licences are shown videos of accidents that were caused by speeding drivers, intoxicated drivers, drivers in non-roadworthy vehicles, etc. Learning from the bad impacts us more, and teaches us good.

So...I thought I would apply this principle to teaching the agile principles.

For many many classes, I spent a few more minutes on the same slide I used previously (how lucky to not have to "waste" any more precious slides on this foundation to the whole huge "agile umbrella of knowledge"!

This time I did not reveal the "masterpiece single slide" in a single click. Instead I made use of PowerPoint's fly-in, appear, and other "On Click" events to have the bullets appear as required (some lines are longer or more complex than others, so give the trainees a few extra seconds to read and understand, occasionally - I am such a nice trainer!)

So now I had the class read 1 principle at at time, and after everyone finished reading the current principle I asked the class - "What effects would happen if you/we did this?". Followed by "And what effects would happen if you/we didn't do this?".

Typically the 24 DO / DON'T outcomes (which I hoped were deep realisations embedded forever in the learners' consciousnesses) were similar to below:

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

DO:        Happier users getting valuable features earlier

DON'T: We don't satisfy our users, sooner or later we lose our jobs

Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

DO:        The development team adapt whatever we/they do to accommodate users' changing minds
DON'T: We build the wrong thing, we don't satisfy our users, sooner or later we lose our jobs

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

DO:        Happier users getting features preferably every few weeks or few months
DON'T: We give our users unusable software quarterly, half-yearly or annually only, we (in)frequently upset our users, we lose our jobs.

Business people and developers must work together daily throughout the project.

DO:        The business and developers work together and become 1 balanced team
DON'T: Business and development don't understand each other, don't know each other, don't work as a team, so the environment is low trust, low knowledge, low productivity, work and value does not flow, and people are stressed and unhappy. No one is satisfied with anyone, including ourselves, blame game is played often, so eventually we lose our jobs or we leave our (bad) jobs.

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

DO:        Hire good people, support them, they are super motivated and do the best job they can

DON'T: Don't support our people, give them bad environment(s) in which to do complex work, don't support them, and continuously interfere with how they do what we ask for. People get frustrated, and either they leave their jobs, or eventually lose their jobs because they're just blocked from doing (enough) good.

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

DO:       Less documentation, fewer/no hand-offs, more quality conversation which is better for conveying difficult abstract details and concepts to each other. More productivity time.

DON'T: Convey information to each other in the least efficient and least effective ways, resulting in miscommunications, misunderstandings, and a lot of wasted time, effort and money. All this waste results in unhappy business people, we lose our jobs.

Working software is the primary measure of progress.

DO:       Everyone believes the development team's progress "report" as it is clearly running in front of eyes and fingers, or not, and hence everyone can plan more confidently based on realtime, real, information.

DON'T: Measure progress by some other means - maybe Red-Amber-Green "traditional" governance reports, Earned Value Burnups, (C)RAID Logs, and we plan based on those abstractions of progress, and quite often those abstractions are not reality and may be quite stale at moment of understanding. And when progress reports are not reality, a lot of wasted time, effort and money goes into that "cottage industry" for negative Return-On-Investment (ROI) and the organisation's plans are wrong. This results in unhappy business people, and ... job losses.

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

DO:        Everyone goes together and works together. Few surprises. No late night and weekend work for anyone. Morale stays high and energy levels are protected and nourished.

DON'T: People work late nights, weekends, get tired, get grumpy, produce bad quality plan/artefacts/tests/requirements/analysis/code/architecture/designs/workshops/sessions/meetings/etc. Boom-and-bust cycles. People miss their personal lives, they leave their jobs. Quality suffers, the users and company suffers, and ... job losses.

Continuous attention to technical excellence and good design enhances agility.

DO:        Our codebase remains cheap to maintain, nice for people to work in and learn from, and we can realistically and constantly "welcome changing requirements, even late in development" from Principle 2 above. :-)

DON'T: Our legacy codebase becomes expensive to modify, it is no longer "soft"ware, it has become "hard"ware, and people hate working in it because little changes require great effort and introduce great uncertain risks that developers are unable to easily (if even possible) mitigate and hence the developers appear to go slower (but actually they're doing a lot more difficult cognitive work!). It creates cognitive dissonance in developer's minds and this is tiring and annoying, so they get sick of it physically due to stress and sickness rates are higher than "normal", developers/analysts leave temporarily on long-term illness, or leave the role, or something blows up in production, and after a short period of job creation (Operations needs more people to deal with poor Change/Development/Tech/etc outputs) ... eventually job losses.

Simplicity--the art of maximizing the amountof work not done--is essential.

DO:        We keep things simple, we save effort, time and money, so more productivity and happier users!

DON'T: We overcomplicate things, waste a lot of effort, time and money, sometimes even make quality worse. We maximise workload, decrease creativity and innovation, and people leave their jobs, or we lose in the market place and eventually lose our jobs because our competition is quicker with new features and products.

The best architectures, requirements, and designs emerge from self-organizing teams.

DO:        The team knows their design, requirements and architecture inside-out, back-to-front and can confidently do things at speed, knowing "where the skeletons are buried", and where they risk nothing, a little, some, more, a lot, or "bet the whole farm" - when they have to.

DON'T: The worst architecture and worst requirements are pushed onto the team who don't understand or know them evenly or equally well, and hence unintentionally build the wrong things in the wrong ways and nothing integrates or works properly, or worst developers paint the whole codebase into a corner. The users and business people get upset as the investment is lost, developers ... lose their jobs.

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

DO:      We continuously learn and improve and become stronger as a team - we become a high performance team that can do anything.
DON'T: We keep doing the (every) thing(s), the same way(s), we never get better, we never modernise our skills, we get bored, we are boring, we are overtaken by other teams, we look bad in comparison, we ... lose our jobs.

In a nutshell, the benefits of this teaching/learning agile principles approach are:

1. The trainer can "tick the box" on the "we covered the basics" section / poorly defined learning outcomes
2. Only 1 slide!
3. Only 1 page to print for the pack for the attendees! Save the trees! Save the planet!
4. It's much better than just a single slide of reading and a short FAQ (aka  agile principles 101) before moving on as some of the learners do engage with the thinking process and take some of the messages into consciousness!
5. There is some interaction with the trainees!

The consequences of this teaching/learning agile principles approach are:

1. Not enough positive effect or impact on the learners
2. Some negative impact on many learners as they begin to feel that agile is being forced on them, that it's "go agile or lose my job". "People don't resist change, they resist being changed." - Peter Senge
3. Some learners feel left out and/or confused by this session - seriously only 1-3 louder folks engage passionately with this approach
4. Learners realise the trainer might not be a good one or the training content might not be good

Post mortem: 

Did you notice who gets more benefit from teaching the agile principles like this? Who is not getting benefit? What about all the negativity taste in the mouth at the end? 

"go agile, or lose your job!" is not a positive message nor a reasonable call to action! Look how well "Stop smoking, or die!" or "Lose weight, or die!" is working in the health industry. It's not that these things are not true to some degree, it's that they're also false to some degree. And the framing does not allow for that "shade of gray" - so people can spot just one counter example and choose (with logic) to disbelieve all of what the principles are trying to encourage understanding of.

This approach does not work well enough. A negative call to act only works when the person called this way really believes that they will actually die otherwise (a gun to the head, and someone's finger on the trigger, and no doubt they will pull it unless you do as they say), and even then, a substantial number of people (and in team work, you only need 1 to be out of alignment) will freeze or flee in different direction. Some will evenly actively fight against it - sabotaging, cynical outbursts, campaigning, using Schopenhauser's methods to win any argument. 

A handful of learners will become more aware of the big picture and hence will support because they believe. But that's not good enough unfortunately!

Also, the summary interpretations are a HUGE gap from what the principles are actually saying!

Users and customers are not always the same thing! The market place - the fact that every software team member is facing off to the market place no matter if they are the networking engineer, database guru, feature team member, scrum master, product owner or any other role required to get the software Done, is overlooked - even in this approach. And this is fundamental - that's why the highest priority is called out so explicitly at Number 1 position!

Every line of code or configuration or content that in some way supports the objectives of the business' service to its customers is either "for" or "against" success in the market place. The principles are trying to make "IT" folks aware of this, as most are blissfully friends with their computer and that's most of the extent of the engagement with the firm they work for. They can't see the tight chain of inter-dependence that truly exists between how quickly and cleanly and consistently they work, with how well the end customer perceives the company.

This approach is more effective than the industry standard agile principles 101, but it causes a lot of hostility quite quickly and hence is simply not effective.

Don't teach or try to learn the agile principles this way. Rather use this as a thought experiment (or 12) once you have taught or learned them in a more positive way. I'm documenting my experiences via my earlier post What Is Agile For so if you are interested, read the other methods linked there!

Thankyou for reading! Let me know what you think!

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!

How To Really Teach The 12 Agile Principles Mindset - A Mystery Mastered

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, right?!!? 

And of course then another timebox for 4 minutes for Questions - "Are there any questions about this?" - kind of "emperor has no clothes" style - 99% of the time no one would ask anything. Probably because the principles are so simple to understand - people looking around would see their colleagues, managers, unknown strangers nodding knowingly! Perhaps even smirking with that secret deep understanding!

And, no one ever wants to feel uncomfortable - especially not by asking an obvious (to everyone else) question to clarify their own understanding, their own perception, their own experience!

Here's what that slide typically looked like (it hurts me just to revisit the old old decks!)

Notice how neatly all 12, and the title, fit really neatly onto 1 slide! Win! ;-)

I particularly like the tiny font size, and the bullets! Wow! Those bullets - they really draw attention to what's so very important to make sure the 12 principles of agile successfully transfer off the presentation and into people's consciousness, and cause the learners (?) to change their way of thinking, of being, their behaviours and thus the real target - their way of working to being more productive with the limited resources and time they have available!

Now for some truth of this widely used, common, dare I say - standard or best practice - approach...

In a nutshell, the pro's of this approach are:

1. The trainer gets at least a 6 minute break
2. The trainer can "tick the box" on the "we covered the basics" section / poorly defined learning outcomes
3. Only 1 slide!
4. Only 1 page to print for the pack for the attendees
5. Lots of nods from the trainees - the words do seem sensible - which makes all trainers feel good inside!
6. Very few questions (in 4 minutes) if any, and, no time to get into any real detail of either the trainer's experience(s) or learners' experience(s) - so only quick superficial answers or "park that one" statements to move along!

The con's of this approach are:

1. Zero positive effect on the learners
2. Sometimes negative impact on the learners as they begin to logically unpack and envision applying in their own organisation and discover stumbling blocks with all or nearly all of the principles!
3. Learners feel rushed
4. Learners realise the trainer might not be a good one or that the training content might not be good

Post mortem: 

Did you notice who gets more benefit from teaching the agile principles like this? Who's paying the money? Who's earning the money? Is it a fair exchange?

No one can apply anything that is read from a densely packed and boring slide like this! The agile principles are too concise and need expansion/discussion to help people interpret them correctly singly and collectively, and within the context of the learners which is unique from group to group, team to team and individual to individual. It's a subjective perspective thing!

I suggest don't teach or try to learn the agile principles this way, please. It's simply a waste of time and energy. I have many more experiences and ideas which I am sharing on What Is Agile For

* Seriously!!? Who can learn something as simple (NOT!) as ballet or agile (or anything else of real substance that is life changing) after only 1 or 2 days on an expensive course for which you get a certificate/certification/membership!!? Certifiable/certified maybe. :-)

Make The Agile Principles Real, Make Them Useful, Make Them Usable, Or STAY HOME! "Hey, teacher! Leave these kids alone!"

Thankyou for supporting! Best wishes on your journey!