The Kolab development team uses the agile development methodology called Scrum. This is an iterative development process set out to achieve a predictable, consistent flow of incremental improvements to a software product, and as such is basically considered mutually exclusive with the concept of a pre-defined end-result.
As I’ve mentioned many times before, Kolab includes multiple software development projects, including third-party components, that we group together and make form a complete collaboration suite. The product as a whole can never really be finished and justifies, not to say implies, using an iterative process for our own development.
Agility serves this purpose really well — relatively small increases in value can be achieved provided early feedback cycles to adjust expectations and/or implementation, and be adjusted one way or the other as the landscape changes.
However, Agile software development projects are not usually provided guidance and direction to the same tune that waterfall projects are.
With waterfall projects, you outline exactly what needs to happen, and every zig and every zag on that pre-distilled roadmap is considered a full-fledged change — to be requested, processed, reviewed and approved.
The waterfall project methodology teaches us of three terms of particular significance; milestones, roadmap and horizon.
In development processes where teams collaborate to develop software solutions, it is important to point noses in somewhat the same direction. This involves stakeholders such as product managers and sales representatives, architects and developers, customers and consumers. Each with their own discipline may have a very different view of the future ahead, but it is important to, at least, remain connected to the common thread of these views.
This becomes even more important when;
- Stakeholders are geographically distributed and do not regularly collaborate with high bandwidth (face-to-face),
- The participants native tongue is not the language commonly spoken, as nuance is lost and ambiguity is introduced,
- The product is made up out of many separate software development projects,
- The development teams are often a mere participant in third-party software development projects,
- The software encompasses broad topics and requires relatively high degrees of expertise.
In such environment, the use of means to funnel attention on to common, shared end-points aids in establishing scope and focus.
In Agile environments, milestones have little meaning — in some regard, the retrospective at the end of every sprint is a milestone.
Milestones can simply function as a limitation on the scope of development to finish first, before additional work can commence.
For example, the first milestone for Roundcube Next could be formulated as consisting of “Email, Calendaring and Contacts” — no more detailed than that, and without restricting the ways in which to actually achieve any of it. Such milestone (along a longer roadmap) can be split in to several milestones — requirement engineering, design, prototype, proof of concept, implementation, delivery. Each of the smaller milestones can be treated as stringently or agile as seems appropriate or is desired — the end is still the one milestone, functioning as a protection mechanism against “feature creep” and a providing a commonly shared “end point”.
Multiple milestones stack up to a roadmap
A roadmap may include enhancements not already a part of any particular existing milestone. For example, we have a desire to be able to hook up more “apps” to Roundcube Next, most of which to be developed in the future. I could put one such “app” for Instant Messaging on the roadmap for Roundcube Next, but I could not assign it to any one particular milestone.
Awareness of items on the roadmap however allows the software development process to achieve the first milestone with a result that allows it to achieve subsequent milestones, by taking in to account what kind of application model design these items may require.
A roadmap is a perpetually morphing target
It doesn’t stack milestones in order, nor does it establish how many milestones there are, which milestones to achieve when, or in fact which parts of the roadmap are included in any milestone. A roadmap as such is a truckload of desires, that you can, but do not necessarily have to, take in to account when actually implementing forthcoming milestones.
A general, shared comprehension of a roadmap protects a project from straying off a path by ad-hoc zig-zagging, and avoids needs to re-factor after passing milestones.
A horizon is the end of a roadmap
In some regards, it is the same as a vision — a fluid concept not set in stone, and something you’ll likely never actually achieve completely — it should be viewed as to provide guidance in design considerations and decisions throughout the process, but not form the ultimate decision making point for either consideration or decision.
Rather, it is important that developers and stakeholders can, along broad lines, agree that somewhere along the possible 360° horizon is that one slice where they can all point their noses. Speaking of pointing noses in the same direction, please note that you can still get where you wanted to get to, no matter how much you zig-zag.
Again, these terms are more commonly associated with waterfall development processes, i.e. “plan everything between now and the desired end-result up front”, in direct contrast with the Agile development processes, which rarely articulates anything about the desired end-result beyond a vision statement, and is an iterative process for which the results are not outlined at the beginning.
I’m sure you can appreciate though, a shared view on the general direction a project takes, and what road to take to get there should bring a lot more clarity to the project’s future.