Definition of Agile retrospective:

An Agile retrospective is a meeting that’s held at the end of an iteration in Agile software development. During the retrospective, the team reflects on what happened in the iteration and identifies actions for improvement going forward.

Each member of the team members answers the following questions:

• What worked well for us?
• What did not work well for us?
• What actions can we take to improve our process going forward?

The Agile retrospective can be thought of as a “lessons learned” meeting. The team reflects on how everything went and then decides what changes they want to make in the next iteration. The retrospective is team-driven, and team members should decide together how the meetings will be run and how decisions will be made about improvements.

An atmosphere of honesty and trust is needed in order for every member to feel comfortable sharing their thoughts.

In IT this is how it looks like:

But this model could easily be adapted to any project context, when more people/stakeholders need to work in teams.

Where to start? By setting the Agenda, of course!

 

It’s also crucial to underline that  “Regardless of what we discover, we truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand. We are here together to find ways to improve, to discover solutions to problems, not to find scapegoats or lay blame. Whatever we discover will make us stronger as a team.”

The base of a Retrospective Exercise uses the traditional questions “What went well?” and “What can we improve?” method, but there are several models that you can use to make it different and more fun every time you do it. My favourite, introduced by the IT AgileTeam @ Booking are:

• The Star Fish

• The Plus/ Delta:

 

– The Learning Matrix:

 

To Sum Up: The retrospective is a window for teams to inspect and adapt, to learn about what works and what does not work, and to find better ways of working together, always striving towards continuous improvement.

Giving and receiving feedback is at the heart of any successful agile interaction, process, implementation etc. and when doing this correctly you are certainly contributing/ leading your team towards a model of High Performing Team.

 

 

So what does all of this have to do with human resources?

For one thing the four values of agile development can be easily applied to the practice of HR. Incorporating adaptability, transparency, simplicity and unity can help improve HR service delivery.

Adaptability is important in the face of changing business needs, while simplicity is important when designing HR programs and practices that don’t cause confusion, alienate managers and employees or try to accomplish too much. Unity applies with respect to HR working together and ensuring it isn’t working in silos or at cross purposes with the business. Transparency is important in gaining the trust of managers and employees and explaining why things have to be done in a certain manner.

I have a good example to share about what we are currently doing at Booking: HR and Business working together to create the best possible Employee Journey experience in IT. This means challenge the current status of our HR core policies, be open to feedback and change, truly listen and understanding the business needs and work together to make sure the communication and implementation phase will be successful. To achieve that we really need to team up with the Business and make sure everyone understands the push and the limit of each proposal and new change.

An agile model of this specific example is the willingness to incorporate feedback into the new project so that changes can be made incrementally and early in the process. From an HR perspective, it’s important to work closely with other stakeholders and obtain their input very early on. For ex. as part of the Employee Journey, we are now changing the set up of the new HRS toll only implemented at the beginning of last year. Why? This was done by thinking Global, in big steps and without thoroughly consulting the immediate stakeholders. This handed up in lots of frustration from the management side with a feeling that HR was pushing process to them or that the processes were too long, with too many approval steps for example. Although the intention of the HR department was clearly positive (empower managers, give them the right tool to find all the info needed about their teams, create reports from whenever and wherever, initiate processes that wouldn’t need email-chains approval etc.) something clearly went wrong. But What/Why?

“Giving and receiving feedback is at the heart of any successful agile implementation”

Looking back, this was an clear project where an effective Retrospective would have made a huge difference.