Personally I favour the phrase “Specification by Example” (Adzic, 2011) over the more commonly used term “Behaviour Driven Development” (BDD). That is because I demand the specifications are by example but only encourage my developers to do outside-in test first development (from BDD).
Continue reading
Epics aren’t very good for driving the development team because Epics lack sufficient detail and will take too long to complete anyway. But Epics are, like their smaller relatives the user story, great as a place holder for a conversation.
Continue reading
I use the formal “As <user role> I want to <action> so that <goal>” format when it helps. The main value of the format is it puts the focus on the users rather than on technology components. So if the user story is about user facing functionality then I will usually use the formal format as a back up to the shorter name of the user story.
Continue reading
The Iterative Incremental approach inherent in Agile applies to delivered functionality but also to the requirements elicitation part of the process.
I like to refine requirements over time. Start high level, just enough to remind us to have a conversation, then fill in the detail just as we need it. What starts as a simple name of an Epic Feature will turn into multiple User Stories each with several Scenarios. But you don’t need all of that at the start.
The iterative nature of requirements definition is suggestive of a spiral process – what my daughter would call a “snail”:
Agile Requirements Snail
Gojko Adzic has recently published a great book on a technique he calls “Impact Mapping”. Gojko’s Impact Maps are a visualisation of the business drivers and the associated project scope. This means the people doing the work (developers, UX, testers, etc) know what to build but also why they are building the functionality, how the functionality fulfils the business outcome and and who the functionality is for. Love it.
As it happens Programme Managers already have a very similar tool for a similar purpose. Benefits Maps, like Impact Maps, are used to visualise business drivers and associated scope, in this case programme scope. They answer two key questions:
The dual function – showing why and how – make Benefits Map high value documents. It also means a Benefits Map can easily morph into the initial Programme Blueprint. For a simple programme the Benefits Map may be the only Blueprint. And the diagram format means it fits on one page. Even in a world where we value “Working software over comprehensive documentation” that one page is worth having.
Continue reading
Search the Lean-Agile literature and you’ll struggle to find much mention of vision. Agile is all about short planning horizons, releasing stuff early and often, and learning. And a vision doesn’t necessarily help with that.
My direction? Anywhere. Because one is always nearer by not keeping still
The quote is from Engleby by Sebastian Faulks (cited Good Reads) and pretty much sums up the Agile attitude. Movement is the key rather than the direction of movement. Most Agile initiatives (i.e. projects and product development) are simply about building high priority stuff now, so it is no wonder that the Lean-Agile methods are relatively silent about the future.
In contrast a programme is about organisation change and the vision helps define the future state and attract buy-in – it is a “Postcard from the future”. A clear vision is an essential mechanism for staying aligned with business strategy. Alignment is, of course, one of my three threads within Agile Programme Management. The vision should be stable; not static but broadly resistant to change. Despite Agilists desire to “Embrace Change” a radically changing vision suggests the programme is no longer aligned with strategy and hence raises the question of whether the programme should be shut down.
Continue reading
In his brilliant post Don’t know what I want, but I know how to get it Jeff Patton used a sketch of Mona Lisa to illustrate the difference between Iterative and Incremental development.
Jeff points out that many Agile people use the word “Incremental” when they mean “Iterative”. I believe this is because, in reality, most Agile project combine both approaches and become Iterative Incremental. In fact I can’t imagine delivering software in any other way.
To illustrate what Iterative Incremental means I’ve taken Jeff’s Mona Lisa illustrations and added a third showing a combined Iterative Incremental approach.
Continue reading
Jim Highsmith proposed two simple strategies for successful software development: Build Less, Start Sooner.
Jim’s observation is genius, but I would add “Innovate Constantly”.
Continue reading
You should vet proposed features of a product and, at a higher level, complete projects. A quick and light weight way of doing this is with the 10 questions of the Opportunity Assessment.
Continue reading
So your boss comes to you mid-sprint and demands a new oscillating-email-ingest-engine. Right now. Nothing else is higher priority.
Scrum says “Say no”. I think the discussion is more nuanced.
Continue reading