patkua@work

The intersection of technology and leadership

Category: Retrospective (Page 1 of 5)

5 tips for using Retrospectives as a tool for dissent

January 29, 2017 / / 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.

Celebrate Dissent Photo

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.

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.

Photo from coltera's flickr stream under the Creative Commons licence

Two topics best avoided in retrospectives

March 27, 2016 / / 2 Comments

When I introduce people to retrospectives I often am asked what topics should be covered and not covered as part of this. When I have asked this question of other people, I hear answers like “Everything should be open for discussion” or “No topic is ever taboo.”

Although I agree with the sentiment, I strongly disagree with the statements.

Photo from coltera's Flickr stream under the Creative Commons licence

Photo from coltera’s flickr stream under the Creative Commons licence

Yes, being able to discuss most topics openly as a team, particularly where there are different views is a sign of a healthy, collaborative team. Even then, I still believe there are two topics that teams should watch out for because I feel they do more harm than good.

1. Interpersonal conflict

Imagine yourself working with a team where two people suddenly start shouting at each other. You hear voices continue to escalate, maybe even watching someone storm off. An uncomfortable silence descends in the open team space as no one is quite sure how to react. Is this something you discuss as a team in the next retrospective?

Perhaps if the issue involves the entire team. When it involves two people where tension escalated too quickly over a single topic, it is more likely you need mediation and a facilitated conversation. A person wearing a leadership role (e.g. Project Manager, Line Manager, or Tech Lead) may be an ideal person with context to do that, but it may also be better to find a mediator who can get to each person’s interests and to find a way to both move forward and to start healing the relationship.

Although it will be impossible to ignore the topic in a retrospective, the focus should be on team expectations about behaviour, or identify ways the team can support each other better. It is unlikely you will solve, as a group, the conflict between the two people without making each of them very uncomfortable and unsafe.

behavioural issues for a single person

Just as you wouldn’t isolate two people and make the entire retrospective about them, teams must not “gang up” on a single person unless they feel safe to discuss the topic. If the entire team complains about what a single person is doing, the person is likely to feel targeted, isolated and potentially humiliated in front of their peers.

It may still be important to highlight issues impacting the entire team, but be careful that a retrospective does not become a witchhunt.

Where repeated, consistent behaviour needs to be addressed, a better solution is targeted one-to-one feedback.

Conclusion

Retrospectives are important practices for agile teams, but it is not a tool that will solve all problems. Retrospectives work well with other tools that offer better, more focused conversations for smaller groups such as mediation and one-to-one feedback.

What topics do you think should be avoided in retrospectives? Please leave a comment with your thoughts.

Running a Personal Retrospective for 2015

December 30, 2015 / / 5 Comments

It’s the end of yet another year and a great time to reflect and put your Personal Retrospective hats on. I mention using Personal Retrospectives in my book, “The Retrospective Handbook: A guide for agile teams” because I find them powerful tools to celebrate the past year and to establish new goals for a new year.

This year, instead of simply stepping through questions on paper or on the computer, I decided to use sticky notes and activities I would use with a larger group. In order to keep flow, I wanted to prepare appropriately. This meant I:

  1. Made a plan for the exercises I wanted to run;
  2. Prepared the activities in advance so I could focus on gathering data/generating insights and reflecting instead of thinking about the process;
  3. Had a set of questions prepared in case I got stuck;
  4. Put on some background music – a quick search on YouTube found this spiritual landscape music; and
  5. Had water and coffee ready so I didn’t need to leave the room.

Here are the activities I used this year and that you might find useful for your own Personal Retrospective.

A year in tweets

Using very small stickies to simulate the 140 character limit (I’m guessing I had ~50) trying to generate a number of small tweets about how I felt about 2015.

Personal Retrospective Activity: A year in review

Personal Retrospective Activity: A year in review

Generating a timeline of events

I find the timeline a very powerful way to reflect on the year’s events, and to celebrate their significance. I first brainstormed memorable events before I attempted to nest them into the timeline. I the checked my personal and work calendars, realising that the human memory (or maybe it’s just mine!) is quite bad at remembering the order of events.

I found this blog, my twitter stream and my slideshare page useful sources to remember other significant events.

Personal Retrospective Activity: Timeline

Personal Retrospective Activity: Timeline

Constructing the timeline took the most time of all exercises. Partly because there were lots of significant events for me, and I wanted to appreciate how much had occurred in this year.

4 L’s (Liked, Loved, Lacked, Longed For

I don’t normally use the 4 L’s exercise but figured I would give it a go. It seemed to work well in terms of framing insights but I found I needed to reflect deeper in some of the initial ideas I wrote up. Having an independent coach/facilitator would have been useful but I had to play this role myself.

Personal Retrospective Activity: 4Ls

Personal Retrospective Activity: 4Ls

Goals for 2016

After looking back at the timeline, and reflecting on how the events made me feel and what impact they had, I brainstormed some goals for this year. My focus for this first round was to generate all possible goals I might have, even though these long term goals would not meet the SMART criteria.

Personal Retrospective Activity: Goals (Before Actions)

Personal Retrospective Activity: Goals (Before Actions)

In the second round, I went through each of the different goals, generating some concrete next steps to move me towards each of those goals. My intention is to revisit the goals throughout the year and to take other actions to progress them further. The orange-coloured stickies in the picture below represet these next steps linked to the relevant goals (in green).

Personal Retrospective Activity: Goals (Next Step Actions)

Personal Retrospective Activity: Goals (Next Step Actions)

I also spent the time digitising the outputs into a A3 Personal Retrospective report and have made the template available here if you want to print it instead.

Have you set aside time to reflect on 2015? How did you run your Personal Retrospective? Leave a comment and let me know.

If you liked this post, you might be interested in The Retrospective Handbook: A guide for agile teams, also available in print.

Retrospectives – not just for agile teams

December 11, 2015 / / 1 Comment

I was reminded yesterday of the power of retrospectives, even in the context of non-agile software delivery teams. I have recently worked with a programme team who are building a five-year business case (quite a world away from software delivery and one would argue, very waterfall-like). Fortunately, several people have been very open to seeing how agile works in their environment so I facilitated a retrospective looking back over several months.

During the retrospective, we uncovered a number of typical issues that groups encounter: visibility of work, differences in how work should be approached, and general puzzles about the organisation. Better yet, the group came out with concrete steps towards making incremental improvements and an excitement and appreciation for the retrospective practice, something I was particularly pleased by.

Although there are other ways of achieving the same goals, it reminded me of how effective retrospectives create a safe space to discuss and address issues and create a better working environment. Better yet, retrospectives work for everyone, not just for agile teams.

Booklist from the Retrospective Facilitators Gathering 2014

May 19, 2014 / / 0 Comments

The Retrospective Facilitators’ Gathering is the only conference I planend on attending in 2014. Like many conferences, I end up with many books to read, and thought it’d be worth sharing the list I accumulated here:

Looking back at 2013

December 20, 2013 / / 0 Comments

Although we have a bit of time left in 2013, my work for the year is almost done. Next year brings a completely different adventure. First though, are some reflections for this year.

A bit of a blur

My year was punctuated with many short engagements and events. I definitely did not have a regular schedule, but I did have a good amount of restorative time. My consulting engagements came dotted through speaking engagements, the latter which I had tried to reduce to a good level compared to 2012. The short consulting engagements often involved navigating a new organisation, collecting enough information to provide advice most suitable for their context.

I appreciated these engagements as it often meant working with really experienced people I don’t normally get to work with during other engagements, and I really enjoyed the debates about what might be the “next steps” that organisation could take to address their problem effectively. At the same time, I less enjoyed building relationships with a lot of new people for such short periods because I found it really drains me (and my memory for names seems to get worse and worse). It makes it worthwhile though, if I know that their environment could improve for the better.

Lots of travel

Naturally with so many different shifts both for clients and for conferences, I found myself travelling a lot this year. One week I remember being in London, Manchester, Hamburg and Rome before returning to London. With another client, it was three cities across three weeks back to back. I found myself returning to Dublin for a client, only to be impressed by how much more “continental” the city felt but you are still guaranteed an Irish pub around the corner.

I also found myself in Brazil for the first time (twice!), a beautiful country but one where the lack of public infrastructure is staggering. Fortunately the reliance on taxis for transportation was definitely made up by the friendliness of the Brazilian people.

The Retrospective Handbook in Print

I have been very happy with the reception to the book, “The Retrospective Handbook”, I published last year. People told me how it’s really helped and improved their retrospectives. Totally worth the time.

I spend time making the electronic copies available as print, and I can now physically give away copies (or you can buy them here on amazon!) There’s still time to gift it to someone before the new year 😉

Keynote for Agile Brazil

I also felt very humbled to give the opening keynote to Agile Brazil, a 1000+ person conference this year held in the country’s capital city Brasilia. It warms my heart to see the ideas prospering around the world. I wrote a new talk, “Agile: Unlocking our human potential” with the goal of inspiring people to engage for the rest of the conference.

The video was recently published online too:

Unlocking the human potential – Patrick Kua from Agile Brazil on Vimeo.

Plans for next year: Berlin in 2014

As I hinted previously, 2014 will be completely different from previous years. I intend on taking a break from work, partly because of a (generous) 12 week sabbatical period ThoughtWorks offers employees after a long tenure. My plans are to move to Berlin for year, with my only goal being to speak/write German fluently. I depart British shores early next year where I will start with an intensive language course involving at least 30 hours a week of study.

For people who I know in Berlin (Hallo!) but I hope to avoid speaking too much English for the first part of the year.

Dafür wir können uns treffen wenn wir nur auf Deutsch sprachen.

I intend to write less on this blog, and to spend more time (deliberate practice!) on a German one I have set up here.

Retrospectives as tools for change

July 8, 2013 / / 1 Comment

Jutta Eckstein recently asked me to write a few sentences about my perception of “Retrospectives as tools for change.” After writing my response, I thought it would be worth publishing here.

I see retrospectives as an effective seed for starting change within a group of people whose ultimate outcome depends on each other. I find they can build a shared context in a place where each person holds different “parts of the puzzle” in their head. When executed well, retrospectives also establish opportunities for the group to progress the way they work, improve their environment and build better relationships between group members.

I do not see retrospectives as the only opportunity for change. I also believe they do not guarantee change. I believe they certainly help, and I am definitely in support of that.

The Retrospective Handbook – Now in Print

February 18, 2013 / / 2 Comments

Last year, I announced the digital version of The Retrospective Handbook being released. As much as I feel digital books are important, I am one of those people who like reading using a physical copy of a book. It’s great for you, and it’s also a great way to give one away. And now you can too!

The Retrospective Handbook

The print copy of the book is now available via Amazon (all the links are below). Buy one for you, your team or as a gift today.

Looking back at a year with a client

December 7, 2012 / / 1 Comment

Over the last twelve months, I’ve worked with a client to rebuild a digital platform and a team to deliver it. It’s now time for us to leave, and a perfect time to reflect on how things went. The digital platform rebuild was part of a greater transformation programme that also involved the entire business changing alongside at almost all levels of people in the organisation. The programme also outlined, before we arrived, outlined a complete change in all technology platforms as well (CRM, CMS, website) to be rebuilt for a more integrated and holistic service offering.

Our part in this program turned into building the new web digital platform, working against a very high level roadmap, and a hard marketing deadline. We ended up building the site using Ruby on Rails serving content driven by a 3rd party decisioning platform (much like Amazon recommendations) guided by the business vision of better tailored content for end users. We didn’t have much input into the final choice of several products. I’m very proud of the end result, particularly given the tense and short-timed framed environment in which we worked. Here are some examples of constraints we worked with:

  • 4 Product Owners over the span of 11 months – From January this year, through to the end of October, the business was onto its fourth Product Owner for the digital platform. Building a consistent product is pretty much nigh impossible with changing product hands, and trying to bridge work from one Product Owner to the next was definitely a challenge.
  • Constant churn in the business – The 4 product owners is one instance, but we would often be working with people in the business to work out what should be done, only to find that the following week they were no longer with the business.
  • 3 Design Agencies engaged resulting in “reskinning” approved by the board before the 6 month public launch – We saw several “design changes” done by firms well stocked with people capable of generating beautifully-rendered PDFs that were signed off. However often these would imply new functional work, or be impractical to the web medium.
  • Marketing deadlines announced well before the development team had been engaged – A common pattern in the business was marketing launching a press release announcing a date, well before the people involved in delivering it were made aware, or even consulted on it.
  • PM Explosion – At one point, it felt like we had more Project Managers on the group planning out work with budgets and timelines that would be approved well before the development team had been approached.

Even with these constraints we’ve been able to deploy to production 37 times in the last three months and more since the original MVP go-live in July. Part of what I’m particularly proud of is the team where we were able to achieve the following:

  • Building an Evolvable Architecture – We questioned the original choice and need for a CMS but with a constraint that a decision had been made on buying these tools, we architected a solution that would hide the implementation details of the CMS via a content service. With our TW experience and pain dealing with CMSes that are shadowed by business need, we wanted something that would not constrain what the business could achieve (hence the decoupling). We even had a chance to prove this out when the business requirements quickly hit the limit of the CMS’s built in categorisation module.
  • Responding to Change – The business roadmaps seems to change on a daily basis, and our team was able to quickly tack to accommodate these business changes. We changed the team structure as the team size increased, changed the team structure as we went live, and again as people in the business changed. Whilst our process felt similar, it would look nothing like a textbook XP, Scrum or Kanban process.
  • Improving the Process – Our team has been constantly trying to change the process not only internally to the development team, but also helping people in the business find ways of improving their own way of working. Progress has been slow as the change that starts falters as people leave. Retrospectives have been a key tool but also has the ability for the team to feel empowered with recommending and pursuing improvements they see fit.
  • Setting an example of transparency – Showcases are key to the business, and we would offer fortnightly showcases to the features built to the entire organisation. Huge numbers of people came along and I found it fascinating that it was one place where people had an opportunity to talk across silos. This sometimes slowed down our ability to show what we had actually done, but I felt exposed missing communication structures that people still needed.

At a technical level, I’m really proud of some of the principles I wanted to achieve at the start and that the team lived throughout (I’d love to hear what their experience is). Some of these include:

  • Fast developer setup – Getting started on each new machine should be fast without complicated installation processes
  • Developers rotating through operations – There’s nothing like supporting the code you wrote to help developers understand the importance of logging, test cases that are missed and just experiencing what production support is like
  • DevOps culture – Everyone on the team is capable of navigating puppet, knowing where to look for configuration changes and ensuring that applications are configurable enough to be deployed without special builds across environments.
  • Continuous Delivery – Our second product owner (the first transitioned out the day we went live) actually asked for us to release less often (i.e. it is a business decision to go-live) so that they could work with the rest of the business to ensure they had their non-IT dependencies in place.
  • Devolved Authority to Feature Leads – I blogged previously about Feature Leads who could help shape the technical solution and drive the knowledge for the project.
  • Metrics Driven Requirements – Though not completely successful, we were able to stop the business from implementing some feature by showing them production metrics. In this case, we were able to avoid building a complex search algorithm to show that we could achieve the same result by adding to a list of synonyms on search.
  • Everyone grows – If I look back at the project, I think everyone on the team has experienced and grown a significant amount in different ways. I think we struck a good balance between being able to work towards individuals goals and find ways they could help the project at the same time.

Other particular things I’m proud of the team:

  • Taming the Hippo – Worthy of its own post, Hippo CMS has been one of the least developer friendly tools I’ve had to deal with for some time. The team managed to work out how to run an effective functional test around its poor UI as well as deploy and upgrade the beast in different environments without the 12 step manual process outlined on their wiki.
  • Rapid team size – Management wanted the entire team to start at the same time. Even being able to push back, we ended up with a very aggressive ramp up and we still managed to deliver well.
  • Diverse but co-operative – We had something like 17 people and 14 different nationalities and it’s one of the strongest teams I’ve seen who were able to work through their differences and forge ahead.

Things that I would like to be different:

  • Find a way to code a lot more – Due to the circumstances, many elements drew me away from coding. At best, I can remember pairing with someone for at most two days a week (for a short time) and I would like to find a way to do that more.
  • Implement more validated learning – Although dependent on a product owner willing to do this, I would have liked to work more on trying to build and experiment a lot more.
  • Have a stronger relationship with decision makers with authority – I believe development teams work best when they are connected to people who can make decisions, not just organisational proxies who provide answers. Unfortunately I felt most of this cascaded very far up the organisation and due to the constant flux and organisational change, this wasn’t possible in the timeframe. I’m hopeful that as the business matures and more permanent people find their place, this will be more possible.
« Older posts

© 2024 patkua@work

Theme by Anders Noren — Up ↑