At the end of June Redgate's Product Development organisation ran a retrospective session to review how things have gone in our corner of Redgate in the first half of 2019. This post explains how we ran the large scale retrospective and what we discovered by doing it.
Inspect and adapt how you build as well as what you build
The need to inspect and adapt is the fundamental concept at the centre of the agile software development movement. However, it often seems that the drive to inspect and adapt is only deliberately applied to what we build and not how we build. This means how a team works together, how they use the technologies at their disposal and how they apply processes can go unimproved.
Goldilocks Goals: How to keep Retrospectives fresh and engaging
One way to keep Retrospectives fresh is to set explicit goals for each session. However, just choosing a goal isn’t quite enough. You want to choose a Goldilocks Goal that opens up the discussion 'just right'.
When the going gets tough, don’t cancel the Retro
If times are tough on an agile project, whatever you do, don't cancel the Retrospective meeting. If you think that having the team in a meeting room for one hour every two weeks is going to make your project fail, then it's going to fail anyway.
Five steps to an effective sprint retrospective
In a typical agile software development process, sprint retrospectives are meetings run at the end a development iteration. In those sessions the team looks back on what they have done and how they have done it, and decides what they can do to improve. More succinctly, the team inspect and adapt. In my... Continue Reading →
Create tangible retrospective actions
In my view, the drive to inspect and adapt is the most important concept to have been popularized by the agile software development movement. It's an idea that got me hugely excited and engaged in the subject when I first came across it in 2005. This essence of this is that 'we will always know... Continue Reading →