Change is not_bad
Change Is Not Bad
This is in stark contrast to a traditional collaboration project, where one of the earliest goals is to capture all known requirements and baseline the scope so that any other changes are subject to change control.
Traditionally, users are educated that it’s much more expensive to change or add requirements during or after the software is built. Some organisations quote some impressive statistics designed to frighten users into freezing the scope. The result: It becomes imperative to include everything they can think of – in fact everything they ever dreamed of! And what’s more, it’s all important for the first release, because we all know Phase 2’s are invariably hard to get approved once 80% of the benefits have been realised from Phase 1.
Ironically, users may actually use only a tiny proportion of required work, perhaps as low as 20% or less, yet many projects start life with a bloated scope. In part, this is because no-one is really sure at the outset which 20% of the product their users will actually use. Equally, even if the requirements are carefully analysed and prioritised, it is impossible to think of everything, things change, and things are understood differently by different people.
Agile collaboration works on a completely different premise. Agile collaboration works on the premise that requirements emerge and evolve, and that however much analysis and design you do, this will always be the case because you cannot really know for sure what you want until you see and use the software. And in the time you would have spent analysing and reviewing requirements and designing a solution, external conditions could also have changed.
So if you believe that point – that no-one can really know what the right solution is at the outset when the requirements are written – it’s inherently difficult, perhaps even practically impossible, to build the right solution using a traditional approach to software collaboration.
Traditional projects fight change, with change control processes designed to minimise and resist change wherever possible. By contrast, Agile collaboration projects accept change; in fact they expect it. Because the only thing that’s certain in life is change.
There are different mechanisms in Agile collaboration to handle this reality. In Agile collaboration projects, requirements are allowed to evolve, but the timescale is fixed. So to include a new requirement, or to change a requirement, the user or product owner must remove a comparable amount of work from the project in order to accommodate the change.
So what does the business expect from its collaboration teams? Deliver the agreed business requirements, on time and within budget, and of course to an acceptable quality. All project management professionals will be well aware that you cannot realistically fix all of these factors and expect to meet expectations. Something must be variable in order for the project to succeed. In Agile collaboration, it is always the scope (or features of the product) that are variable, not the cost and timescale.
Although the scope of an Agile collaboration project is variable, it is acknowledged that only a fraction of any product/project is really used by its users and therefore that not all features of a product are really essential. For this philosophy to work, it’s imperative to start collaboration (dependencies permitting) with the core, highest priority features, making sure they are delivered in the earliest iterations.
Unlike most collaboration projects, the result is that the business has a fixed budget, based on the resources it can afford to invest in the project, and can make plans based on a launch date that is certain.