I recently became involved in an open source project called AgilePlanner through Bob McWhirter of Codehaus and OpenXource. "Not another agile planner?" I hear you say. Yup! But this one is wiki-based. The wiki itself comes out of Jotspot and is nice and easy to use. Bob introduced me to Scott McMullan of Jotspot who is actively involved in the project and Bob has also organised the participation of a Google Summer of Code student.
I'm interested in this project for two reasons. First, it's open source and there's plenty of room for some competition and improvement in online planning and tracking tools for the poor man. Second, the use of a wiki is worth exploring as the medium for such a tool, especially in the evolution of user stories as part of adaptive planning.
A user story represents a conversation that has occurred between the customer and the developers. It has 3 parts:
- Card: A written description of the functionality used for planning incremental development
- Conversation: Discussions facilitating a drill-down into the details of the functionality required
Confirmation: Acceptance tests capturing the details and used to determine when a user story is complete
Given the successful use of wikis as a collaboration tool in team environments, capturing and organising emerging information, they seem well suited to the Conversation aspect of user stories, i.e. deriving the details through discussion. The developers should discuss the details of a user story with the customer at the point when the details become important, adding notes to the user story as appropriate. You can imagine a user story being a wiki page where these emerging details are recorded.
Closer integration of tracking with FITNesse acceptance tests
Agreements about the functional details of a user story between the customer and developers are documented as acceptance tests.
A number of online planning tools record acceptance tests as note-like elements, perhaps with a checkbox to say 'accepted'. I am sometimes tempted to think about a closer integration between the planning and tracking tool and the build/continuous integration system. My temptation is to provide the customer with a single dashboard, in a single tool, that monitors progress throughout the iteration and assesses the iteration's end result in terms of passing/failing FITNesse acceptance tests. AgilePlanner is a wiki that can embed wiki applications ....
Having said all that, i have not actively pursued this idea because it's not 'the simplest thing that will work'. No doubt my recurring temptation will continue to visit me.
Tags:
agile,
adaptive planning,
agile planning
Links to this post
Agile estimating and planning
Agile estimating and planning techniques are a combined subject that holds particular interest for me. Over time, I've experimented with various techniques and some worked better than others. Estimation is always a lot of 'fun'! How many times do project managers, stakeholders, indeed whole corporations expect estimations to be accurate within a neglible tolerance? Too often. Worse still, they hold you to the original estimates even when they've been empirically modified. But planning is where i see it all go wrong too often, and sadly usually from the outset. Whether it be as simple as not employing adaptive planning techniques where plans consequently take root and become inflexible and pointless, or more subtly because of the way the problem domain or user stories are disaggregated to produce an emerging design with low cohesion and tight coupling.
So i was particularly excited when Mike Cohn started the agileplanning group to review and discuss the draft material for his forthcoming book: Agile Estimating and Planning. It was both fun and educational reviewing Mike's evolving work and offering feedback. And hearing the ideas and input from other members of the group. The content of the book is very rich and serves as a toolkit of techniques for adaptive planning and empirical estimation within the larger context of agile software development. I definitely recommend purchasing a copy of this book when it is published by Prentice Hall in September 2005.
Mike made my day, today. He asked permission to quote me on the subject of iteration length, a subject which came up in one of the many threads that had run in the group. Of course, without hesitation i wholeheartedly gave my consent. Here's the quote:
"Like a heart beats with a regularity that keeps the body going, a fixed iteration duration provides a constant which helps establish a development (and delivery) rhythm. Rhythm in my experience is a significant factor that helps achieve a sustained pace."
Innocuous really, but it's nice to be quoted nevertheless.
I made a post to this blog around the same time titled Fixed iteration length.
Tags:
agile,
adaptive planning,
agile planning
Links to this post
Iterative and incremental development
Typically agile software development combines incremental and iterative techniques to deliver functionality early and often. Many people believe that iterative development is the same as incremental development. In fact, they are different but entirely complementary practices for developing software.
Iterative development
iterate - verb perform repeatedly. Make repeated application of a procedure, applying it each time to the result of the previous application.
Iterative development refactors code repeatedly, making progress through successive refinement. On any given day, a developer repeatedly performs a little modeling, a little coding, a little testing, a little integration using the practice of test-driven development. The completion of each cycle provides feedback for the next cycle.
Using a book-writing analogy (taken from http://www.c2.com/cgi/wiki?IterativeVsIncremental) to demonstrate iterative development. As an author:
- I write an initial draft chapter that's not well organised.
- I review the draft discarding irrelevant and superfluous text, expanding on the important topics, clarifying confusing or poorly explained topics, and sorting out the overall structure and formatting.
- I review again and start to see a shape emerge. I continue to resolve issues.
- I review yet again, etc, until the draft chapter can be considered good enough.
Incremental development
increment - noun an increase or addition.
Incremental development builds and delivers software to a production environment as a series of small and regular releases with expanding functionality. An application is therefore delivered in incremental releases over time, where each release adds new functionality to the previous release.
Again, using the book-writing analogy to demonstrate incremental development. As an author:
- I write the first chapter
- I write the second chapter
- I write the third chapter
- And so on until the book is finished
In Extreme Programming, the term 'iteration' defines a time-box. An iteration can be considered a mini-project whose goal is to produce an increment of functionality with stable, integrated production-quality code. An increment does not have to be a release, i.e. delivered to a production environment. In some circumstances it may not make sense to deploy an increment to production, e.g. the increment may require other software, that will only be developed in the next iteration, for it to be usable by the end-user. Arguably an 'iteration' should've been called an 'increment'.
Note: My previous post Slicing the cake described how to evolve the functionality of a user story through multiple increments. In this context, an increment is not a release nor the output of an iteration. An increment is simply an incarnation of the user story functionality at a point in time. Within an iteration, the demonstrable functionality of a user story will proceed through many increments as the developer completes the engineering tasks. This is an entirely separate concept to iterative development, which of course, the developer is practicing as he refactors the code to improve its legibility, design and structure.
Combining iterative and incremental development
Agile software development employs both iterative and incremental development techniques but also applies feedback across releases or increments, or to use Extreme Programming terminology, iterations. Effectively, incremental development becomes evolutionary, where the previous iteration guides the next iteration.
In any iteration, you should focus only on the functionality described by the user stories in that iteration. You should pay no attention to other user stories, not yet scheduled, which may impact how you choose to implement the current user stories. In practice, during the coding of an iteration, you often need to change or refactor code from previous iterations to accommodate new functionality.
Interesting links:
Iterative and Incremental Development: A Brief History, Craig Larman and Victor R Basili
Tags:
agile,
extreme programming,
iterative and incremental development
Links to this post
