Category: Facilitation (Page 1 of 2)

Thanks Jerry Weinberg

August 11, 2018 / Patrick

If you have worked in IT for some time, you will have come across the name Jerry Weinberg (Gerald M Weinberg). I first came across Jerry when I first read his book, “The Secrets of Consulting.” Jerry impacts great wisdom through his use of stories. He shared his knowledge generously with our industry and set a great example.

He was a prolific writer and I was lucky to inherit many of his books when a contact moved house. I devoured them rapidly, learning much in the process. As a proud Systems Thinker, I enjoyed “An Introduction to General Systems Thinking.” As someone passionate Technical Leadership, I inhaled, “Becoming a Technical Leader.” I refer and recommend many of his books time and time again.

I never had the opportunity to meet Jerry but I met many people who he had personally influenced. I heard amazing things about the “Amplify Your Effective (AYE)” conference. I felt people who frequented the AYE conference came away with more drive to have a greater impact. I regret not taking the one opportunity I had to take part, given the wrong timing and place in my life.

As someone who believes in agile values, I was lucky to meet Norm Kerth. I forgot he co-authored the “Project Retrospectives” book with Jerry Weinberg. Continuous improvement is the basis for better organisations, teams and processes. Call it retrospectives, kaizen or some other name. I count myself lucky for reading this early on in my career.

We stand on the shoulders of giants. Jerry was definitely a giant among giants. In the world of software we often have a negative association with the word, “legacy.” We forget that sometimes that legacy can be a good thing. I am particularly grateful for the legacy Jerry left behind.

5 tips for using Retrospectives as a tool for dissent

January 29, 2017 / Patrick / 1 Comment

I recently shared this article on twitter from HBR, True Leaders Believe Dissent is an Obligation – the spirit of which I wholeheartedly agree. Effective leaders should not be surrounding themselves with yes-people because you need a diverse set of opinions, perspectives, skills and experiences to effectively problem solve. You can read more about How Diversity Makes Us Smarter, Research on how a Diverse group is the best solution for problem-solving tasks and Kellogs’ perspectives on Better Decisions Through Diversity.

Photo from Vipez’s Flickr photostream

A challenge with many leaders is creating the right environment to allow dissent. I draw upon Retrospectives as a useful tool and here are some tips if you are a leader looking to use it effectively.

Be clear about your motives – I can see some types of leaders who want to use retrospectives as a way to get to blame (which is definitely not the point). It helps to be explicit upfront about what you expect from people and to let people know if there will be consequences. If people feel like retrospectives are being used to “find dirt” or for blame, people will refuse to actively participate in future sessions or simply lie.
Find an independent facilitator – I address a number of the trade-offs of an independent facilitator in The Retrospective Handbook and when you’re a leader running a session, there will be times you will want to participate. Playing dual roles (participant + facilitator) can be really confusing for those simply participating, so I recommend at least starting retrospectives with an independent facilitator.
Allows others to talk first – Leaders often come with a level of explicit or implicit level of authority. Different cultures treat authority differently and it pays for a leader to be aware of the significance that is automatically added to your words by holding back and allowing others to speak. Focus on listening first and foremost, and ask clarifying questions rather than being the first to put your opinion on the table.
Pick a topic that affects all participants – When choosing participants, make sure that the topic is relevant and that everyone can contribute different perspectives for. Although outside opinions about a particular topic are often welcomed, retrospectives are best when people can share their experiences. If, as a leader, you are gathering a group of people who don’t regularly work together around a common topic, reconsider if a focused retrospective is a good solution.
Keep an open mind – There is no point in gathering a group of people if the leader is going to follow through on an action they thought of previously to a retrospective. Consider scheduling a retrospective early on, very focused on information gathering and generating insights as a first part, and then a second part with a smaller, focused group on the next steps. By having time to digest the new information, you may find you end up with very different solutions than what you first had in mind.

When used well, retrospectives can create a safe space to invite people to dissent and create an ongoing culture of challenging the status quo.

Panel for Tech Leads: “Navigating Difficult Situations”

August 1, 2016 / Patrick / 0 Comments

I recently moderated a panel in our London ThoughtWorks office aimed at developers leading technnical teams as a follow up from the Lead Developer conference.

Leading development teams can be a challenging prospect. Balancing the needs of the business with those of your team requires a number of different skills and these situations are often very difficult to prepare for.

This panel session will provide a platform for a group of tech leads to come together and share their experiences, insights and advice around the topic of managing conflict and overcoming difficult moments within your teams.

Our panelists are all at various stages of their own leadership journeys and will be offering a range of perspectives and viewpoints to help you on your way.

Tech Lead Panellists

The panelists shared their experiences around situations like:

Having a tough conversation with a team member or customer;
Sharing how they have dealt with overtime (weekends, later work);
How they resolved a technical disagreement within a team; and
Handling a particularly aggressive person, or being aggressively threatened;

The audience also threw in a few questions like:

Dealing with office politics;
Finding access to key influencers/stakeholders;
Where you draw the line with a person on a team; and
Dealing with a technical stakeholder who is too involved, because they seem to have too much time;

We also had some great sound bites in relation to the topics being discussed.

To deal with angry people:

Be the adult – Laura Paterson

or just:

Let them vent – Jon Barber

Managing stakeholders is hard, and you sometimes need to take a stance:

It’s easy to say no – Priya Samuel

People in teams need feedback to both strengthen confidence and improve effectiveness. However:

Frank feedback is really hard. Give the person a chance. – Mike Gardiner

Lastly when thinking about people and teams:

Have empathy. Pairing is scary & exhausting – Kornelis (Korny) Sietsma

I’d like to thank Amy Lynch for organising the panel, Laura Jenkins and Adriana Katrandzhieva for helping with the logistics, all the panelists who contributed their experiences and shared their stories (Priya Samuel, Kornelis (Korny) Sietsma, Mike Gardiner, Laura Paterson and Jon Barber) and all the people who turned up for the evening.

From Flickr (https://www.flickr.com/photos/susivinh/7019888809) under the CC licence

Book Recommendations for a Tech Lead

October 24, 2014 / Patrick / 3 Comments

I gave several training courses on being a Tech Lead and found myself giving a number of book recommendations. Although books are no substitute for experiential learning and close feedback cycles, they are useful as ways of introducing some key skills developers rarely practice in their day-to-day tasks.

Dealing with people

Tech Leads are leaders for an engineering/development team and will need to learn the right skills to deal with the unusual world of people. People are different, unique and have their own styles which may or may not align with your own.

Leading Snowflakes is a good e-book, aimed at Engineering Managers who need to deal with different situations. Although it goes beyond just the people aspects, it is still a good book that focuses more on the people side.

Managing Humans (3rd Edition) is written by Rands & Repose author, Michael Lopp. It’s a humuour collection of stories describing the weird and wonderful world an Engineering Manager may find themselves facing. Most, although not all, of the stories will be relevant for Tech Leads. Thanks to Alex for this book recommendation.

Turn the Ship Around is a great leadership story that talks about how leaders should be enabling other leaders using an example story of how a certain leadership style turned around one of the world performing US navy ships into one of the best. Thanks to Joe for this book recommendation.

Negotiation

A Tech Lead represents both the technical perspective to outside stakeholders, and often carries a business perspective back into the technical team. Conflict is inevitable and understanding how to negotiate to an optimal solution for two parties is a timeless skill.

Getting to Yes was one of my favourite books. It’s short and insightful. The book describes the different between Positional-based negotiation (typical) vs Interest-based negotiation. Thanks to Jo for this book reommendation.

Getting Past No (Fisher) is the sequel to the book above that describes getting through more difficult conversations. Jason Yip recommended this book.

Crucial Conversations is a great book talking about how to have conversations when the stakes are high. They also have another great book called Crucical Confrontations that shows you how to have those difficult conversations that matter. Thanks to Clay for this book recommendation.

Facilitation

Meetings. Meetings. Meetings. Three dreaded words that a developer doesn’t want and often can avoid. A Tech Lead often dreads the numerous meetings as well, but will be often expected to contribute. Most meetings will be poorly planned and facilitated, leading to even more drawn-out meetings. In my experience, when done well, meetings can be focused, short and fruitful when they are well-facilitated. Facilitation skills are also useful on a day-to-day basis when ad hoc meetings between team members occur, or when a particular topic needs to be discussed.

The more collaborative a team becomes, the more useful facilitation skills are to the Tech Lead as they blur into the background to all voices be heard.

The Skilled Facilitator (Schwartz) is the first book I recommend to new facilitators. I find the book easy to read and is comprehensive in its explanation about the role of the facilitator.

Facilitator’s Guide to Participatory Decision-Making (Kaner) is a more focused book, covering how to have group discussions, balance hearing all views and to converge into the best outcome.

Collaboration Explained (Tabaka) is written by an agile practitioner who I trust dearly. I have see her facilitate, and her wisdom is captured in this book that will be highly relevant to particularly agile teams.

Secrets of Facilitation (Wilkinson) is a book recommended by Jason Yip.

Risk Management

With authority comes responsibility and the Tech Lead suddenly sees risks everywhere. Or worse, they don’t see any risks at all.

Waltzing with Bears (De Marco and Lister) is the timeless book that talks about risk management in the settings of software development. Although some of the examples may feel a bit outdated (death march projects), our industry still has plenty of them and the lessons are still relevant for today’s style of software development.

The Failure of Risk Management (Hubbard) is another book recommendation from Jason Yip. Now added to my reading list as it’s one I haven’t yet read.

Not just for Tech Leads

Unsurprisingly the book recommendations above are not only relevant to Tech Leads, but to anyone who may find themselves in a leadership role. There are plenty more skills and books to recommend, but these are a good starting set.

If you liked this article, you will be interested in “Talking with Tech Leads,” a book that shares real life experiences from over 35 Tech Leads around the world. Now available on Leanpub.

Book Review: Getting Past No

July 14, 2012 / Patrick / 0 Comments

A long time ago, I read the very excellent Getting to Yes (1981), a book that described the difference between position-based negotiation and interests-based negotiation. The follow up book written by one of the authors, is aptly named Getting Past No in applying the same principles from Getting to Yes but provides a different technique when negotiating with another party who is unwilling to relent.

In the book, Ury describes the conditions that prevent people from getting to agreement, including your own reactions, their emotions, their position, their dissatisfaction and their power. I like the five step series that he outlines in the book:

Don’t react, go to the balcony – A powerful metaphor that describes a thinking style of keeping your reactions from affecting the negotiation. Instead of giving to natural instincts of striking back, giving in or breaking off, going to the balcony offers a different alternative to approaching the situation. Take time to evaluate the situation as it will lead to the best outcomes for both sides
Don’t argue, step to their side – What I like about this book is the way that Ury describes a collaborative approach to negotiation. Stepping to their side often involves acknowledging (you don’t have to necessarily agree) with the other party’s point of view. Until the other party’s viewpoint is heard, they are unlikely to hear your own.
Don’t reject, reframe – Reframing involves using questioning and other techniques to change the game from a “fixed-pie” mentality to a “win-win” opportunity. Rejecting doesn’t progress negotiations. Exploring interests can. The point of this chapter talks about avoid dismissing the other party’s position, but instead trying to understand what their motivation they have behind it and finding a solution that might solve both sets of interests.
Don’t push, build them a golden bridge – Ury describes this stage as one that takes time. If you try to close a deal too quickly, negotiations will break down. During this phase, you need to address unmet interests, help people save face and involve the other side in the solution.
Don’t escalate, use power to educate – This section outlines a number of strategies if the other party sticks to their position and is unwilling to relent. The key to this stage is knowing both your own Best Alternative to a Negotiated Agreement (BATNA) as well as theirs. Ury recommends executing on your BATNA as this will reduce the possibilities of future transactions, but by knowing both positions, you can explore the consequences if both parties fail to agree. He talks about strategies such as using third parties and aiming for mutual satisfaction rather than adopting a victory mindset.

Book Review: Agile Coaching

May 4, 2010 / Patrick / 2 Comments

It’s about time I got around to reading the whole Agile Coaching book by Rachel Davies and Liz Sedley. I’ve owned it for at least six months now but has sat with a number of other books that demanded my attention. Fortunately long flights (like back to Australia) give you lots of time to pass with books to read. I’m glad I finally got around to reading it as well. The short version: if you’re interested in what agile coaches do, or if you’re working in an agile team, particularly a leadership role, this book is for you.

When you first open the book, it’s obvious it is a Pragmatic Press book. It jumps straight in with lots of helpful hints for those that want or are currently looking to be an agile coach. It’s broken up into four main areas, with smaller sections revolving around specific agile practices. This also means it’s fairly easy to digest it in smaller pieces (something I probably could have tried) doing the daily commute on the train.

I’ve been fortunate to know Rachel and Liz before and during their book writing. This book really captures the way they work, and great advice in the form of very practical tips for people. I hope that any readers, even without knowing the authors, can tell the wealth of experience both of them bring. I think writing a book on agile coaching is pretty tough. There’s a temptation to focus on the coaching elements alone, or to capture the distilled gotchas around introducing and coaching teams on specific agile practices. This book definitely gets the balance right for those new to coaching agile teams – enough background to the practice with helpful hints (it’s not meant to be a definitive guide on a particular practice) yet framed in a way that would definitely help anyone introducing and encouraging an agile way of working.

There are many other people this book wasn’t written for (more on that later) yet in its form is the best collection of wisdom steeped in experience that I see budding agile coaches benefiting from. I wish I had something like this when I first started out explicitly acting as an agile coach.

Like all the pragmatic books, this one is really easy to read. I think it took me about three hours on the first leg of my flight to finish it. Reading through each of the sections, the authors offer advice and helpful techniques. Many I’ve drawn upon over the years and draw upon often, a few I’ve never used and many that I definitely needed a reminder about using them. In other words, this book contain lots of practical advice that can really work depending on your team and circumstance.

There are many things that I like about this book – including the small personalised stories from both authors, named techniques that will help new coaches remember them better, and a very direct try this and see sort of philosophy that is both pragmatic and living by an agile way of working. I particularly approve of this book being, for the most part, methodology-neutral mentioning a broad spread of practices and principles individual methodologies espouse followed up with many other links to resources, books and references for agile coaches to then follow. I also like the hurdles section (there’s often much more than those listed!) as it hopefully prepares agile coaches for what happens when things don’t go to plan (almost always).

This book definitely fills a need – helping new agile coaches work out where to start with lots of advice that can be applied almost immediately. This book is also a useful reminder of tehcniques and a way of filling in some gaps for agile coaches who might have only experienced some of the agile practices and ways of working.

Like all well focused, practical books, part of what makes it so well focused and good are the areas that it leaves out (something I’m sure will be filled by other books to come). Some of these topics include:

Setting up an agile coaching gig right (when they perhaps need something broader than agile coaching) – it’s no panacea for all organisational problems and coaching isn’t guaranteed to turn every situation in short timeframes
Coaching larger teams or large organisations
Coaching distributed teams
Helping organisations “go agile”
Different types of coaching engagements (full time – to part time)
Working with other agile coaches as a team

I’m glad someone got around to putting this book together – and I’m happier knowing that it’s also written by practitioners grounded in plenty of real world experience and a variety of different contexts. To new coaches, many of these apporaches may seem optimisitc or impossible but I know that they’re all tested and can work in the right circumstances. Read this book as a way of starting off and refining your own agile coaching style – don’t view this as a definititve book to agile coaching, and as the authors put it so well at the end of the book – develop yourself continually.

Agreeing to Agree Slides

February 15, 2010 / Patrick / 0 Comments

Thanks to all the people who came along to the GeekNight Liv Wild and I hosted last week. We’ve put the slides up online here.

Agreeing to Agree at London Geek Night

February 7, 2010 / Patrick / 0 Comments

Conflict is a natural part of your every day life, whether it is at work or home. A certain amount of conflict is healthy as long as you work out how to resolve it.

Liv Wild and I will look at a number of conversation models we’ve found healthy teams use, in agreeing to agree. We’re holding it at the Thoughtworks UK office from 7pm this Tuesday (9 Feb). More details can be found here.

Retrospecting Resources

September 28, 2009 / Patrick / 0 Comments

I was really pleased to stumble across a new site for Retrospectives dubbed the “Agile Retrospectives Resource Wiki“. I can’t find who put it together but thank you for putting it to the public. Some other resources that I know about and is worth making more linkable on the internet include:

Retrospective Facilitator’s Gathering – Wiki website detailing the yearly gathering of people passionate about facilitating retrospectives
Retrospectives – The first website Kerth put up describing the practice of Project Retrospectives.
Links to retrospective resources – A good collection of links to blogs, articles, etc that are related to retrospectives

I’m really pleased to fin

XP2009 Day 3

June 5, 2009 / Patrick / 0 Comments

The keynote
Bjarte Bogsnes gave, in my opinion, the best keynote out of the three speakers, where he discussed his experiences applying the concepts discussed in Beyond Budgeting in Statoil. He talks about why do you want a system that is based on assuming you cannot trust everyone? Instead you want a system where the default position is that you trust everyone, and that you manage those that you can’t by exception (and not the other way around).

He talked about how the trigger for Statoil was two fold – internal and external. External pressures included the fluctuating nature of the sale price for barrels of oil, and internally it was the social pressures of actually having systems that encouraged all the good things that they said they did, yet didn’t neccessarily encourage, where policies were largely authority based (sign off) compared to those of trust and respect.

The key question they asked was, “How do we create the conditions that let people make good decisions and execute them well?” Compare this to, “How do we make people make good decisions and execute them well?”.

Interesting their solution laid in removing the “traditional” budgeting scheme, asking people to “do the right thing”. Resources were available but not yet preallocated. I remembered most his metaphor, describing most businesses operating like a bank that is open for four weeks out of the week. Customers need to predict exactly what their year is going to be like, and ask exactly for the right amount.

They identified that budgets typically have three overloaded (and often opposing goals), representing performance targets, forecasts and resource allocation. They implemented a system splitting each of these different aspects into different systems to achieve better visibilty and improve the quality of conversations around each of these topics. They created a system to ensure there was alignment at all different levels, directly creating KPIs out of the strategy, generating actions out of the KPIs and then individual goals out of the actions.

Industrial Logic’s eLearning Tool
I had a great chat with Joshua Kerievsky, founder of Industrial Logic and he asked if I wanted to see their “eLearning” tool. I’m glad I did as well because I think it’s an amazing environment for all developers who want to be professional. I don’t think calling it an “eLearning” tool does it justice. In a nutshell:

Imagine gathering some of the world’s best experts in different programming disciplines such as refactoring, automated testing, design patterns and imagine working with them on the same team. You get to watch over their shoulder as they explain what they’re thinking as they execute, you get to practise an exercise with them and receive immediate feedback, and you get to interact with the most engaging pieces of training I’ve ever seen (including many of the hands on training classes). All of this just happens to be online.

They’ve put a tremendous amount of effort responding to student’s feedback and its narrow focus on (currently) developer related material means they can give some surprisingly detailed feedback including comparisions and alternatives as a result. The tool itself only happens to help deliver the message and, more importantly, he’s managed to capture so much knowledge in the “albums” they’ve already put together.

Go check it out. Take the tour and then have a look at some of the albums.

Telling Your Stories: Why Stories Are Important for Your Team
Fellow retrospective facilitators Diana Larsen and Johanna Hunt ran a fun session that was particularly engaging considering, managing to have the busiest session on the last slot of the last day. The title of the workshop didn’t describe the session as accurately as it panned out as it was extremely creative workshop where we looked a number of a card games often used for story telling in other areas, and then brainstormed ways in which we could create cards and a process to help use stories in an agile environment. The group had some fantastic ideas and even heard a few people walk away saying, “I need to get some of those cards made!” to take back to their teams.

Conclusion
I’m pleased that this year’s conference seemed to have returned to what roots it was for me four years ago. I appreciate the fact that there are still so many people passionate about “doing the right thing”, about helping each other out, and that the main motivator is still to “grow, learn and get better” first, instead of “making money” prioritised as number one. Thanks to all the wonderful people I met at this conference (for the first time and again), and the great memories I took away.