Our planning process for developing Agile eLearning has become exceedingly lean over the years.
What began with traditional Extreme Programming and Industrial XP planning methods, has shrunk into an ultra-lean process that is thoroughly tuned to our culture and context.
Our culture is not typical.
Nearly everyone in our shop is a veteran coach with 7-10 years of XP/Agile experience.We are co-located and distributed: some of us work together in an office, some are remote and collaborate via Skype and VNC.
Over the past year, we have
- stopped using a planning tool
- stopped maintaining a backlog of stories
- stopped writing user stories
- stopped tracking work on posters or electronic tools
What do we do instead?
We communicate and collaborate a lot, mostly using voice, occasionally drawing pictures and sending email.
Every week we strive to discover the most important customer-oriented or sales-driven work to do, remove “feature fat” and work to ship new features to production.
Feature fat is behavior we thought we needed (or may need, at some later date) and which we can live without for now.
How can we build a product and not maintain a backlog?
If we remember a feature/defect, it is important. If we don’t remember it, it isn’t important.
We have limited time and limited staff. We only focus on important stuff.Large, important features (like our new Test-Driven Development analysis) may take weeks or months to develop.
Nevertheless, we find ways to build and ship primitive versions of a feature that ultimately evolve to become sophisticated over time.
How can we keep track of Work-In-Progress (WIP) without a board or planning tool?
We just talk to each other. We’re all experts and focus on developing and delivering thin vertical slices of useful functionality.
Our WIP rarely carries over into a second week. If a user story is discovered to be too large to deliver quickly, we re-plan it so that it is deliverable quickly.
Our group is happy to accommodate changes in our plans.
For example, this past Monday we decided to refine a part of our new TDD analysis for Java.
By Tuesday AM, I realized a better plan: spend time making TDD analysis for C++.
We re-planned our work Tuesday morning and by Wednesday evening had what is close to a new, releasable TDD analysis lab for C++.
If a story is ready to ship early, and another is taking longer, we may ship twice during the week.
When we have something to ship, we want to ship it. We don’t have any steady beat or fixed length release cycle.
We micro-release opportunistically.
Kanban?
Our planning process is an extremely lean version of Kanban. We manage WIP and value streams without physical markers.
We recently pondered the idea of trying one of the new Kanban tools and decided against it, because we believe it would only slow us down.
Conclusion
Our ultra-lean planning process has evolved according to our specific (and perhaps unusual) culture and context.
Is our planning process a good fit for companies beginning to adopt an Agile process? Probably not. Yet elements of it may in fact be a good fit.
Your traditional Agile process may be in need of a diet. Perhaps our experience will give you some weight-loss ideas.
