Category Archives: Experiences

agile, Experiences, goals

Coaching Objectives

Leave a comment

It can be hard to set objectives for coaches. Linking a coaches deliverables directly to the output of a team is neither fair nor sensible yet it’s frequently used as a path of least resistance.

I’ve been asked how I was measured as a test coach. Below is the set of objectives that the coaching team, which included an agile coach and myself as test coach were set, as well as an excerpt from the job description for my role. Hopefully they prove useful.

Key duties and responsibilities

Coaching Team Objectives

We also had 360 feedback in our performance management process which was collected and discussed every 6 months.

Want To Know More?

Want to know more about test coaching? My presentation So Mr Testing Coach, What Do You Do? may help.

 

 

agile, conferences, Experiences, management, practices, Presenting, reviews, team, Testing

Presentations from Agile In the City London

Leave a comment

I recently spoke at the Agile In the City London conference. As well as watching a number of great presentations, I also was lucky enough to be able to give two presentations and I’ve shared the slides below.

 

agile, Experiences, management, reviews

How We Improved Performance Reviews – What Happened?

Leave a comment

tl;dr No-one really likes performance reviews. But giving your team members good, actionable feedback and setting clear direction with them is very important. In my team we changed how we did performance reviews.

Note: This is the third post in a series on performance management and review. It’s worth reading the other two first:

What We Did

In part two of the series I talked about how my team and I took the performance review and feedback system that is used at Atlassian and adapted it to suit our groups context. I talked about the themed ‘checkin’ sessions and how we got the whole group working to a common timeline for review and feedback, and the advantages that brought.

We what happened? How were the changes received and what was the feedback from the teams?

Selling the Idea

Once we were clear on our direction, we had agreed as a leadership team how we wanted the process to work and what themes we were going to use, then we prepared to sell our idea to the rest of the team. I strongly believe that one should not dictate changes that affect people’s career development or relationship with their manager, and so it was critical to us that the team members were bought into the ideas of the changes and our reasoning for proposing them.

We gathered the team together and explained the new process and how we felt it benefited them. I explained how I felt that the traditional process was sub-standard and could be improved. The key messages were this:

Feedback is better when it’s timely and so we want to start a process where that timely feedback enables higher quality discussions about you

As a group we agreed to run the process for one cycle and then review the results. If, after that, the teams were happy to continue then we would continue and if not then we would stop and revert back to the company-wide yearly cycle.

Kicking It Off

The issue with selling an idea to a group is that often, in private, people will express their reservations more freely. So it was key to ensure that managers then spent time with their team members and gave them the opportunity on a one-to-one basis to discuss the new process. This was also a good opportunity for managers to explain the process in more detail and seek additional buy-in.

The checkin sessions themselves are intended to be 30 minutes long in order to ensure that the process does not take too much time every month. It ensures that only the valuable things are discussed, and the sessions can be to the point and targeted at what matters. However, since this was a new process then we ensured that the first few checkin sessions ran to an hour so everyone could get the hang of it.

Writing It Down

Since checkin sessions were short and punchy – although not literally 🙂 – then it was critical that everyone prepared for them. The checkin’s process works if the team member comes to the session having already prepared what they want to talk about. In order for them to be able to do that then we needed somewhere that they could document their thoughts.

Being an MVP then we did not want to spend much on supporting tooling (there is an excellent tool called Small Improvements which supports this sort of process) so instead we designed our own form. It’s simple and includes questions that the team member should answer in order to prepare for the session. The idea is that they fill in the relevant tab before each session, the manager can then review and prepare based upon the information they’ve entered, and then the checkin session itself can be focused on the discussion and actions from that discussion, rather than the actual ‘thinking’ time. It allows sessions to be targeted and valuable.

We designed our own form to support the process. If you’d like to see a copy then get in touch. We used the questions below to drive discussions: 

Another advantage of using the form was that each team member built up a record of their year, what they had done, and how they had performed. This meant that when we did need to provide yearly feedback into the main company process then it was simply a matter of extracting the information we already had in each form. It was also great to encourage team members to look back through their forms to see what they had achieved throughout the year.

Not Just Qualitative Feedback

By meeting with our team members every month for themed, targeted performance and career management discussions then it also meant that we had a great opportunity to give them quantitive feedback. Like a lot of companies, we use a four point scale and at the end of each year every employee receives a performance review score which has an impact on salary and promotion – standard stuff in most companies.  Once per year with no indication in-between how they are performing relative to that four point scale.

This seemed unfair so we adapted the checkins process to also include giving the team member feedback each more on how they had performed against the scale and why. This helped solve multiple complaints against a yearly system:

  • One key aspect of feedback is to amplify the positive and managers could tell their team members about the good things they were doing.
  • Since the manager and team member were setting goals together as part of the checkins process then we wanted managers to act more like coaches. Having the team member measure themselves them this helped to amplify ownership of their goals and performance.
  • Team members got timely feedback that meant that they could adapt quickly if they weren’t on track.
  • Managers could give timely, targeted feedback with recent examples, in order to drive meaningful improvement. No more having to keep a years worth of notes or trying to remember what the whole team were doing a year ago.

However, merely getting a feedback score from the manager still presents a surprise and it was important that the manager was able to have a meaningful two-way discussion about performance. In order to drive this we asked each team member to give themselves a score, on the same scale, before the session. This enabled the manager to then understand how the team member felt they had performed, and it encouraged the team member to think about their achievements during that month. The discussion, held towards the end of the checkin session, could then be focused on any differences between the manager and team members interpretations of their performance.

Running The First Rounds

The first rounds went smoothly. One thing we learnt pretty quickly was that it took time to adapt to the process and so running the first couple of checkins for each team member as hour long rather than 30 minutes was definitely necessary. There was also some prompting required of some team members in order to get the forms filled in prior to the checkin session rather than during the session but this was to be expected given that the process was different and new.

People were surprisingly happy to provide a feedback score for themselves and by asking them to do so, we were able to make more meaningful and example based discussions on how they had performed.

Feedback

As we had promised, we ran the process for four checkins, i.e. one cycle and then sought feedback from the team. Broadly speaking it looked like this:

We Liked

  • Focused sessions are clearer beforehand
  • Keeping track of things and getting constant feedback
  • It’s easier to remember what’s happened in a month
  • Makes the annual review much easier
  • More productive
  • Constructive, thought provoking guidance

We’d Like To Change

  • Some sessions are too similar or too regular
  • Some sessions are too close together
  • The process is too time consuming so could it be shortened?
  • No 360 feedback
  • There’s nowhere to document the managers feedback

And So…

We now had some feedback to work with. Overall the experiment had been a success and was worth continuing with, albeit with some small changes. Overall we had:

  • Designed and rolled out a process which enabled timely, targeted, example based feedback to each team member
  • Enabled each team member to take responsibility for their own development and think about it each month, before the checkin session
  • Set clear, regular, expectations on people’s performance throughout the year
  • Made it far easier to deliver what was required by the companies yearly performance management process.

In the last article in this series I’ll explain what we did in order to improve the process to suit our context even better, and some of the key learnings we got from running the process over a longer time period.

 

Experiences, leancoffee

West London Lean Coffee – 2nd March

Leave a comment

We had some great discussions at the last West London Lean Coffee session which was held in Carluccio’s in Westfield on 2nd March. Here’s a brief write-up of what we talked about.

What We Discussed

Finding the Right CTO For a Tech Startup

We talked about how to go about finding a CTO. If, as a founder, you have a great idea but no clue about how to get the technology enablers completed in order to get to market then what should you do?

We discussed using specific CTO and founders meetups and websites to help with the search. It’s important to spend a lot of time choosing the right CTO (so many startups fail due to differences of opinion between the founders and early employees). Having a strict spec can be un-helpful and it’s as much about whether one can work with someone, than it is about their pure technical skillset.

There’s also the opportunity to consider part time CTO’s to help guide you. We also talked about whether having one right from the start is even required and that time would be better spent iterating over an idea, testing it through marketing or consumer research, before even thinking about how to partner with someone to built it.

How To Choose The Best MVP

What does a good MVP look like? How do you go about defining it?

We talked about whether it’s actually better to look at Minimum Pitchable Product first, vital for securing funding. We also discussed trialling ideas on customers, segmentation and why it’s important to consider that the customer base is not a base of you.

Revenue can be your best proof of an idea or a minimal pitchable product. You need to prove that you can deliver value.

In that respect I’d certainly recommend reading The 4 Hour Work Week by Tim Ferris which contains a lot of tips.

What Are The Key Behaviours That An Agile Coach Can Demonstrate?

What should you look for when choosing an Agile Coach? What behaviours make great coaches? We came up with this list:

  • Calm
  • Knowledgable
  • Lack of arrogance
  • Contextually aware
  • They want to make themselves out of a job or contract
  • Good agile knowledge but not prescriptive
  • Behaviours are the most important thing

Alignment Of Lean/ Agile To Customer Value

How can we ensure we are aligned to the needs and value gained from customers? We talked about gathering value as early as possible. But in order to do that one needs to understand what value means and this has to come from stakeholders. Identification and relationship building with those stakeholders becomes is so important.

How Much Transparency Should a Team Provide During a Sprint?

How much should a team feedback progress during a sprint vs just getting their heads down and getting on with it?

Our discussion started by talking about the pros (stakeholder management primarily) and the cons (perceived lack of trust, reporting overhead) of providing visibility. We agreed that the key point was not to disrupt the team during the sprint and to that end, automated reporting solutions (within popular tools like JIRA, Trello, etc) were key. But on their own reports could be misunderstood and lack context so if teams do want to report during sprint then there is a human overhead to do that, perhaps falling to the Delivery Manager or Scrum Master.

What We Didn’t Get Time To Discuss

  • Product Owner role in a larger product company
  • How close to an actual customer do you take user stories?
  • Sharing failure stories – good or bad
  • Process of website up and pitfalls (yep – I don’t understand what this really means either 🙂
  • Have you ever worked with someone who stood out in a positive way and why was that?

The next West London Lean Coffee will be on March 30th in Carluccio’s in Westfield at 8:30am. Hope to see you there!

Experiences, KanBan, leancoffee

West London Lean Coffee – October

Leave a comment

Last week saw the latest edition of West London Lean Coffee, slightly delayed from October into early November. We had a group of 8 people and some great discussions.

img_20161103_084636618

Things We Discussed

Does Agile Need Updating

A detailed discussion about whether the agile principles are still valid and if they are not then does the manifesto need updating. Is the language right? Is it just a matter of applying general principles to the correct context?

It’s worth reading this article from Ben Linders on the same subject.

Transitioning Teams From Waterfall

How can you transition teams from waterfall methodologies? We talked about the complexities when fixed deadlines are involved and how negotiation with Product Owners is key. We then discussed about the importance of focusing on outcomes and not outputs from a team and avoiding falling into a trap of merely doing mini waterfalls. Identifying where the value is and tying everything to measurable business goals can help. I’ve found a lot of what Johanna Rothman has written to be very useful in the past so it’s worth checking her website out.

Impact mapping is also great at ensuring that the team are focused on outcomes from the start.

Alternate Benefits To Contracting For Developers and Testers

We spoke about the difficulties of retaining employees when the contracting market is so strong and what could be done to help. Focusing on team culture is key and ensuring that there are strong, personal bonds between team members. Treating people like adults and helping them adapt to change, while protecting a team from a lot of outside influence can also help. The focus on autonomy, mastery and purpose in a role can mean that the money aspect becomes far less important.

It’s worth checking out Management 3.0 for more details on ways in which you can help build great teams.

How Best To Organise and Delineate Different Workstreams Across Kanban Boards

We talked about whether it was best to have one large Kanban board that covered a number of different workstreams, or let teams have their own. It was agreed that team ownership of boards was the clear winner and something like a portfolio board could be used to bring the results together if needed. We then talked about how using a tool like JIRA could also help and could be used for reporting as much as tracking.

It’s worth checking out some of the presentations from LeanKit as a starter to learn more and this blog post about Portfolio Kanban.

Integrating UX/UI Into Agile Delivery

What’s the best way to integrate UX and UI design into agile? Do you just have the designers work a sprint ahead? But what happens if there are problems with the designs?

We spoke about how putting regular checkpoints or design reviews into the process can help and getting the ‘QA’ aspects of the design process as early as possible can de-risk having design ahead of development.

Things We Didn’t Talk About

  • How do you know what are genuine (non vanity) metrics for MVP? This article could help.
  • Any experience about sizing addressable markets?

The next Lean Coffee is on November 24th, 8:30am in Carluccio’s Westfield, Shepherds Bush. Hope to see you there.

 

conferences, Experiences, management, Presenting, Testing

My Experiences of WeTest 2016

1 Comment

tl:dr;

I really loved being a part of WeTest 2016. I gave the opening keynote at both conferences, as well as a couple of other talks at sponsor events. If you came to any of them then this post contains some useful links you may want to read. It was great to meet so many engaged and knowledgeable testers in New Zealand.

The Opening

I was thrilled when I was offered the opportunity to travel over to New Zealand and talk at the WeTest 2016 conferences in Auckland and Wellington. I mentioned my conference speaking goal as part of my presentation at both events – this was that one day someone would invite me to speak in New Zealand. And Katrina Clokie, on behalf of WeTest did just that earlier in the year. It didn’t take long for me to agree to be a part of the conference and being offered the opening keynote was a real privilege.

Now there is one thing that’s clear and that is that it is a long way to New Zealand (28 hours to be precise from the UK). So I wanted to ensure that I made the most out of my short time there and to give a presentation that fitted in with the conference theme of “Influence and Inspire”. Given that I have made a move out of a pure test role over the last few years then this seemed like a logical theme for the presentation, and an opportunity for me to give my views, gained from outside of testing, on how testing is perceived. I also wanted to show the audiences that there’s important leadership roles within testing to be taken and made the most of.

Preparation and Arrival For WeTest

I can say without a doubt that WeTest was the best organised conference that I have spoken at and it’s testament to the effort put in by Katrina, Aaron, Shirley and Dan. All too often presenters at conferences aren’t treated brilliantly by organisers – either by having a lack of support leading up to the event, being expected to pay their own way or by needing to foot the bill for travel and accommodation then claim back. WeTest was different – they organised and paid for all travel up front and sent detailed itineraries for each speaker, plans on how the conference rooms were to be setup, as well as ensuring that the simple things like a taxi to pick you up off a long haul flight was pre-arranged. It made the whole experience easy and it made us speakers feel valued. Other conferences should take note.

A really appreciated gift at checkin. WeTest was a great example of how to run a conference
A really appreciated gift from the organisers, handed out at hotel check in. WeTest was a great example of how to run a conference.

Up and Away?

My presentation focused on my views of testing from outside of just testing and how I made a move into software management and why. It was part of a clearly well thought out programme and the other presentations, whether focused on more technical aspects such as mobile testing, or other leadership presentation, fitted together really well. You can see the programme here to get a feel.

Great sketch notes of my presentation from Yvonne Tse
Great sketch notes of my presentation from Yvonne Tse

Highlights

People arriving for WeTest in Auckland
People arriving for WeTest in Auckland

I thought all the presentations were good but a particular highlight for me was Adam Howard’s “Exploratory Testing Live” where Adam took the really brave step of doing live exploratory testing on the Trade Me website in front of a conference audience. Fair to say it went a bit better in Wellington than Auckland, where he found a bug early on that blocked a lot of the rest of the session but he coped really well and there was value in both sessions. We don’t see enough live testing at testing conferences, it’s common to get live coding at development ones but hasn’t seemed to catch on. Based upon Adam’s session then it should.

Also I really enjoyed Joshua Raine’s really personal story about “Conservation of Spoons” which he did as a noslides presentation. Deeply personal at times and spell binding. I won’t give you the details because I’m sure he’ll do this one again and to know the story would spoil it.

A New Approach to Q&A

As part of my presentation I thought I’d try out the new Q&A feature in Google Slides. It turned out that this was a good move because it enabled me to get questions from the audience as I talked and also to keep a record of all of them for later. If you speak at conferences I’d really recommend it.

For those of you who attended then here’s the questions asked, my responses, and a little more information.

What do you most miss about your testing focused roles?

I guess I miss being the expert with the safety of many years of experience of testing. I also make sure I keep connected to the testing community because it’s great and if I didn’t then that would be the biggest thing that I’d miss.

It’s hard to find a balance between adapting and burning out when trying keep up with new trends and technologies. Do you have suggestions on how to manage that balance?

I make sure I do one thing well; that together with Jerry Weinberg’s Lump Law – “If we want to learn anything, we mustn’t try to learn everything” help me to maintain a balance. Trying to find the one thing to focus on is sometimes hard, but by discussing with your stakeholders and your team then you can usually come to find out what is the most important.

Do you have any resources/suggestions for learning to speak ‘Dev’?

There’s not one clear answer to this – it depends on your context, languages and architecture that you are dealing with. When I started then I tended to use google a lot and base my searches on discussions I’d had with the dev’s in my team. I’d also ask them what they thought I should be learning and why. I’ve also found sites like Hacker News and Stack Overflow to be great for keeping up with what’s happening. Talking Code also comes recommended.

Was your career path in the same company or different? Would you suggest to change companies or progress in one?

It was in the same company and I think it’s much easier to make a change from one path to another when you are in the same company. You have that reputation to use and you are a known quantity. It’s also likely that you’d been working towards such a change as part of your personal development anyway so the company will be confident in your plans.

Since we are talking about change, at any given point during those career changes did you resist the change? How did you over come that? Were you specifically looking for change?

I talked about how it can be scary to make changes but trying something new for 6 months is key. You need to understand that you will go through a change curve just like anyone else and things will feel extremely uncertain as a result at the beginning. I knew what to expect since I’ve been through other changes.

In this case I wasn’t specifically looking for change, more for an opportunity.

Thank you for the nice talk If you had to recommend doing ONE PRACTICAL exercise to raise awareness with the team that WE ALL own quality – what would it be?

I like the idea of whole team testing and bug bashes are a great way of starting.

What do you think testing will be like in 10 years time?

I think we’ll see less traditional testing roles and the focus on automated checking will become more of a development activity. This may mean that there are less testing roles in total but good, exploratory, coaching testers will always have a place in teams. I think the biggest change will affect Test Managers, with far less of a need for them and a transition to coaching roles.

How do you avoid being typecast as just being a tester and overlooked for other career opportunities?

Show that you have an interest to others in your company. Work with your manager to map out your path to a new role and start to show that you are learning the skills that will be required in order to be successful at it.

In short – you own the responsibility for your own career.

A lot of people in this company are transitioning from Waterfall to Agile. Some of the people in the room might gain from you talking to how you see that transition working from the experience you bring, especially if they’re concerned about career development and management.

It does depend a lot on how the management structure adapts. In agile transitions that I have been a part of we’ve changed to autonomous, cross-functional teams with single managers, who have been supported by coaches for both agile, testing and development. This support network is key, as is the establishment of discipline based communities. A strong testing community for example, allows testers whose roles are changing to adapt.

I’ve spoken before about the effect of removing Test Managers from an organisation and the biggest takeaway for me was the need for a strong support network for testers afterwards.

Support from coaches allows not only testers to be supported but also means that someone with testing experience becomes responsible for establishing career paths, competency expectations, etc that can then be used by other managers who are not experienced in managing testers. It also helps maintain a ‘voice of testing’ towards senior management and to enable activities that help testers grow within an organisation.

And Repeat…

Parimala Hariprasad is full flow!
Parimala Hariprasad in full flow!

The first conference was in Auckland and we repeated the experience again in Wellington three days afterwards. This meant that the whole WeTest circus upped sticks and set off for Wellington for a repeat performance. I also did an “Understand Your Mobile Users” presentation at a sponsor the night before, plus the same WeTest presentation at a sponsors internal conference the day afterwards. Four presentations in one week was something new to me and actually pretty interesting to do as I got into the speed of things. It almost felt like being in a band on tour 🙂

Closing Thoughts

WeTest was great. I met some great people and learnt some new things. It was extremely well run by a passionate bunch of volunteers who knew how to treat their speakers well and how to organise a great programme for the conferences. The testing community in New Zealand is really engaged and it’s clear that there’s some really forward looking testers pushing the boundaries here. If you get yourself over to New Zealand then I’d certainly recommend it. It’s not that far. Really 🙂

Experiences, leancoffee

West London Lean Coffee – 9th June

Leave a comment

I’m the organiser of the West London Lean Coffee meetup and I thought it would be good to do some short write-ups of the events and an overview of what was discussed. Useful for those who attended and hopefully also for those who didn’t.

lc(If you are wondering what a Lean Coffee is then take a look at the Lean Coffee website to find out more).

 

Topics We Discussed At Lean Coffee

Applying Agile To Non-Software Tasks

A good discussion about how you could apply agile to HR, finance, change management, etc. It got me thinking about this TED talk about how you could use agile to plan your families tasks.

What Is The Easiest Way To Transition To Cross Functional Teams

We got talking about how you could transition teams from being discipline focused, i.e. development team, test team, etc to cross functional agile teams. There’s some good examples in this blog post and also it’s worth thinking about skills mapping as part of the exercise.

Sizing In Points Vs Time

Is it best to size in points or time? Or both? Or neither? We talked about how you might bring two teams together who size differently, why the most important thing about sizing is not the method you use, but the fact that it gets the team to think about the tasks, and how that can help drive commitment.

Topics We Didn’t Get To Talk About

  • PO = Business?
  • Does agile estimation bring value?
  • Idea to bring a good but impersonal team together.

Hope to see everyone next time. If you haven’t been before and fancy coming along then join the meetup group.

Experiences, practices, Testing

Talking About Testing

5 Comments

Have you ever said “I’ll just have a play with the software….”?

As testers we are generally really bad at explaining what we do and the value it brings. In fact we are usually pretty rubbish.

This makes stakeholders take us less seriously, and can affect career prospects, position within the team, or even a job itself. Outsourcing what is perceived to be low skilled work is tempting, especially when times get tough.

We then complain that we are not being taken seriously, and we feel ignored, undervalued and sad.

And so we retreat into our bubbles and the whole thing repeats itself.

So How Can We Change This?

We can get better at explaining what we do and the value we bring as testers.

Keith Klain sums it up nicely here

What is Testing?

“Testing is the infinite process of comparing the invisible to the ambiguous so as to avoid the unthinkable happening to the anonymous”

James Bach

A great definition but not one that lands well with non-testers in my experience. It’s like when myself and Dan Ashby tried to get a company to stop saying ‘manual testing’ and instead say ‘sapient testing’. It made perfect sense but it just didn’t land. People didn’t see it as important. They didn’t see a need to change because we were trying to take a leap that was too large, from what they thought was correct language to what we thought was correct language.

When I’m explaining testing I prefer to start by asking “Do you care about quality?” The usual answer is “of course”, in which case I can then use the Weinberg/ Bach/ Bolton definition:

“Quality is value, to some person who matters”

“So what’s testing then?” they will ask.

Well.  “Testing helps us uncover risks to product quality. It’s about investigating software, in order to discover those risks, enabling others to make decisions about whether it’s suitable for release”.

We Need to Talk More Technically

But that is hard. Just see how complicated it is to explain the Heuristic Test Strategy Model in two minutes for example.

(OK – I know the whole point with this video is that it is impossible, which proves a point I think :))

What Value Do We Bring?

When explaining value, it’s all about the words we use, and the angle we take. It’s about the audience – don’t explain testing to a developer in the same way as you would to the CTO.

Again, Keith Klain nails it with this talk.

So, think very carefully about how you explain your testing. Perhaps, just perhaps, ‘playing with the software’ isn’t what you mean.

So – how do you talk about testing?

Experiences, practices

A Christmas Retro

Leave a comment

Ho, ho. ho, Merry Christmas!

At this time of year it’s a great opportunity to sit down with a team and reflect on the year that has been, and to look forward to the year to come. And being Christmas then it’s also a great opportunity to look a bit silly, dress up in Christmas hats and jumpers and have a  bit of fun.

With that in mind, I decided to organise a Christmas retro for the team I’m working in. We are responsible for a brand new product  which launched this year, so we’ve had a very busy, very exciting and very experimental year. Getting the team together to reflect on that year was very important.

The Idea For a Christmas Retro

My first step was to look round for inspiration for Christmas themed retros. Had anything like this ever been attempted before? Fortunately I was in luck, both Em Campbell-Pretty and David Manske have both written about a great way to run a retro at Christmas, based upon the Dicken’s book ‘A Christmas Carol’.

Em’s blog article, where she applied the technique to a large group was my first inspiration, and then I stumbled upon David’s article as well, which helped to add some more details, and was helpful for the smaller (15 people) group that I work with.

Basically speaking, the idea is that you base the retro around the ideas of Christmas Past, Present and Yet To Come. In A Christmas Carol, the main character, Scrooge, is visited by ghosts on Christmas Eve who show him how Christmas was, how it is presently for others who rely upon him. and how Christmas will be, were he to continue on his current path. It’s a great book and I’d definitely recommend reading it. Or, watch A Muppet’s Christmas Carol. It’s great 🙂

present

Adapting It For a Retro

Since the Muppets theme seemed to be a fun way of introducing the idea of the Christmas Carol retro format then I went with that. The team love Muppets.

Adapting the story to use in the retro was pretty straight-forward and heavily based on Em and David’s ideas. In order to get the team thinking about everything that had happened throughout the year then myself and our Product Owner prepared a set of posters, one per month of the year and then pinned them up on the wall of the room where the retro was to be held. It was pretty amazing to look back at everything that the team had achieved throughout the year. We focused on delivered work; features, numbers of tickets, etc, and then interspersed this with press cuttings from the year that mentioned our products, team details and fun stuff, such as number of Percy Pigs sweets eaten, etc. Which is important to this team, believe me 🙂

IMG_2930

We also bought lots of Christmas hats, food and even a Father Christmas beard for yours truly, then invited the team into the room to start the retro.

Christmas Past

past

For Christmas past we got the team to look back at the year and then think about whether there was anything that they regretted or wish had gone differently. They wrote these on post-it notes and kept them to themselves.

Christmas Present

present2

Next I explained the idea of Christmas Present, and encouraged the team to think about what had gone well throughout the year, what had made them feel good, and who in the team they would like to thank for helped with particular pieces of work. Again, they wrote these on post-its.

Christmas Yet To Come

yettocome

The third piece, Christmas Yet To Come, was about the hopes for the next year, What did they want for the team, themselves and our product? The idea was to get them thinking about future priorities and to work on putting together a short list of what we, as a team, think is important for the future.

How It Went

So the stage was set, people were wearing silly hats and eating Christmas food. More importantly they could also see how much we had achieved throughout the year, and they were thinking about how we could work in the future.

The Grinch

grinch_by_crazymic-d6yvfkp

Once everyone had written down their thoughts on Christmas Past, Present and Yet To Come I introduced a fourth category, The Grinch. This was an idea that David explains in his blog post and the intention was to get them thinking about what could happen to us, as a team, that could threaten next Christmas. Essentially  it was about identifying project and team risk. So everyone also had a think about that and wrote down their ideas.

The Retro

We then went through Christmas Past, Present and Future, and The Grinch in turn.

For Christmas Past everyone was expecting to come and pin up their post-its, rather like a usual retro. But instead, being Christmas, it was time to let go of regrets and so I encouraged everyone to tear up their post-its and throw them away. When I was planning the retro I wasn’t sure how people would react this – would they view this as a waste of their time in writing the regrets down in the first place? It turned out they didn’t – after much hilarity with people throwing post-it’s at each other, the feedback was good, with some people saying that the idea of throwing away regrets rather than sharing them, was the best part of the retro.

For Christmas Present and Future everyone came up in turn and discussed what they had written on their post-it’s. People thanked each other for work that they had helped on. We talked through trends and actions that could be taken from what had been discussed. This gave everyone a great view on where we are as a team and where we want to be going.

For The Grinch we talked through the risks that everyone saw, and how we could deal with these in the next year.

From all of this we were, as a team, able to decide on what was important to us going forward; with actions that were both product focused, and also team focused, such as organising more social events and sharing the responsibility for doing so.

Merry Christmas

We finished by thanking the team for what they had done and explained how they should all be very proud of what they had achieved throughout the year. Then it was time to go off on our team Christmas event offsite.

Overall I think that this retro format works very well. By combining something seasonal, fun and focused, it made looking back on a whole year much easier and more exciting than a more traditional retro format would have done. The format engaged people and made it easier to share experiences.

And let’s be honest, who doesn’t like wearing silly hats and Christmas jumpers once in a while? 🙂