When you look for inspiration in the Agile Coaching community, the name Gordon Ramsay is probably not the first name to come to mind. He has been known to be belligerent, condescending and downright rude, but underneath this brute facade is a treasure trove of skills and talents that influence change.
In this presentation we will draw insights from his ‘Kitchen Nightmare’ escapades and draw parallels with how much his work aligns with that of an Agile Coach and the goal to successfully drive change and introduce a number of models and techniques that are indispensable in the coaching toolkit.
My presentation from the Agile Brisbane meetup called “Agile Coaching Nightmares: Lessons We Can Learn From Gordon Ramsay” is available on Slideshare.
When you look for inspiration in the Agile Coaching community, the name Gordon Ramsay is probably not the first name to come to mind. He has been known to be belligerent, condescending and downright rude, but underneath this brute facade is a treasure trove of skills and talents that influence change.
In this presentation we will draw insights from his ‘Kitchen Nightmare’ escapades and draw parallels with how much his work aligns with that of an Agile Coach and the goal to successfully drive change and introduce a number of models and techniques that are indispensable in the coaching toolkit.
My presentation from Agile 2016 called “Coaching Nightmares: Lessons We Can Learn From Gordon Ramsay” is available on Slideshare.
When you look for inspiration in the Agile Coaching community, the name Gordon Ramsay is probably not the first name to come to mind. He has been known to be belligerent, condescending and downright rude, but underneath this brute facade is a treasure trove of skills and talents that influence change.
In this presentation we will draw insights from his ‘Kitchen Nightmare’ escapades and draw parallels with how much his work aligns with that of an Agile Coach and the goal to successfully drive change and introduce a number of models and techniques that are indispensable in the coaching toolkit.
Learning Outcomes:
Understand the difference between coaching, advising and mentoring
Approaches to having confronting coaching conversations
Dealing with denial and unengaged staff
The criticality of a burning platform to invoke change
Why it is important to have coaches as experts
Agile coaching is more than the GROW model (or other coaching models)
It was extremely disappointing that my partner in crime on this talk Renee Troughton could not make the trip to Atlanta to deliver this with me, I certainly hope I did her parts of the talk justice.
When you look for inspiration in the Agile coaching community, the name Gordon Ramsay is probably not the first name to come to mind. He has been known to be belligerent, condescending and downright rude, but underneath this brute facade is a treasure trove of skills and talents that influence change.
In this presentation we will draw insights from Ramsay’s Kitchen Nightmares escapades and explore parallels with how much his work aligns with that of an Agile Coach and the goal to successfully drive change. We will introduce a number of models and techniques that are indispensable in the coaching toolkit.
The talk was also recorded and is available to view on InfoQ.
Craig and Renee catch up after the last session at Agile 2015 in Washington, DC and talk about the highlights of the conference. Sitting in the atrium near a waterfall, they discuss:
The day before the Agile Australia 2012 conference in Melbourne was workshop day, and I presented a couple of sessions as well as sitting in on others. There was a good mix of local talent delivering workshops this year. One of my hopes for next year is to make them inclusive of the conference proper somehow, so more people can benefit from and experience them.
First Steps With Agile
On behalf of the Agile Academy, Rene Chappel and I presented First Steps in Agile to a large enthusiastic class (in fact, the class was four times larger than we were expecting and much larger than the numbers I have had in similar classes for the last few years).
New to Agile and wondering where to start or want to know what all the fuss is about? This workshop will start you on your journey and help you become familiar with the core values and principles of Agile. You will gain an understanding of what is meant by the term ‘Agile’ and learn about some of the key practices and processes of an Agile approach (while having some fun along the way!)
I had one session free and sat in on this session delivered by Jason Yip. The workshop exercises presented scenarios and encouraged participants to practice speaking aloud their process to solving the scenario.
novices understand the formulas but not what is happening
superficial (understand the formula), semantic understanding (understand what is going on), qualitative understanding (know instinctively what is true)
“Think like a Commander” – US Army exercise to expose and correct weaknesses
learning is not a comfortable experience, it is an experience of confusion
sits between classroom study (learning basic concepts) and a full scale simulation (you use your strengths to achieve an aim)
The Agile Coach is a critical role in helping leaders, teams or individuals understand, adopt and improve Agile methods and practice. Additionally, an Agile Coach helps people rethink and change the way they go about their work. For a individual to be effective in a coaching role, they must poses a wide range of skills and experience. In this workshop we will explore Agile coaching skills in the context of a competency framework and provide participants with lessons from real-world coaching experience. The workshop will provide an opportunity for participants to learn about coaching, identify areas of Agile development and to broaden skills through hands-on group and individual exercises and games.
You will:
» Understand role of an Agile coach and the typical development pathways
» Identify personal areas of strength/weakness in relation to a broad range of Agile and related skills
» Learn situational specific coaching techniques for common Agile dysfunctions
» Understand the use of maturity models in helping teams learn and adapt to Agile
» Understand organisational and role specific Agile challenges
» Learn how to adapt Agile practices to suit team specific challenges
A couple a months ago, Adrian Smith and I were asked to put together an article for the third edition of AgileTODAY to complement a workshop we plan to run at Agile Australia 2012. Adrian and I had a whiteboard session, and we put together these 8 tips which will hopefully help aspiring Agile coaches.
Introduction
The Agile coach is a critical role in helping leaders, teams and individuals understand, adopt and improve Agile methods and practice. For new and aspiring coaches, starting a coaching engagement can be daunting. It is easy to become distracted from the original mandate and get embroiled in the issues and politics of the team. The following tips were put together to help Agile coaches stay focused and achieve successful outcomes.
Before beginning an engagement with a team try to define success in terms of measurable outcomes and a realistic timescale. Share the outcomes with the team and sponsor to ensure there is a shared understanding of what you are trying to achieve. This will help clarify your role within the team and can help reduce any fears the team may have about the coming changes. Setting a clear end date will also ensure that both you and the team are clear that the team have to own and understand their way of working.
Showing the team how it is done the first time then supporting them as they take ownership of the new way of working is a great way to bootstrap new practices and build trust in new practices. Role model behaviours you want to see in the team. If there are techniques or technologies you cannot model yourself, you may need to mentor an enthusiastic team member or bring in an expert.
There is always a temptation to get involved and help with the team’s delivery work – especially when you see them struggling. While this may offer some short term help and can be useful as a learning exercise, it is unlikely to help in the long term. Becoming part of the team will also make it difficult to have tough conversations with team members, call-out unproductive behaviours and stay focused on your coaching objectives. Try to stand back, your role is to support the team and let them take credit for their success.
The team has probably faced a majority of the issues long before you got involved. If they are to own the solution after you have gone, it is important to have them involved in the decision making process. Remember you are trying to help the team learn to work without your help. This sometimes means you have to let them make a decision that goes against your best judgement. Teams need to learn by their mistakes (and sometimes their idea works out which means you can learn something too).
People can adapt to change more easily when it happens slowly and they see how it aligns to an overall plan. Additionally, change becomes natural when you are able to create a safe learning environment for the team that encourages experimentation. Try to change the practices that are causing problems first replacing them with simple alternatives. If you take away all the old practices that a team depended upon they can lose their way and not see the dysfunctions for themselves.
Asking questions is a fundamental skill for an Agile coach and can be used to drill down to the root cause of problems a team is facing. Don’t be afraid to ask “why” a couple of times to get to the facts behind a problem or to introduce the elephant in the room. As a coach you are in the privileged position of being able to raise sensitive issues and to legitimise discussion of difficult issues.
Helping the team identify what is important (especially from a customer’s perspective), making it visible and updating it regularly will focus a team. Example metrics include: throughput, cycle time, delivered value and many others. The corollary to this suggestion is that you need to be careful what you measure because you can incentivise behaviour that has the potential to be counter-productive.
Although the Agile journey is important, Agile perfection is not the end goal. What does matter is delivering what your stakeholders want in a sustainable way. For this reason it is important to use Agile maturity assessments and other metrics with care. Helping a team become agile should focus on instilling Agile values and principles, while selecting and adapting Agile practices to help the team deliver.
Summary
Becoming an Agile coach requires a deep understanding of Agile, the confidence to drive change and a willingness for self-reflection. The role of an Agile coach is a rewarding one that allow you to use a wide range of skills across technical, social, business and communication disciplines.
Day 2 at Agile 2011 in Salt Lake City kicked off with Todd Little advising that the conference this year had 1604 attendees from 43 countries and from 968 submissions we ended up with 268 sessions. Here are my notes.
Keynote – Why Care About Positive Emotions
Barbara Frederickson led with a keynote, but unfortunately I didn’t get to stick around for much of it as I needed to prepare for my session following. Two brief notes I picked up were:
positive psychology is about resilience, the closest concept in psychology to agile
positive emotions open us – we are more creative and can see more in the periphery, we have more resilience to bounce back, better performance on exams
The Speed To Cool: Agile Testing And Building Quality In
The session that I presented with Adrian Smith from Ennova was close to a full audience and was also one of a handful of sessions that was chosen to be recorded. We received lots of great feedback. The slides are available in a separate post. The following pictures were Adrian and I outside the room prior to the session:
Agile Coaching Self-Assessment – Where Do You Stand on the Competencies?
This session was limited to 32 participants, so it was with good luck and planning that I was able to sit in workshop facilitated by Lyssa Adkins and Michael Spayd.
Coaches are energy shifters and are tuned into the atmosphere of the room. We were invited to walk around the circle and reflect on the following areas:
agile-lean practitioner – people who know the tools and practices
business mastery – know what the business needs
coaching -professional coaching
mentoring – help people access what they already know
technical mastery – help people create great software
context – need to not look at a whole object but how it fits into the whole system
patterns – in pair programming, the navigator can see patterns because they are not concerned with the symbols and syntax, pattern matching is the key to expertise
neuroplasticity – humans can grow new neurons, but not sitting in a cage or a cubicle, work with enlightened people or in a sensory rich environment you will grow new neurons, but if you don’t use parts of your brain it will get rewired
If you study in an artificial environment you will get artificial results.
Skills – the Dreyfus model – rules –> intuition, consider everything –> relevant focus –> detached observer –> part of system
novice – no experience, accomplish a goal, want to get it done, don’t know how respond to mistakes, only way to be effective is to have contact-free rules (ie working in a call centre, following a script), need recipes to follow, can’t get much productivity from this level
advanced beginner – start trying tasks on your own, don’t want the big picture
competent – build conceptual models, troubleshoot on your own
proficient – want to understand the big picture, want to understand why, frustrated by oversimplified information, self correct previous poor task performance (retrospectives are a good example of why they need an experienced coach), learn from previous experience, can understand and apply maxims
expert – primary source in their field, continually look for better methods, work from intuition, world does not really work on rules it works on experience
second order of incompetence – know what you don’t know and admit to it
nursing practice shares a lot of similarity to software development – you need to solve problems then and there – need to become outcomes-based, importance of the individual, keep experts in practice, pay based on value added to the company
South American monkey trap is like the tool trap – confuse model with reality, de-value traits that cannot be formalised, legislating behaviour that kills autonomy, alienated experienced practitioners, demand for conformity of tools, insensitivity to contextual nuances
brain is not a computer – made up of L mode and R mode and we switch between them – spinning girl exercise – creativity and intuition works better in R mode
image streaming – pose a problem to yourself, close your eyes for 10 minutes and then for each image that crosses your mind describe it out loud, image it with all five senses and describe it in the present tense
free form journalling – first thing in the morning, write three pages long hand, uncensored, don’t skip a day – way to get it out
ten mental locks – the right answer, that’s not logical, follow the rules, be practical, avoid ambiguity, ……
you need to keep track of your ideas, otherwise you will stop having them – everyone has great ideas, fewer keep track of them, even fewer act on them and very few can pull them off
carry something with you all the time to record notes – tools like The Pocket Mod or Evernote
mind maps
we miss things that change slowly – this happens on projects on all the time
90 cognitive biases that people suffer – memory stinks – every read is a write that can create false memories, anchoring, fundamental attribution error, need for closure (agile estimation) – we will take any information even crap information for closure – in agile we want to keep things open ended, exposure effect, Hawthorne effect, relativity
ask yourself how you know what you know
your age group changes the way we view and understand things
some people need auditory, visual, kinetic
how to read – SQ3R – survey, question, read, recall, review
how to take notes – make a mind map, the sensory of pen and paper is better
get your ideas out there and blog it, tweet it, present it
Warnings:
multitasking – when you get interrupted your memory is blown, constantly checking email is an IQ drop of 10 points, three times as much as smoking a joint!
send less email and you will receive less email – pick up phone, walk down the hall
choose your tempo for an email conversation
don’t context switch – scan queue once, put things into piles, no mental lists (GTD)
set cues for task resumption when you get interrupted, leave a quick mote in code or on a notebook – gets back to resuming task much faster
set team interruption protocols – most teams say this is the happiest times they have coding
second monitor is a 20-30% productivity gains – ALT-TAB in windows is context switchin
Change is hard:
start with a plan
avoid inaction not errors
new habits take time (3-4 weeks)
belief is physical
take small next steps
This was a great session with so many techniques to look (and re-look at). As a result I think I will also add this book to my reading list (especially given that The Pragmatic Programmer in one of may favourite books). Finally, Andy reminded everybody that the Pragmatic Programmers also have a free magazine that is worth checking out.
After Dark
Tuesday night is typically the night that most of the vendor parties happen. I managed two invites – one to the Atlassian Drink-Up (which unfortunately due to talk preparation I ended up missing) and one to the Celebrate with Rally party which I was able to make for a couple of hours at the end.
It was great enthusiasm that I set off to Salt Lake City last month for Agile 2011. In the lead up I was a reviewer on two stages (Testing & Quality Assurance and Working with Customers), plus I was lucky enough (and apparently the only submitter) to have all three of my original submissions accepted (although conference rules, for good reason, restrict speakers to two sessions). Whilst its a been a month since the conference (I took some time afterwards to spend time on both the east and west coast of the USA), I wanted to ensure that I posted my notes.
Here are the notes from the sessions that I attended on day one.
The Product Partnership: Using Structured Conversations to Deliver Value
Mary Gorman and Ellen Gottesdiener led this tutorial. They started by taking about requirements by collaboration and leading a discussion on things that hinder and help.
Things that hinder: access to the right people, thinking about the solution rather than what needs to be done, multitasking, people not listening, customer not clear of needs, backlog too big, stories too big, missing product owner
Things that help: centralised repository, short backlog, story maps, clear business goals, UI mockups part of the story, clear priorities, crisp acceptance criteria
conflicting voices for value – not just from the customer but technology value, we need to listen to all the voices
evaluate requirements – value, risk (such as technology risk, team risk, outsourcing risk) and dependencies (dependent on other teams or external vendors and requirements and dependencies where value violates the way we would like to build the system)
benefit – IRACIS (increase revenue, avoid cost, improve service) needs to be balanced with cost, time and delivery
table stakes – the things we must deliver to stay in business
differentiators – point of difference in the marketplace
two states – credible (it has some kind of value) or buildable (it has been prepared and is sliced, groomed or right size as well as understood well enough to estimate, test and document)
incorporate UX into preparation, collaborated workshops
slice for value – starts with a glean in someone’s eye, then it gets bigger because we have a bunch of options, so we need to fit based on value to contract the list
Data: Fee
Type options: regular, early bird, super early bird
State options: available, sold out
Data: Payment
Type options: credit cards, payment order, check
State options: paid, pending, not paid
We may also visualize this as a data model or a state diagram
Once this is complete we can now we slice for value and write a story. This needs to be the silver bullet / tracer bullet, then you can break down from there. At this point you can write the stories and throw the sheets away. This all leads to:
As a... I need... so I (value)
Requirements leads to examples which leads to tests. We can now link this to given when then:
Given: pre-condition (state), fixed data
When: action, business rules, input data
Then: output data, post condition (state)
It is recommend that you come to these workshops with some pre-planning but be under the agreement that they are draft and often wrong. These could be release or iteration planning workshops.
Now the forgotten heroes, the non-functional requirements:
design and implementation constraints – the givens, the parts of your technical infrastructure that are dictated or restricted – worth pausing and discussing if there are any options
interfaces – human, other systems and device interfaces such as messages (you could use a context diagram to illustrate this) – with the diagram you can start discussing the options / choices / possibilities
quality attributes – things like speed, stability, uptime, security, scalability, usability, extensibility, etc…, need to be testable and SMART (specific, measurable, attainable, realistic, time-based) – eg. recover from user error in x clicks, x time
You can do this at the big view (business process, features, MMF, scenarios), pre-view (user stories, user story maps where you lay out stories left to right, scenarios) or the now view (buildable, scenarios). The granularity will change.
Need to have a structured conversation to communicate effectively. Face to face is the most effective and get a shared understanding of the highest value.
Overall, this was an enjoyable session. I really liked the templates for mapping out the requirements (despite the fact that these were essentially just aids for the workshop) as they helped focus the conversation and gave our group something to focus on. Mary and Ellen are currently writing a book based around this content, so I look forward to seeing that in the future.
Coaching Success: Getting People to Take Responsibility & Demonstrate Ownership
Christopher Avery (creator of the Leadership Gift and author of The Early Admissions Game: Joining the Elite, which apparently is 10 years old and still in print) led this extremely packed session, the essence is contained in this publication available here (as well as here).
We started the workshop by competing in a spaghetti challenge (based on the Marshmallow Challenge) which consisted of the materials of just 10 pieces of spaghetti and a line of tape. The team I was working with constructed a tower of 35 inches, which ended up being the second tallest in the room.
There is a pattern in our mind that kicks in every time something goes wrong – creates angst and anxiety – responsibility process – a descriptive model:
QUIT – the pressure of responsibility and obligation can lead us to quit, an avoidance move, a lack of completion, active disengagement
RESPONSIBILITY – call yourself on obligation so you start looking for solutions – start saying “I get to go to this stupid meeting”, means you have a choice – we were taught that doing stuff we have to do makes us responsible
OBLIGATION – I have to go to his stupid meeting have to but don’t want to – leads to resentment
SHAME – how could I do this, how could I be so stupid – laying blame on self – premise is the problem, you can’t learn
JUSTIFY – it was raining, I dropped my keys – story makes it just – “that’s just the way it is around here…”
LAY BLAME – who took my keys? – not a solving position of mind
DENIAL
3 keys – descriptive model
INTENTION – wanting to get something done, get to RESPONSIBILITY around every problem in your life
AWARENESS – be aware of which level you are in
CONFRONT – ability to face, taking yourself to the edge of your comfort zone, comfort zone = current capability, confront = expanding capability – every person you know was once a stranger
Example coping mechanisms are: learn to live with it, it worked on my machine, they just don’t get it, it’s the vendors fault, it’s too hard, you’ve been here long enough to know that’s not going to happen, murphys law, we did exactly what they asked for, …
We then did a “Be With” exercise, which was essentially sitting knee to knee with the person next to you, in complete silence, for 30 seconds, to feel the others anxiety. Ultimately, it’s not the other person that makes you feel bad, it is yourself.
Confront is the angst of confronting yourself. If you want to change something you need to poke it, and observe the change.
Accountability Responsibility:
accountability is the number one tool of management – it’s the way we manage commitments between two parties – its outside of us because it is us and someone else
responsibility is about how we respond – internal to us, and different for all of us
what people are signed up for is greater than what they are responsible for
what people are responsible for is greater than what they are accountable for <– We want to be here
they are both equal
Where’s the bottleneck?
what if you had to reproduce the code, if you had the same team and resources?
what percentage would be more efficient the second time?
modal is 70%. You would be better because you have solved the problem before. Learning takes time. Essence of agility is to learn and take feedback.
There is lots of feedback in agile practices such as retrospectives, showcases, standups, etc… If you are not going to do anything about it, stop investing in the feedback loop. The fastest way to learn is to take ownership.
Fastest way to elevate responsibility in a group is demonstrate it yourself. If you are saying people around you are not displaying responsibility, then you are just laying blame.
Exercise coaching responsibility. The responsibility process only works when it is self applied! You need to teach it so others can self apply it. Counter not being good enough yet to teach this yet:
Give yourself forgiveness, forgive yourself for being human
Teach this with a light tone. Make yourself the brunt of all the jokes that are below the line
Don’t go into agreement (“but I do have to go into that stupid meeting”) – don’t confuse the facts with the mental position – take time, breathe, count 10 seconds and answer – validates they raised a good question and allows you to respond – ask if you can push back on them a little bit, and ask them to identify where they are on the chart
Make sure you support – need to forgive yourself, let go and move onto a better future
Taking responsibility is owning your power and ability to create, choose and attract.
Responsibility is the design space. What do we want from this? Be clear with what you want and be clear about the consequences. Responsibility gives you power but also potential consequences.
There is a difference between choosing something and avoiding something.
As a coach you get to intervene in situations, so you need to act from a position of responsibility and check where you are coming from (move through the model as quick as you can). Ask yourself if your message is clear and does not sound like blame.
Advice is seldom effective so stop giving advice. You are transferring responsibility from them to you. If it doesn’t work they perceive it as being your fault. Instead:
Resist giving advice. Tell me what you have tried, tell me what you haven’t tried
If you must give advice, give three alternatives so they have to choose, putting responsibility on them. “If I were in your shoes I might consider a…, b…, c… What do you think about those?” One coaching company advises 10 alternatives, so you really think about the responsibility.
Finally, play the “Catch Sinner” game to learn the process:
make a score card
choose a word for today
make 2 columns – “get off of it” and “it got out”
throughout the day, everytime you catch yourself in a position of “blame” mark your chart
10 points for the left and 1 point for the right column
build tremendous awareness for each word at least for one day
There are a bunch of resources at Christopher’s website, in particular he encouraged us to get a copy of the teaching poster and empowered us to teach the process to our peers.
Overall, I really enjoyed this session, as I had heard good reports from this session when it was help in 2009, and this year it was listed as one of the most popular sessions. The responsibility process is something I would really like to work on personally.
The Agile Manifesto 10th Anniversary Reunion: The Big Park Bench
This was one of the highlights of the conference where 15 of the 17 original authors of the Agile Manifesto got together on a big park bench to discuss the writing of the manifesto.
Jim Highsmith noted that there us nothing about it that he would change and would not get back together with these people to do it!
Ward Cunningham would change the colour balance of the background image
Brian Marick noted that individuals and interactions can often be a beat up for people who appreciate tools
Jim Highsmith commented when asked about the next 10 years that agilists don’t predict!
they never expected that something written in a couple of afternoons would be this big
Brian Marick recalled that the stated objective of the meeting was a manifesto and it seemed miraculous that they left with a good framework . Bob Martin was just surprised that he has been to one meeting that worked!
Martin Fowler did not want to call it agile, he wanted a wackier name
Agile Manifesto nailed it as a baseline – they might have added “we really mean it” or “we are not kidding”!
when you gel with a team you get what can be summed up in 3 words: high quality work
great teams change people lives. “The manifesto changed our lives, and probably yours too”
many people who may have survived under waterfall may not survive much longer under agile, as it is flushing out bad practices
other potential names for agile were: adaptive, hummingbird, lean (used already), PPP, a bunch of acronyms, did not want a word they would have to wear pink tights and a tutu to explain!
Agile was a coincidence – people following lean in the 1990’s were saying agile is the future, which was good because agile has a meaning in the business world
the most argued item on the manifesto – iteration timeframe, executes terminology
the principles were harder to arrive at
biggest disappointment – everyone wants to be agile but too few people want to do it (when they wrote it they really meant it), the scrumbut
biggest success – uses outside of software (for example Pragmatic Programmer publishing), wanted teams to be able work freely in a way they wanted to work
need a revolution in middle management and need a similar framework for agility
Agile is not the “not-waterfall” – it’s about teams and delivering software
Agile stands as a beacon of hope, for it to disappear would mean the evil empire has won
in software, we still need to ask how do we do a better job?
an Agile process of inspect and adapt is what makes lean companies great
Jim Highsmith particularly called out Jeff Smith, the CEO of Suncorp Business Services as being someone who got promoted from CIO to CEO through the success of Agile
My presentation from YOW! Hong Kong 2017 and YOW! Singapore 2017 called “Agile Coaching Nightmares: Lessons We Can Learn From Gordon Ramsay” is available on Slideshare.
Craig Smith 
You must be logged in to post a comment.