Friday, 24 March 2017

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. Thank you!

Monday, 13 March 2017

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.

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.


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?

Thursday, 9 March 2017

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.