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.
George Dinwiddie led this session which turned into a lively discussion! I had proposed what I thought was a related session on Specification By Example and had combined them, but the conversation never really had a chance of getting onto that topic!
George expects the business people to be able to read and understand the tests
non-programmers should not be writing automation, it is the programmers responsibility
wants to be able to extract working tests into a step definition rather than needing to rewrite in Ruby (George Dinwiddie)
there is a difference between a specification and testing (Christian Hassa), this is a fundamental shift
building a DSL – talk about terminology and how we explore our domain – essential step
you don’t create a DSL, you build it
not a problem with the toolset but our training in thinking in a procedural way rather than an example way of thinking (Corey Haines
testers new to automation create large scripts because it’s their only hope in creating some sort of repetition (@chzy), it does not take a lot of effort and most business people are open to working this way
enable non-programmers by getting them to come work with us every day (Woody Zuill)
George is helping people make a transition, don’t want people to throw away what they have,
ideal is not to have step definitions call step definitions, Cucumber community is becoming a community of programmers and are moving away from this
Robot Framework is more keyword driven, more aligned to non-programmers, you can also make a mess, “it is a double edged sword” (Elisabeth Hendrickson)
testers like to test the negative cases, should they be expressed at a high level or expressed as a unit test by pairing developers and testers
if you are testers and you cannot write simple Ruby scripts, then you have no place on my team (Corey Haines), this opinion is probably shared by the Cucumber community (George disagreed…)
need to use the same design patterns in both Robot and Cucumber (@chzy)
in an environment that is test centric and BDD, Cucumber is the tool (usually environments with little to no QA), in a business centric environment where you an get the business involved Robot Framework is your tool
Corey works in environments where there is very few Cucumber specifications per scenario, backed by lots of unit tests
Cucumber came out of environments where the team is predominantly developers, hence the desire to drill down to Ruby code sooner
at a large household name company – theyexpect testers to be more technical, happening more in the industry, eliminated the role of tester due to different pay grades (@chzy)
moving traditional organizations to a collaborative way of working is hard (@chzy)
wants simple refactorings that are are a bridge from one place to another (George Dinwiddie)
at a startup Joseph was at, tests were taking up to 8 hours to run and costs for distributed architecture was high
Forward Internet (London) – let developers do what they want – by not testing they could be faster and more interactive than their competitors – did testing in Production, a risk that sometimes things could fail – testing should not block deployment
in some situations it is just worth hacking it out, particularly in a lean startup
if it is faster to rewrite rather than maintain it, then don’t write tests (Fred George via Corey Haines)
a big question of this is the skill level of your developers – do you have the skill level to make the choice to not do it (Corey Haines), primary impact of success is the skill level of your developers
Scribd – were having trouble with test speed and found out the developers were scared of breaking the PDF (which is the heart of the business) – they separated the PDF out to speed up development (so developers weren’t worried about breaking it)
quick delivery – need the quick feedback cycle to make this work, simulate production
need effective tests – small suite of tests that are 5-10 minutes long
test what you are most scared of
Silicon Valley’s issue is hiring – Facebook is stealing developers from Google because they hire good people and enable them to just hack it out
2 software industries – small companies and large corporations, very different worlds
question everything – can only do this if you have experienced it before and understand it
Wikimedia Foundation – looking at ways crowd source testing to test infrastructure (rather than content) – more on this initiative to be announced in the near future
why is it any different to coding katas? Safer and smaller so you get more practice, practice collaboration too
organise a community like a book club
code roast – put the code up and everybody critiques it, be careful not to attach to a person!
We finished up the open space by writing what action we were taking from the day and giving them to another participant to keep us honest (mine was to write this post!)
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.