Alok Joshi from our Melbourne office shares his insights on whether Agile Scrum can work on Fixed Price Data Warehouse projects.
I’ve often heard the argument that Agile Scrum cannot fundamentally work with a fixed price project due to the nature of the predetermined scope of work. Aside from the price, what are you actually fixing? Is it requirements or outcomes? Outcomes are subject to the interpretation and skill of the person / team tasked to complete the project, whereas requirements can be agreed and clarified. For example, if the requirement from accounting is to have a quarterly report that shows month end expenses by each department, is the outcome then to show the information in a bar chart? Tabular structure? Line graph? This can be clarified with accounting, but at the end of the day it is up to the team executing to provide the capability. This especially goes for more complex scenarios requiring specialised skills like dimensionally modelling a data warehouse. A requirement may be to model the data to optimise for scalability and performance – there could be a dozen ways to achieve this outcome when modelling a data warehouse. So let’s talk about what we should be actually fixing here: The requirements to be met, and how the core components of Agile Scrum can be adapted.
Requirements and Product Backlog
The product backlog in a fixed price engagement is your scope of work and in Agile Scrum, this is your master list of requirements to be prioritised. What this means is that for fixed price, all items in the product backlog need to be completed by the end of the project. This is in contrast to a scrum backlog, where the highest priority tasks are “picked” at the start of each sprint. Therefore, all components of the development lifecycle are captured here in the form of tasks (or stories if applicable) from requirements, analysis and design, to build, test and deploy. This is your work break down structure and your map to follow for the project.
In Agile Scrum, Product Owners have the opportunity to revisit the product backlog anytime and reprioritise the tasks that they want the team to tackle in the next sprint. So why not in a fixed price project? The only difference is if new items are brought in to the backlog and prioritised or removed, this equates to a change in scope and the relevant change control processes would be engaged i.e. change request and subsequent agreed re-scoping. This shouldn’t be seen in a negative light, but as an essential step in ensuring customer requirements are met.
Planning and Estimation
In Agile Scrum projects, sprint planning is where the team would come together and decide as a team, what is achievable for the duration of the sprint, with a sense of priority and guidance from the product owner. The team picks tasks from the top of the product backlog and estimate the effort required to complete it.
In a fixed price project however, the sprint goals are predetermined, the backlog priorities are already set, and the tasks to be completed are already estimated to be feasible for the sprint duration. So why hold a sprint plan? The simple answer is to create the opportunity to challenge the timeline, the work being performed and the outcomes the sprint is looking to achieve. Are the goals we set 2 months ago for this sprint still relevant? Are there more pressing items to address? It is better to answer these questions intermittently than at the end!
Showcases and Retrospectives
Showcases enable the team to demonstrate the capability that has been delivered in the sprint. This does not need to change in a fixed price project. The team can organise showcases so that whatever part of the project they are working on can be demonstrated to stakeholders. It is better to get feedback (good or bad) early so you know what works and what needs to be addressed.
This is where retrospectives in Agile makes the process of continual improvement within the team much more achievable. It is important for the team to reflect on what went well and what could have been done better. Holding these sessions is just as important in a fixed price engagement. If the processes or products being developed are found to be not working, it provides the opportunity once more for change control processes to kick-in and allow the team to continue down the right path.
At the end of the day, it’s about expectations that are agreed upon and being able to manage this as flexibly as possible when something does come up (and it will!). Having a framework to help keep everyone (delivery team, project manager, customers/stakeholders) on board and aligned makes for much happier outcome.
What do you think about applying Agile Scrum to Fixed Price Data Warehouse projects? Have you used this approach? Share your thoughts.
