A two-week Sprint creates the impression that a Scrum Team learns every two weeks.
But that is true only if useful feedback reaches the team within that period.
A Sprint may end while the work is still awaiting integration, testing, deployment or use by real customers. The Scrum events continue, but the most important feedback arrives several Sprints later.
Continue reading What happens when the Sprint is shorter than the development feedback loop?I was speaking with a friend recently who told me that his Scrum team had not held a Sprint Retrospective for several months.
I found myself wondering: at what point does a team stop practising Scrum and merely retain some of its vocabulary?
The Sprint Retrospective is one of Scrum’s formal opportunities for feedback. Remove it and the team loses a regular opportunity to inspect and adapt how it works.
Scrum is built around such feedback loops.
The Scrum Team frequently inspects its progress, its ways of working and the Increment it is creating. At the Sprint Review, stakeholders can examine what has been produced and influence what happens next.
Yet simply holding every Scrum event is not enough. Creating an opportunity for feedback is not the same as being able to respond to it.
Continue reading Scrum creates opportunities for feedback, but XP makes feedback technically possible
Cal Newport is one of my favourite authors. An American non-fiction author and full professor of computer science at Georgetown University, Newport has written some of my favourite deeply insightful books:
and now this book Slow Productivity: The Lost Art of Accomplishment Without Burnout (2024).
It took me a little longer to read than I had meant as I was made redundant during the first half of the book and I’ve been focused on my work situation. But I finished reading it this afternoon and I wanted to share my initial thoughts.
Continue reading Book review: Slow Productivity by Cal Newport
The second supporting agile/XP practice that I want to explore is ‘spike solutions’ or simply ‘spikes’.
The name ‘spike’ comes from rock climbing. A piton (sometimes called a pin or peg) is a metal spike or wedge that is hammered into a crack in the rock to act as an anchor to secure the rope. This protects the climber from the consequences of a fall and to assist progress. The spike itself doesn’t move the climber closer to the top but it helps provide a safe path to do so.
Similarly, in software development, spikes help developers determine a safe path forward when knowledge is lacking about how to do something.
A software spike is a technical investigation—a small experiment to research the answer to a specific problem about how to do something.
Continue reading Spikes: supporting agile practiceIn my blog post a few weeks ago, I said that future posts would include some of the supporting practices (outwith the Scrum framework) that we can use from our agile toolbox.
When I first discovered agile and then introduced it to my team in 2008, pair programming was one of the first practices we adopted.
As the name suggests, pair programming involves two developers sitting side by side working together on the same code. Two developers means two brains working on the same problem. One developer ‘drives’ while the other ‘navigates’.
As Shore and Warden say in The Art of Agile Development (O’Reilly, 2008), “together, the driver and navigator create higher-quality work more quickly than either could produce on their own.”
Continue reading Pair programming: supporting agile practice
