This is the final article in a series on optimising project delivery in an agency environment. To complete the introductory picture I am going to look at what I consider to be the beginning and the end of an environment that is optimised through change, the retrospective.
Throughout these articles I have used the term 'makers' to refer to developers, designers and other creatives and the term 'specifiers' to refer to product owners, account managers or any other form of business stakeholders. When looking at QA we explored a third type of role, 'critics'.
When I began this series I was torn as to whether to start or finish with the retrospective. I chose to finish with it because I put a lot of value behind the importance of the retrospective and I felt that the last thing that you, the reader, read would come to mind first.
What is a Retrospective?
A retrospective is, over time, what your team evolves it to be but there are some key principles that should stand regardless. I recommend having a retrospective every two weeks and certainly no less than monthly.
- To be effective a retrospective must be an open, critical but non-judgemental environment where people can raise issues. The purpose of a retrospective is continuous improvement not blame. For this reason when adopting a change focussed way of working, that retrospectives normally exclude Specifiers from a Makers retrospective (and vice versa). This encourages free speaking. As this way of working becomes more ingrained and openness becomes more accepted then that situation can change.
- The retrospective will usually be facilitated by a member of the team. The facilitator's job is to ensure that everyone is encouraged to provide their input. The quite guy in the corner may not be very vocal but his opinion has as much value as the loud-mouthed joker in the team.
- The team members will communicate things from the period being assessed that went right, things that went wrong and and ideas for improvement. I normally then encourage use of a voting system to pick out the key issues and then discuss these in more detail, coming up with actions to deal with things that are not working or for the key improvement ideas.
At the end of the retrospective actions should be written up and tracked so, when the next retrospective occurs the results from the actions last time around can be reported to the team.
Why is this so important?
The retrospective is the key engine for change in a change enabled structure. The actions from retrospectives across the business should be used to drive new initiatives and changes to product and process to make both the product and the delivery of the product better and more effective.
The retrospective empowers the team involved to effect change of process and workflow, to introduce new systems and approaches to work that become clear at the ground level as problems are raised.
This is the final article in my introductory series on optimising project delivery using agile techniques within an agency environment (whether or not you are properly agile). I will be taking this further in upcoming articles and delving into these topics and structures in greater detail in my upcoming book.