Posts tagged agile
Posts tagged agile
Many of us have heard analogies to help us think about delivering value in the form of real working software at the end of each iteration. One of my favorites compares value to a slice of cake. I’m not sure where I first heard the comparison, but here’s the version I like to tell:
Say there’s a baker (delivery team) whose customers come in craving a slice of five layer cake (desired feature) with all its promised yumminess in the chocolate ganache, chocolate mousse, white chocolate, coconut, raspberry, and strawberry filling, but they share with us that they are on a restricted diet (time) and therefore they need our help in being mindful of their calorie intake (what is delivered).
Which path of the knife will they value more? The one that slices horizontally and delivers only the first two layers but is 4 inches wide? Or, the vertical slice that offers all five layers of goodness and is only 2 inches wide?
WARNING! Any attempt to stand between me and my five layers in a real scenario carries danger of having knife yanked out of hand and applied to throat.
Each layer of cake is likened to a component of system architecture from the front-end software down to the hardware it’s embedded on. We can think of the filling as the integration points. In order to say that a feature is really valuable - is really done and potentially shippable - we need it all.
When coaching new agile teams, some will challenge this notion of vertical slices with comments about the complexity of their environment and the impossibility of delivering all layers for every feature in a two-week iteration. It’s usually then that we have an in depth discussion about the art of splitting (or, “slicing”) user stories. We walk through a few of their real-life examples and “aha” moments typically ensue.
And as the concept is starting to sink in, someone might say, “But what about design? I’ve got to think about the database as a whole or performance will be terrible. The UX designer needs time to gather user feedback before they can answer the team’s questions about the UI. Somebody has to have the overall architecture in mind - you can’t just piece it together.” And that’s when we talk about “just enough”, “last responsible moment”, and “real options”, and how the team is in the best position to decide just what those terms mean for their situation.
One day I was searching for a metaphor to prompt thinking about how to tell what’s just enough but not lacking? I like Dean Leffingwell’s allusion to planes taking off and architectural runway. And it got me thinking of another mode of transportation: trains and the tracks they run on.
If the delivery team is likened to a cargo train - a train that needs to start moving and keep moving if it is to have any hope of reaching its destination in a reasonable amount of time - then we might compare the development environment and infrastructure to the tracks. Without enough track in place, the train might be stopped or worse, completely derailed.
Let’s say a train starts in Seattle and is destined for Canada. If we knew almost for certain that our destination was Vancouver B.C. and no track had been laid yet, then we might be tempted to put down all the ties and rails to get us there. But what if we need to stop into a station or detour onto a siding to load more freight? What if all the sudden we learned that instead of Vancouver, B.C, the cargo is expected in Vancouver, WA?
Fortunately for us, railroads are now built in sections and with switches that make it less costly to change direction than it was years ago. In software, some of our most powerful switches consist of automated testing and continuous integration.
For maximum agility — flexibility, adaptability — and minimum cost of rework, we would be laying track down just a few ties at a time, putting ourselves practically under the train while it’s moving. Now some you might be thinking, “Sounds dangerous!” However, the idea is to think critically about just how close you CAN get.
In a place where the delivery team has all the access they need to make necessary database changes to implement a desired feature, the distance equates to keeping time with the train. On the other hand, for teams that need to submit database change requests eight weeks in advance to an external operations department, they look just far enough (perhaps 8-10 weeks) ahead in their product backlog and start preparing the ground to lay the needed track. Obviously, the first case gives us maximum agility and more real options. There’s less agility in looking ahead 8-10 weeks…but it’s still a whole lot more than trying to anticipate needs 6-12 months in advance.
For a closer look at this agile mindset, read how Katrina Lindholm described her approach to UX design at Rally Software.
What do you think of this concept? Have you seen it applied to hardware and embedded systems, as well as to software?