Agile frameworks such as SCRUM major on the Definition of Done, or DoD. In the SCRUM the DoD is used to keep the team focused on all of the activity necessary to take a business requirement or user story from conception through to being used by the end customer. This is shared understanding across the team and the concept is applied at user story, feature and increment level. Whilst the DoD is an absolute, unequivocal shared understanding of completion in an Agile project, when you analyse the back log of work, there is nothing absolute that constrains scope. The backlog is a list of work ordered by priority that is subject to regular change. Priorities change, and work is added and removed. As it should be. Agile projects embrace change so there should be no hard scope cut off point.
Many Enterprises that are moving to Agile are coming from a more structure project delivery background. Projects have a clear start, middle and end. They agree what will be delivered and the associated costs at the start. This fixed scope is built and tested in the middle and then deployed to the customer at the end. Some organisations when applying Agile, simply use the start of the project to create a backlog of the work, with a “minimal” design, deliver the software using iterations and then mop up the remaining scope at the end. The project is aiming to deliver as much of the backlog as possible given the allotted time and resource and thereby delivering for a fixed cost. However, many organisations struggle with the implied variable scope in this equation and label project’s that don’t deliver all of the intended scope as a failure.
Often these types of approached reflects some of old school thinking that still exists in many types of organisations. You find this primarily in stakeholders that are not directly involved in the day to day delivery of projects. They think about the world in terms of
Project A will cost £444, end on X and will deliver the complete product 123
The project has an absolute cost and an end date, and it will deliver an absolute scope. But the world doesn’t work like that. There is no black and white, only grey, scope will change, risks will emerge and the minds of the customer will change. The delivery of a product needs to be adaptable and flexible not static and absolute. In my experience the vision of a complete project is based on architectural pureness or what was agreed upfront not what was actually needed by the business or customer.
The viewpoint of completeness can be scaled up outside of a single project. Often Enterprise Architects will strive for a complete architectural vision across a business, whether that be an Enterprise Service Oriented Architecture or a canonical data model shared by all business applications. Here a number of projects need to deliver their predefined scope over a number of years for the EA vision to be realised. However, this doesn’t account for change. How many projects deliver exactly their pre agreed scope? So hoping 4 or 5 will is clutching at straws. The reality is that the course of the business will change meaning another Enterprise initiative has only been partially completed. Another failure. But does it matter if the business is still making a profit and its customers are happy.
Organisations are starting to realise that there is no end. There is no point where the stars will align where there is a perfect portfolio of products or a neat enterprise architecture and neither does it matter. There is no end, only constant change and they are adapting to be better at dealing with this change.
IT visions are still required, only they are no longer static. They are presented as roadmaps, where elements in the near future are more certain and fleshed out than those in the distance. As you move through time in the roadmap, not only are elements less defined, there are more alternatives and variations. The roadmap is dynamic and adaptable, exactly like the businesses they need to support.
And how should this roadmap be presented? The model I prefer is to create work items describing what needs to be done. The things that need to be done soon have a lot of detail added and those in the future can just be a place holder. They are given a priority based on how close to the present they are needed, e.g. high priority = soon, lower priority = future, and the work items ordered by priority. This list is continuously refined as priorities change and details added…, somewhat like a backlog!