Retrospective in the sky

April 2, 2016

Yup, that’s literally what it sounds like. Retro 326m above the ground in Vilnius TV tower.

Me and my team have been working on a cross-team project for a quite long period of time (half year). Although the whole project is not finished yet, we have completed one big epic, and decided to celebrate it and also have a reflective session (retrospective) what’s been done, what we succeeded and what not. In project management such activity is often called project post-mortem.

Retro goals

I’ve had the following goals for this retrospective:

Learn new retro techniques

I am very lucky that my team members are self-organizing and can constructively evaluate the status and progress of the team. Therefore the most common retrospective format (what’s good; what’s to be improved; actions) still works for us.

However I wanted to try the format and activities suggested in the Agile Retrospectives book. There’s also a very neat tool Retromat that can help in making the desirable retrospective agenda.

Review what we have done during last months

The details of the big projects, or product epics that last for multiple months are tend to be forgotten. Especially, smaller details. Therefore I wanted my team to remember and review the things we have done during last half-year. This can be the foundation of the further discussion and can also help the team understand its capacity and velocity better.

Celebrate the completion of an epic

I absolutely agree with the idea to Celebrate small victories. But when it happens to work on a product/project/task for a longer period of time, it also gives the time to try various ideas, validate the assumptions and have the results afterwards. Also, some problems become visible only when you look at them from the wider perspective. Therefore a retrospective of the longer timeframe is also beneficial. Also, it’s a good time to gather with the team and spend some time together and celebrate it literally :)

Improve the execution of further big cross-team projects

Definitely, generating insights and agreeing on the particular actions are the mandatory parts of the retrospective.

Retro plan

I have followed the most well known pattern for having retrospectives - five stages: “set the stage”, “gather the data”, “generate insights”, “decide what to do”, “close the retro”. The initial thoughts were taken using Retromat tool, but then adjusted accordingly.

Set the stage

During this stage I asked every team member to tell his expectations for this retrospective and I stated why in my opinion we need this event. I’ve also presented my goals of the current retrospective.

Gather the data

As one of my goals was to review what’s been done during past half year, I asked my teammates to draw a timeline and define what was done during particular time.

It was fun to compare the results with the real facts.

Also it was a good start for the further discussions which led to generating insights and declaring actions.

Generate insights

After gathering the data the team has already had numerous topics to discuss on what we did well and what we should have done better. The retrospective plan then shifted to the team-driven, but as long as it was meeting the goals and expectations, it was ok.

If the self-organization wouldn’t have happened, I had planned the following actions: since it was clear previously, that the project took too much time than it was planned, I would have asked the team to make an ideal plan (user stories) of such project and compare it to how we were working.

In addition, to see where we had failed I wanted to map our effort to Agile Manifesto to see where we had lost the agility.

We however have defined our findings of this project naturally - you will find them below.

Decide what to do

I would have been using SaMoLo technique (same of…, more of…, less of…) to define the actions if we wouldn’t have done it naturally.

Close the retro

As the closing part of retro I asked the team to review whether their expectations of this retro were met and draw the results as the emotions on the mandarins - you can see them in the photo :)

Findings

Here are our findings and advises of running a cross-team project. It is definitely not a complete list, but the one based on our experience and observations during the retrospective.

Cross-team dependencies should be clear and transparent

When working in an Agile environment, the “decide as late as possible” paradigm is likely to be used. However it is quite hard to see when this “late” becomes “too late”. This especially happens when working on a cross-team projects. Understanding what each stakeholder has to do and how they are dependent is crucial before starting the project. Otherwise it might explode the scope, affect the estimates and plan or even fail the whole project.

Everything should be written down

People are tend to forget things, stakeholders are tend to change, so it is very beneficial to write down everything you agree to anyone.

Such project must have project manager and followed all management activities (planning, stakeholder management etc.)

It’s pretty obvious, but sometimes it might seem that everyone understands everything and everyone knows what to do. For the very trivial tasks it might work out, but for more complex projects essential project management activities are needed, as Dwight Eisenhower said: “plans are useless, but planning is indispensable”.

There must be an integration plan

Well, plans might not be that useless after all. It’s just important to respond to change and adjust the plans accordingly, keeping the agility.

Planning - means thinking up-front, and thinking of the integration reduces the possibility of failure.

Backlog refinement (grooming) activities should include old stories

When working according Scrum, Backlog Grooming (refinement) is the ceremony for handling changes and adjusting plans. Teams should review the planned tasks (or user stories) and adjust them according to the changes in the environment. The output of this ceremony in most cases is estimated user stories in the backlog, which is afterwards prioritized by the Product Owner.

However, there are cases when this activity is misused and treated only as the estimation session for the unestimated stories. Some even have the story status “Groomed”, which naturally leads to sticking to the plan, which violates the fourth statement of Agile Manifesto.

This once again reminds to understand and apply the manifesto in order to be truly agile.

Iterative approach should be followed, trade-offs should be made

It is a very common scenario when the client needs EVERYTHING and ASAP. It’s up to the Product Owner to make the decisions, but in order to be Agile, delivering the product in small working chunks of the product, collecting feedback and adjusting the product is a must. It often requires trade-offs to be made and close collaboration with the clients and other stakeholders. Declaring that “it is needed to deliver everything at once” means there is a possibility of failing being truly agile.

There should be a plan how to collect feedback

One of the reasons to fail delivering small increments is that it might not be known how to properly collect the feedback from the clients. In such cases hoping to deliver everything at the same time and make the customer satisfied is very risky, because there’s the same or even bigger chance to upset the customer as well. In such case you’d have to remake much bigger part of the product, spend more time, and end up creating much more waste.

Epilogue

Retrospectives are the great way to improve how you work. As we tend to plan small iterations (sprints), and the bigger ones (product vision and roadmap), it’s also useful to have retrospectives of both scales - small ones (sprint retro), and bigger ones (epic retro, half-year retro etc.) - they will give you different results and you’ll find different ways to improve.