Sunday, May 6, 2018

Delivering without a scope in agile projects | Supreme Agile

In traditional projects, the 'Scope' reflects the answer to two main questions of the 'What should be delivered?'  and "How will it be delivered?", it's the constraints that keep the organization from exceeding the requested scope as asked by the customer (What + How = Project Scope).

Let’s say that your project is to deliver a three layer of a chocolate cake, in that case, the "What" will refer to the "Chocolate cake" and the 'How' will refer to the effort that goes into preparing the cake (Materials, stove, recipient Etc.).

The scope is a very important constraint in regardless the project management approach, but the importance of the scope is reflecting more easily in traditional projects where you can hear the very common phrase of "If it's not in the scope, it’s not in the project". In traditional projects, the organization and the define the scope at the start of the project and prior to many other important aspects such as the schedule and budget.

In traditional project management, these three aspects (Scope, Schedule, and budget) are also known as the "Iron Triangle". In this 'Triangle' each one of the three corners reflects one aspect from this list but also determines the correlation among them (Change in one aspect will affect the other two). Just for example, if the project schedule is changed, the organization will have to change the scope of deliverables and the budget that they can invest to make it happen.

The scope of Agile Projects

if you familiar with the agile manifesto and it's 12 core principles than you already know that the project scope is a variable that is expected to be changed "Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage".

In agile projects, the scope is just another variable that comes after that the organization has determined the costs and schedule at the beginning of the project. The schedule and costs are based on the customer that determines when he wants to finish the project and how much he's willing to pay for it.

Once the organization has these two variables of budget and schedule, it’s time to determine the project scope which is the responsibility of the team to add the relevant stories (Functional and nonfunctional) to the product backlog.

When the project starts the budget and schedule are supposed to remain constant throughout the project, in agile, there is no release date for the completed scope, the customer will receive all the scope they pay for based on what is prioritized by the product owner and within the original constraints. 

Agile Quality and Value

In agile, the quality and value are a key factor in the project scope. The agile team cannot deliver low-quality deliverables that will encounter the agile definition of done (DoD). They must ensure that each incremental release will meet the quality standards as specified in the DoD, if they fail to do so, it may break the trust between the organization and the customer and affect the future of the entire project.

To ensure that the team can deliver high-quality releases, the project scope must already include the time and effort the team will need to invest to meet the Definition of Done. This is the only way to allow the team to deliver working software under narrow timeframes and with the expected quality.

To see the difference between the two methods (Traditional/Agile), let's develop an ATM machine:

Traditional ATM (Scope, budget, and schedule at the beginning)
In this project, the organization will determine the scope, budget and schedule at the start of the project that will include a detailed plan prior the team start to work, the plan will include the hardware specifications, ATM Functionality and anything else that they will need to complete the project. 

Agile ATM (Budget, and schedule at the beginning)
Now let's take a look on how the same variables are different when using the agile project, the budget and schedule defined at the start of the project, for example, the project costs should not exceed 1M$ and the ATM should be delivered in 3 months.

The remaining variable of the project scope is still not defined at this point, the project scope will be determined only when the development team will start to work on the project and add their PBI's to the product backlog. Once the team adds their PBI's, it’s time for the product owner to prioritized which items should deliver first to increase the ROI.

Changes are here…!
Now, let's say that the customer wants to add/modify an ATM functionality, in the traditional project the scope is already defined and based on a fixed price and schedule that sighed with the customer, this will make it almost impossible for the team to add these new requirements (Remember that schedule and cost already been used during planning phase).

In agile projects the scope is flexible enough to add these new requirements and to allow the product owner to re-prioritize the product backlog and deliver the exact scope that the customer asks for (The same timelines and budget are kept, but the customer will get a different ATM than he asked at the beginning of the project). 

No comments:

Post a Comment

My Presentations