22

Agile reflection

Reflection is a skill that is vital for raising awareness through feedback that enables us to learn, and identifying opportunities for improvement and change.

On a day-to-day level, reflection can help us to plan and evaluate work in progress. With each sprint we can reflect on the performance and outputs of that batch of work. By combining the learning, action and reflection from previous sprints of activity, we can review and measure against our goals, objectives and chosen direction to ensure we are doing the right thing and doing the thing right.

In order to reflect well, we must take time to gather a clear picture of the reality of our actions. The agile approach provides valuable data through the activities of estimation and ranking, and mapping actual workflow, establishing accurate measures that can be reviewed and evaluated.

Regular reflection is interwoven into the fabric of the agile philosophy and methodology, and includes techniques such as retrospective meetings held at the end of each sprint of work (see Figure 22.1).

Time for reflection provides a means to review feedback that we have received from releasing early versions of our solution, which works to inform and guide future work. By regularly reflecting on progress, we can see the impact of our work and how it fits with our environment and its dependencies.

From reflecting on activities and progress, we can identify what is going well and do more of that: we can strengthen and build upon the positives. The flipside is that we can be better aware of what has gone less well and what can be done to prevent underperformance in the future.

Reflection enables a comparison to be made towards our estimation of where we predicted we would be, and the results of our actions against the current reality. We can review our metrics and adjust our projections accordingly. The agile dashboards help to capture and visualise this to see progress, impact and value.

Figure 22.1 Sprints of learning, action and reflection

By reviewing and refactoring every few weeks we are able to evoke lots of small incremental change, which adds up to big change but in a managed and controlled way. Risks can be identified early and decisions made to respond to changing situations and scenarios.

At its extreme, agile provides a methodology to learn fast and fail fast if an idea is not viable, which can save a lot of pain from progressing something that is not worthwhile. Equally, it also provides a format to review ideas that are not effective and to find ways to change and improve them, so that they evolve into being viable and effective solutions.

Retrospectives

A retrospective (a term used in software development to describe meetings that review past performance, inform future work and identify improvements) is the name given to reflective practice within agile. It contains five key questions that can be used to review your whole approach to working as a part of day-to-day reflection of work in progress, sprint reflection for short-term targets, and reflecting on the goals and objectives and direction we have established through our GROW model.

• What is going well?
• What can we do better?
• What is stopping us?
• What has changed?
• What is next?

WHAT IS GOING WELL?

Reflection allows you to identify what is going well and recognise good performance. It is an opportunity to celebrate success and review the impact of positive outcomes in bringing you closer to reaching your goals through your work.

By reviewing what is going well, there is an opportunity to focus on what works and what can be done to harness and grow those elements further. It also identifies areas that are performing efficiently and whether these may be causing a positive or negative impact on related and dependent activity. Often, when we improve one aspect, it requires that another aspect also will need to change or improve to compensate for the impact, which is an opportunity for continuous improvement.

It is really important to recognise success and good performance, as it is all too easy to dwell on the negative and what we do not get right.

WHAT CAN WE DO BETTER?

As part of the retrospective, we look to identify opportunities for improvement by identifying areas of our work or solution that have the potential to be done better. Better, in this sense, may mean better quality, faster or cheaper.

What activities did not go as well as planned? This could be due to a number of reasons, both internal and external. It could be internal, where areas of your work can be improved and developed in order to increase performance and outcome.

Rather than dwelling on what went wrong, or suggesting that something is not good enough, the question is angled to be solution-focused, identifying what can be improved. For example, reviewing lean efficiencies may provide opportunities to identify and review opportunities for improving efficiency and value through reducing waste, and making best use of the capabilities and capacity available.

Externally, there may be an unforeseen impact of integration or changing requirements that mean the planned work does not fit as well as expected. Other internal and external events also may have impacted on your workflow. These may have caused interruptions, distractions or blocks.

If your work is not receiving the good reviews you hoped for, this could be miscommunication, which easily can lead to misunderstandings. Ensuring clarity through retrospectives can help to make certain that you are clear on needs and expectations. It is vital to question and ask for feedback to clarify why it is not satisfactory, so that the next cycle of work can identify amendments and improvements to address concerns, and deliver a solution that is agreeable.

WHAT IS STOPPING US?

Review what is stopping you – where the blocks and bottlenecks are within your work – so that you can act to improve the flow of your work. This can highlight waiting times, gaps and opportunities to improve processes.

Bottlenecks can show where estimates are wide of the mark or activities are under-resourced, and where a team can swarm to help relieve the pressure points by working together. Resources may need to be reallocated, additional tools or solutions brought in to address delayed responses caused by issues with other dependent activities, and actionable tasks should be established, in order to improve the flow of work going forward.

If there is always a waiting time within a particular task it is a good indicator that that task needs to be broken down into multiple tasks that have dependencies and can be actioned when needed, rather than staying ‘in progress’ or ‘waiting’ status for extended lengths of time.

WHAT HAS CHANGED?

Being aware of what has changed and what may affect your progress is vital. Are there external factors influencing your environment that need to be addressed? Are there internal changes that impact upon your ability to do your job? How do you need to adapt to take this change into account, and are there opportunities of which you can take advantage?

New work also can be classed as change that needs to be considered. Items that have been added to the inbox or collated on an ideas board can be reviewed and scoped to establish whether they should be added to future work, and where they should be prioritised through estimation and ranking.

WHAT IS NEXT?

The final question of the retrospective is defining what next. The reflection and learning from the previous questions should provide actions going forward for what the next sprint of activity should contain, and any broader actions that are required in order to support the success of the next sprint.

If following the retrospective, changes are needed, these are recorded for action in the next sprint planning meeting. This might be new work that needs to be added to the backlog of future work or changes to current work.

• What should we stop doing?
• What we should start doing?
• What should we do more of?
• What should we do less of?
• What should we keep?
• What should we lose?
• What should we add?

If the retrospectives uncover a potential need for a change of tactics at a high level, or flag a potential change of direction, then the GROW model and scoping and estimation techniques should be used to help map and review the options for change.

The outcome of a period of retrospection should feed into learning, which can inform the scope of future work. It provides the knowledge needed to revise resources, review estimations, reprioritise the future work and map what will be in the next sprint of activity.

Stand-up meetings

The purpose of a stand-up meeting is to maintain a real-time image of work in progress. It acts as a mini-retrospective to review progress regularly within a sprint. Stand-up meetings (daily meetings commonly held by scrum development teams and, more widely, by software development teams) classically are very short, 5–10 minutes in length if there is a team, often just a minute per day, if just an individual.

A stand-up meeting is a meeting where you literally stand in front of your board and update it. Whether working alone or as part of a team, taking a few minutes to update the board every day means the board maintains an up-to-date representation of current status and work in progress throughout each sprint of work. You may invite others to your stand-up meeting. For instance, this may be someone you want support from to help deal with a blockage. Ideally, everyone who has work on the board will join the stand-up meeting.

• What has been done since the last stand-up meeting?
• What did you do yesterday?
• What is currently in progress?
• What are you doing today?
• What are you doing next?
• What are you doing tomorrow?
• Are there any blocks or delays that require action?

The outcome of this meeting is that the board is updated and its status is reviewed quickly; any obstacles can be identified and actions set, if needed, before they impact upon progress towards completing the sprint. Any unresolved issues should be taken to the sprint retrospective at the end of the current sprint for further discussion and agreement on action needed.

These are some signs of delay and blocks:

• I was interrupted yesterday to do something else.
• It is taking longer than estimated as resources/equipment are limited.
• I need a dependent activity to be completed before I can start on that activity.
• I am awaiting a response from an external contact, which I need before it can progress further.

If you are working as a team, the benefit of having very short daily meetings, rather than the typical monthly team meeting, is that focus is maintained. Meeting time is productive in updating the status of work and presenting a view of work that can be reviewed easily to see if work is running as expected.

Another benefit of meeting daily is that it is much easier to catch up if you miss a day. Depending entirely on the scenario, a stand-up meeting does not strictly have to be daily. However, a dashboard should be updated regularly during a sprint. The board should be updated as needed, which sometimes may be multiple times a day; at other times, every other or third day may be sufficient.

Sprint retrospective meetings

Regular stand-up meetings will drive short-term activity and responses to daily influences on workflow. At the end of each sprint of work, a retrospective meeting is an opportunity to review performance and identify change, based on the last sprint of work. The outcome of this meeting will inform the next sprint planning meeting.

A sprint retrospective meeting (the reflective meeting held at the end of each sprint within a scrum software development team) should include those who are actively working on the work, which might be just you or members of your team. You may choose to invite your manager and those associated with your work as appropriate, or indeed customers so that you can update them and gain their feedback.

• What has gone well?
• What can we do better?
• What is stopping us?
• What has changed?
• What is next?

A sprint retrospective gives the opportunity to gain feedback more widely and provides a structure for regular feedback and input from customers and others who are involved or impacted by your work.

By structuring planning meetings to be quick and often, we avoid the need for lengthy monthly meetings where half-day meetings turn into whole days with the result of very little productivity or actionable outcomes. In comparison, using agile takes up comparatively the same amount of time, but structures it to be little and often and driven by specific purpose in contributing to planning and reviewing activity.

Stopping regularly to reflect upon the results of our work means we can see what is going well and what we can improve upon – we can address any blocks or changes and decide what is next.