Double loop learning

I do apologize about the white space. I made the mistake to type this in word and use a table and then failed to figure out how to get it into blogger nicer than what you see below. Hopefully the content is in there and that is the important bit ;)

This was a session led by Benjamin Mitchell. He got me
interested in the topic because this were the first 3 words he said when he
arrived ;) There were a lot of people in this session and I was late so I do
not have the names instead I focused on trying to capture as much as I could.

The main idea as far as I understood is that there are a
couple of behaviour models when talking to people and based on which you choose
you get different value in the response. The goal is to choose a strategy/model
that allows you to generate learning (double loop learning) rather than to
close the communication loop and generate... Nothing?!

So this is how it looked like:

Governing variables	Action strategies	Consequences
Model 1 -          Win, do not lose -          Achieve your purpose -          Suppress emotion -          Emphasize rationality	-          Control  environment -          Track -          Protect self	-       defensive relationship -       little public -       reduces valid information
Everything above characterizes single loop learning We revert to this mode when we feel threatened or embarrassed
Model 2 -            Valid info -            Feel informed and have been given choice -            Internal commitment	-      Shared control -      Illustrate evaluations -      Surface conflict views -      Encourage public testing	-       High freedom of choice -       Increased likelihood of double loop learning -       Minimum defensive relationship

 

Defensive routines are: easing in, requesting help,
delivering bad news, saving face. Bypass routines are covered up: inventing
motives – e.g. if I explain harder or overwhelm them with my logic they will
get it; holding others accountable; casual explanations; story telling.

It is apparently all explained by Chris Argyris’a and I have
made notes of 2 books – “59 seconds” and “Discussing the undiscussable”.

The last thing I have looks like this ( which presumably
represents a system or organization)

Thinking    -> System   -> Performance

We need to change the thinking to move to double loop
learning.

 

ACG2010 - Afternoon sessions

I decided to combine the following two because I do not have a lot on them. I started the slot in the first one but ended it in the second so I hope the notes I have can be useful.

The first session was “Game-sense approach to coaching” and was initiated by Steve Tooke. Also present were Matt Wynne, Patrick Kua, Enrique, Dave Harvey and The Bus – the latter being the main reason I changed sessions because I could hardly hear what people were saying.

The idea behind this session as far as I understood it was to link the coaching approach in for example coaching a Rugby team to working the same way with software development teams. Developing people’s skills while playing a game and developing a situational awareness. We tend to do coaching as part of the game in software development but in rugby for example you coach prior to the game. So we do not get opportunities to coach – we’re expected to help the team improve while they deliver. One suggestion to introduce practices is to start with a simple games and add more rules as you go.

At this point I left unfortunately even though the topic was very interesting..
And I joined Dadi’s session on Solutions Focused (Agile) Coaching. I believe it was inspired by a book “The Solution Focus – making coaching & change simple” by Paul Jackson & Mark McKergow

What is wanted?
Vs.
What is lacking?

We’re here to help teams improve. Not sharing info for solutions you know about is negligent – e.g. If the team identifies that there is not enough testing they may decide that the solution is to introduce more test engineers while you may know that TDD/BDD approach is an alternative solution.

Once again the issue about retro items becoming sprint backlog items came up. Makes you (and the team) think how much needs/can change.

Somebody asked if there really is one approach to everything? A tool perhaps is not always applicable. But this approach can be used for the definition of Done- e.g. What will satisfy you that you’ve done a good job?

This approach is also good for solving a problem perhaps not generally making the team better.

I made a reference to a book “Discussing the Undiscussable” by William R. Noonan

Giving up as a coach

Xavier wanted to have this discussion on when do you give up as a coach.
It was attended by Dadi, Liz, Marc L, Patrick Kua, Mack Adams, Racha H, Petra Skapa, Gordon Barrs, Rachel D and perhaps a few others who joined in later on.

I thought it is an interesting one because as a change agent it is inevitable to consider giving up especially when you’re introducing a considerable change and people usually resist changing and even if you find your way around getting them to define their own change it does take time and can be frustrating.

We started by discussing if giving up is a failure. Xavier posed his questions – at what point it is not worth it? What does it mean to give up?

It was pointed out that if teams or individuals don’t want to be coached then we should look for underlying problems. We could try understanding how to game agile(the change) in people’s favour.

For some teams it might be necessary to ask the question – is Agile right? Is Coaching right?

The problem could be in product strategy as well. Teams might be asked to deliver the wrong thing or with less quality which is why they could be de-motivated.
Most of the time finding the problems within the team can be crucial to understanding what is wrong elsewhere in the organization.

Xavier pointed out that as a non technical coach it might be difficult to teach technical practices in which case you only suggest but cannot really mentor.
Do you estimate impediments or organizational changes – for example introducing TDD?

The group said yes of course – they take time.
Sometimes giving up can be useful so we should always have exit criteria- if you have to leave when you do then give them the feedback. They may not understand it at that point in time but when/if their organization moves in the right direction they eventually will and they will call you back. Being honest could be good even if it means you have to leave.

Coaching people on the team to be coaches can be useful for you exit criteria - what happens when you leave?

Someone mentioned the situational leadership model- with 4 phases – telling, selling participating, delegating.

Are we able to coach executive level managers? Must be a very good coach, must be able to help them discover things.

Transformational backlog is important – you have something to start with and it shows that you do work. For reference - Leading change – Richard Durnall’s blog

Presentation is NOT facilitation

This was a well attended session suggested by Tobias Mayer. The people that I remember in the session were: Manav Mehan, Petri, Petra, Dave Draper, Simon Kirk, Dave Harvey, Simon M, Paul D and Laura. Apologies to those that were there but I can’t remember.

The session was inspired by a book I am currently reading – Training from the back of the room which is one of the two reasons I decided to join this session. The other reason is that last year I learned a lot from one of Tobias’ sessions.

It began with Tobias setting the scene and explaining a little bit about what he meant by this title. Learning should be a shared experience and slides are a prescription. Slides effectively are anti-agile, they often are corrupt and wrong.

People come with knowledge so we should not stand as experts. As a trainer or presenter – leave your ego at the door. The experience should be learner centric. For example: don’t put the slides first up. Use a flipchart for the topic (flipchart could still be about me – but helps build some trust in your ability – as you do stuff – e.g. write on the flipchart not just flick slides)

Someone mentioned a useful training “Think on your feed” which resembles the same practices. We then split into groups of 4. Smaller groups mean more people are likely to contribute. We discussed “why do we have slides?” Someone say they are the equivalent of the Gantt charts. We have charts because the business sees them as the product (training) that they sell/buy.

We then talked about how we teach Scrum. People seem to teach Scrum as a process, not its values and this is why it often fails. Most people learn by doing or discovering for themselves. We don’t have to talk about values – instead demonstrate them..
Training must be seen as a holistic process. People walk out with about 10% of the training – however value changes stick.

Tobias said that he has removed his Q&A sections. How would you do that? When training from the front of the room people resist and argue with trainings and this usually goes nowhere.

People’s brain is most open at the start and at the end of the sessions. For example use 5 flipcharts with different questions. The moment someone walks in ask them to go to a flipchart, find a partner and start answering questions to each other.
Tobias also said that he printed his slides and put the around the room rather than showing a slideshow.
Don’t be afraid to say ‘I don’t know’

How to engage people at the beginnings and endings?
- Game straight away? E.g. lego pieces
- Ask people to explain to each other – they’ll remember more.
Overall it was a good discussion. I perhaps expected a little more based on my experience from the year before but still a good value and some excellent ideas.

Thanks All!

Weekly agile links 19th July - 23rd July 2010

Agile: Doing the wrong thing righter Bob Marshall with his point of view on whether Agile helps or not overall. Judge for yourself ;)

Programme Level Kanban David Joyce with a different approach to scaling agile - program level kanban board to replace Scrum of scrums. They look pretty similar approaches, don't they?

Coaching Agile Teams Podcast Lyssa Adkins talks about her new book.

The Flow Experiment based on maths example. Good illustration.

Ester Derby's Coaching Toolkit 'As a coach, your job is not to solve or do—it’s to support other people as they develop skills and capabilities ' looking forward to reading this one ;)

The Core Protocols an Experience Report by Yves Hanoulle (Part 1)

An interview with Russell L. Ackoff It is a pdf and very long. My experience tells me I should find time to read it ;)


The System Behind The Behaviour by Esther Derby (Better Software) - this helped me with an approach to a problem recently. Very good.

The Limits of Agile Alan Kelly talks about common frustrations when applying agile. Very thue. Not sure about the Is it worth it section - Coming from the point of view where I was not replacing a process with Agile I can't argue with how successful other approaches can be.


Scrum is a Silver WHAT and you want to put it WHERE? By: Mike Dwyer. I like this answer - Silver mirror ;)

Re-thinking Lean Service I am pretty sure I've had this John Seddon video before but it is so good that I am including it again.

Experiences from the coaching discipline, ACGUK 2010

This was the first session I attended at ACG UK 2010 and I thought it was a great way to start a day full of open space sessions. The topic was suggested by Petra because of the many analogies with coaching in other areas and there was plenty of discussion and contributions from David Draper, Xavier, Manav, Dadi, Ali, Steve Freeman, David Harvey, Doug Hudson, Ken Powel, Mike Hogan, Mack Adams, Hedi, Nadir, Steve T and others whose names I can’t remember (sorry!).

We all agreed that coaching must start with something interesting especially in the initial phases where you’re most likely in the teaching stage. I immediately noticed that we’re really very focused on coaching Agile teams because I am sure the coaching discipline does have a specific understanding of how much directing should be used. (e.g. none)

It was suggested to break down the information we want to present and build it into a larger practice slowly. It helps if the teams want to learn but we need to make sure they understand it is ok ‘not to swim’ from day one – analogy was made based on someone’s experience being coached to swim.

It is important to start with a clear goal and help them define a goal- why do they want to learn?

Don’t come in with a pre-conceded plan – find out what people want to learn first.
Dave Harvey suggested the EPIC acronym.. e.g We coach for:
- Education
- Performance
- Innovation
- Change

I thought this can perhaps be called “The lifecycle of agile coaching”? e.g. we train then we mentor then we coach?!

The coach is not necessarily better at the skill – something that came up immediately in other sessions as well and also last year. For example 90% of swimming coaches have never been professionals.

Analogy with Rugby coaching: the coach is a facilitator – the players are the experts.

A definition was made: The (agile) coach is a facilitator that created the environment for the team to excel. We would start driving, then observing and then looking for opportunities. Long term learning comes from discovering solutions not from being guided to them.

Don’t guide people to your outcome but facilitate them to the best outcome for them.
First come principles-> then values -> then manifesto – and then practices. (Evolution of learning/knowledge?)

Find positives? Things people would engage for –e.g. find tools. For example: coaching a skilled tennis player – little point to instruct him but rather focus on the positive aspects.

Sometimes however it is about expressing ideas. For example a team might resolve testing shortage by dedicating more time to testing and not by automating the tests which we might have already seen working well.

Difficult people – e.g. “mortgage driven development” is when people only come to work for the money. And that could be ok! Ask: what do you personally get from being on this team? Sometimes the goals could be – I’d like it to be less frustrating? Can always ask – how did that feel for you?

There are different goals in the organization:
- The Coach’s goals
- The Sponsor’s goals
- The team goals
- The individual goals

Our job is to align these goals. It is important to do 1:1s. You could point out that we spend 2/3 of our awake time at work – so why not put some extra effort in making it as pleasant as possible?

Weekly agile links 12th July - 17th July 2010

We just ain't that good at risk Rich Maltzman argues that we're not good at managing risk with (only) our gut. I agree. He also argues that "the tools and techniques given to us by our PM books and mentors are worthwhile" - I would say in some contexts. Interesting read overall.

LeanSSC 2010 UK The link to all published presentations from this year's event @ Bletchely Park

How To Succeed With Scrum When Your Company Is Anti-Agile by Rob Diana. Good article that highlights the issues with the way we sell agile (and the way we've been taught to do it) and why it does not work. I agree the approach will have its benefits and it will be event better if we find ways to illustrate how good this is not by facts but by making people realise it themselves.. and then perhaps at some point they'll realize that there is a bigger problem to solve because it is a common experience that development adopts agile well.. the issue lies elsewhere..

Leaving a Legacy, How Do You Leave an Environment in Which a Team Can Continue to Grow Dan Rough's notes from the open space session with this title at Agile Coaches Gathering in UK 2010.

Kanban - how software people get it wrong Thad Scheer pointing out the mis-understanding and mis-use of Kanban. Pretty good and explains well why most companies would move a team to Kanban only after they've mastered Scrum/XP for the benefits of JIT delivery.

The Essence of Agile Henrik Kinberg's slides from his keynote "The Essence of Agile" at Agile Spain 2010, Madrid.

Millennials and Scrum, made for each another What Lyssa Adkins talks about here is exactly the place I'd choose to be. Just look at that: “Well, that’s just stupid. Who would ever choose to work that way in the world we live in?” When was the last time you heard someone who is not an agile proponent to say something like this about waterfall?!

Paul Dyson's On Estimation article says the things pretty much the way I think about them. Easy to say do not estimate, not so easy to avoid it - yes I do want to know how much it costs before I make a decision to buy it.

The Secret Sauce Recipe to Agile Coaching I am going to read ROB MYERS in detail and compare with my notes from ACGUK 2010.. the topic is hot hot hot for me right now.

Metrics Used In Testing Lots of suggestions.. pick & mix.. but remember Demming's quote: "The most important things cannot be measured."

5 Tips to Build a Real Project Dream Team Ty Kiisel on my favourite topic - building dream teams.Simple & effective.

Weekly agile links 5th July - 9th July 2010

It is Agile Coaches Gathering week and I am heading to Milton Keynes early on Friday so this post will either be lucky to be published earlier or will wait until Sunday.
Looking forward to a great event and for those who cannot attend follow the twitter updates - tag #acg.

Enjoy this week's links ;)

Steps In Performing a Project Risk Audit One topic that is hot at the minute, at least according my impression..

New Maxim: If You Can’t Change the People . . . Change the System! From Tripp Babbitt's Blog

The History and Simplicity of Lean Process Improvement Brian Hunt explains a lot of the reasons behind lean and why things are the way they are.

How to Project Manage Just About Anything My busy week means I can't read this one now but the title sounds intriguing enough so I am including it.

The globally connected project team This might as well have been titled practicla advice on how to work in a distributed team. Looks good.

How Agile Projects Measure Up, and What This Means to You Executive report by Michael Mah, Senior Consultant of Cutter Consortium.

How To Tell Your PM His Leadership Skills Are Terrible? Send him to a IMPROV course? No, seriously I suck and I am proud of it!

Test Driven development with MVC and MSpec 52 minutes video, must watch for me ;)

HICSS 2011 Agile Papers - Need Reviewers! Jeff Sutherland posted this call for reviewer recently.. I wanted to do it but then considered my schedule and gave up.. any takers?

THE LEAN PRODUCT BACKLOG – ELIMINATE WASTE Roman Pichler usually has very useful things to say so worth readin..

LOOKING FOR A NEW SCRUM MASTER I am not looking for a ScrumMaster. this is just the title of the article by Thomas Karsten. Once I had to make similar choice and who knows when it might happen again?