Once the walking skeleton is in place, its structure and behavior may imply substories, or you may find in the next sprint that priorities have changed, in which case the walking skeleton can be put aside. But if you decomposed the story into tasks because it seems easier to complete one task as a “story,” the resulting software will have no discernible added value, as tasks tend to focus on disconnected components, not connected value streams.
Mistaking scrum for agile
Scrum is a process-management technique, not a software-development technique. Ditto for Kanban. Scrum and Kanban without strong agile principles eventually revert to waterfall. This is exacerbated in many enterprise environments by huge initial backlogs (inviting waterfall designs instead of incremental evolution) and “standardized” agile practices.
If you’re concerned about feature lead time -- how long it takes an idea to go from conception to production -- the best way to kill it is to have large queues. Unfortunately, many organizations still plan, authorize, and execute software development projects in large chunks, resulting in huge backlogs from the get-go and guarantees that features at the end of the queue will have terrible lead times.
Suppose you’re going on a run to find a hidden lake you’ve heard about. Would you load up a backpack with everything you own or pack only what you’ll need so that you can keep up a good pace? Huge backlogs are like this; you’re looking to discover/validate feature value as quickly as possible, but your backpack is overloaded from the start.
Projects don’t really exist; they’re a mental model, not an actual thing. We invented projects so that we can talk about a nebulous stream of work as if they were single blocks of time and effort. There are no projects; there are only products. The key is to pare down. Organize projects around an initial set of features that can deliver measurable value, followed by “waves” of small, measurable enhancements.
Never pairing (or always pairing)
Pair programming is loved by some and despised by others. It’s a tool, folks, not a religion. It should be used where it’s appropriate -- and yes, some level of it is almost always appropriate.
Pairing spreads knowledge of the system, tools, techniques, tricks, and so on across the team; reinforces human connections; supports mutual mentoring; and in many cases can produce higher-quality software faster than developers working alone. If you look at a story and think “two heads would be better than one on this,” then pairing is an obvious choice. If anyone on the team can implement a story, then pairing may not be helpful. Like every agile practice, pairing is a tool; use it when and where it is effective.
Sign up for CIO Asia eNewsletters.