Our Agile Meta-process
Our team is talking about going agile, discussing ways to bring in an underlying iterative backdrop to what is largely a waterfall context. Though we live within the constraints of Sun's product lifecycle process, we believe that we can become more effective, flexible and productive by intentionally working in various aspects of an agile mindset. In fact, the way we're probably going to be able to accomplish this will itself be agile - a little bit at a time, course correcting as we go, getting feedback from our stakeholders.
So what we're really doing is something of a "meta-process" - figuring out what process to use to bring in a new process. Our "stakeholders" in this meta-process will be our managers, who will need to continue with their own existing processes but be able to integrate our progress reports, issues, bugs and so on without disruption. Ideally, we are able to demonstrate to our managers (and ourselves!), over time, the value-add of an agile approach.
One of the goals is to avoid the Big Bang Integration we've seen in the past. We also target getting "aspects" done as we go instead of waiting until the end (logging, I18N, diagnostics, persistence, ...). We're convinced that this will facilitate communication around all areas of the product - in particular acknowledging the realities of our Sun product lifecycle needs - early on, addressing any risks and unknowns upfront instead of bumping into unforeseen problems later in the cycle.
Since we have a new product spinning up as we speak, we think that now is the right opportunity to rethink our approach from the inside-out, simultaneously educating ourselves on agile process fundamentals and engaging with others here at Sun who are already on that road. Here's our first cut at how to proceed internally with our new product, which involves web-based management of iSCSI devices:
The first release is a thin vertical slice, focusing on "happy path"
only, and addresses one user story only - as pretty much an "excuse" to
get all infrastructure together upfront. The release might consist of
something like this:
- Identify one user story
- Establish infrastructure, process details
- artifacts, documentation (functional spec, etc.)
- daily builds, automated test runs
- code reviews, code quality exercises (findBugs, etc.)
- product installation (in our case, this involves Sun packages)
- determine remote connectivity as needed
- establish servers and storage devices that can serve as a test bed
- Implement components for a thin vertical stack
- barely sufficient UI design (do the least we have to do to support a quick A-to-Z supporting the user story)
- barely sufficient large-grained components and structures: view helper, business delegate, remote
adapters (translate device information into application objects)
The second release still focuses on happy path, but sets a basis for unhappy path and performance testing. It might be something like this:
- Identify 2-3 more user stories
- Extend existing stack components to support additional features
- Backfill functional spec, etc. with "just enough" documentation - updates to existing content, add new content for next iteration
Release #3 addresses unhappy paths for the existing features. Here's where we establish conventions/idioms for logging, diagnostics, exception handling, I18N, 508, etc., and continue to backfill documentation and other artifacts. No new features here. Accept, Demo, Release and Review.
Release #4 establishes a performance baseline. Here's where we set up our framework for stress and regression testing so adding new features gets easier as we go forward. We set our standards for what's expected performance-wise, and immediately address problems as they appear here and going forward. No new features here. Accept, Demo, Release and Review.
Subsequent releases are now wide-and-deep:
- Add new features
- Extend stack components to support them
- Add unit, integration and system tests
- Address unhappy paths
- Add new features to performance baselines
- Backfill artifacts, documentation
- Accept, Demo, Release and Review
- Repeat until "success"
I would suggest that "success" is not the same as "product has shipped"; I'd define it as "we have customers actively engaged in the product, using it, succeeding with it, and communicating with us about future releases". Regardless, the Sun product lifecycle has its own timeline boundaries, so while a true Scrum might indefinitely continue to define releases with new features, it eventually becomes time to start our next product cycle. Ideally the "success" part precedes that stage.
