Ron Jeffries published a wonderful post titled “working software“. He quotes the agile manifesto “working software is the primary measure of progress”.
Now, he explains that what exactly “working software” means depends (as always). But in general,
Working software is real. It works. It can be tested. It can be verified. Questions about whether it does X are readily answered with “Yes” or “No”. The less ambiguity there is in our answers—our true answers—the closer to “working software” we are.
And he shares his opinion on “best development style”:
The best development style we know today, whether working solo, in pairs, or in a mob, is to pick a very small thing that the system doesn’t as yet do, verify that it doesn’t do it, then make it do that thing, verifying again, and keeping the code at or above our standard of internal quality.
How small should that thing be? Tiny. Smaller than that. No, smaller still.
I repeat that:
- pick a very small thing that the system doesn’t do yet
- verify it doesn’t do it (the “red” step in the TDD cycle)
- make it do that thing
- verify it does it (the “green” step in TDD)
- keeping the code at or above our quality standard (the “refactor” step in TDD).
I really like that. It’s not always that easy. But more often than not.
I know of TDD but I need to get better at remembering this (I’ll put that in my Anki deck) – including the very small part – and then practice it.
Sprint Goals are one of the more elusive parts of the Scrum Framework. Most teams know they are important, but few use them – for a variety of reasons. In this post, Barry Overeem and I bust the myth that Sprint Goals are optional in Scrum. And we make an effort to show what makes them so vital in the face of complex work. And more importantly, what you can do to start working with Sprint Goals from now on.
I really like this article because I am in a Scrum team where everyone works in his/her niche area. So far we haven’t used Sprint goals. I agree with the observation in the “What happens without Sprint Goals” – section, especially:
Without Sprint Goals, each Sprint implicitly has the same purpose: complete all the work. This makes all Sprints the same, and can make people (rightfully) complain that they are artificial;
So if you’re in a Scrum team that doesn’t use sprint goals, this is definitely a must read.
In this episode we talk to Robert C. Martin, many of you might know him as Uncle Bob, and we’re here to talk Agile and taking it back to basics.
A great podcast episode with Robert C. Martin on “Agile – back to the basics”. So what are, in the time of Scrum, LeSS, SaFE etc., the basics of Agile?
Apparently, “Uncle Bob” has a new book in the works, “Clean Agile” (duh!), covering this subject.
On point he makes is that often engineering practices like Pair Programming, Test Driven Design and Refactoring are overlooked. Especially Scrum does not comment on these. But without these practices, technical debt is likely to accumulate (see FlaccidScrum).
Mike Cohn notes:
Without standards of excellence for agile, anyone can call anything agile.
And asks his blog readers:
What do you think are the core principles or elements of agility?
Which starts an interesting discussion.
One answer that I want to refer to is the “Heart of Agile” by Alistair Cockburn. It’s