What do you build?

Lean and Agile software development frameworks are a great starting point for identifying the bare necessities for efficiently running software projects.  The Agile Manifesto itself is timeless in that it transcends process, rules, methodology and paperwork.  It cuts through to the universal, raw values that compel us to produce working software.

I’m a certified ScrumMaster.  You can take that certification course too, and learn all about the promoted techniques, meetings and artifacts.  What the course won’t teach you, though, is how to fill in the blanks.

One of those blanks is the gap chasm that can exist in your work model between “What do we offer users?” and “what are the concrete components that we build?”

Developers don’t develop user stories; they develop features and functional components.  On the surface, this may sound like semantics, but consider building a search engine.

User Stories answer the question What can I do with the software? Examples of this are “As a user, I can search by string,” and “As a user, I can page through search results.”  Provided that the product manager/owner actually fills in the backstory – rather than offering a meager list of one-liner requirements – the goal of the user story is to give developers enough context to a) coarsely estimate the complexity of the user story and b) identify the feature(s) that fulfill the user story.

There’s where some popular frameworks, including Scrum, dive headfirst into “start the sprint and we’ll see you in 4 weeks.”  Out of the box, there are few suggestions of how to operate after planning meetings and within sprints (iterations), other than “have a daily standup” and “end on time.”

One of the glossed-over steps is the need to synthesize a design for the features (and their inter-dependencies) that your team will use to fulfill the user stories under consideration.  Your architect or technical lead may be the one that produces this.  To extend the rugby metaphor offered up by Scrum: think of this as part of your game plan.

Once you have this game plan in place, your team will have the goods to provide finer-grain estimates for the work at hand.  Also, for you Scrum purists out there: there’s no rule that says you can’t allocate time for progressively elaborating this game plan inside a sprint. The important thing is to be deliberate about your feature breakdown, account for it, and adjust the rest of your schedule accordingly.

The moral of the story is this: Don’t expect too much from the framework you choose.  It’s up to you and your organization to define the processes that govern how you behave within that framework.

This entry was posted in Software and tagged , . Bookmark the permalink.