Agile and Fixed Budget ProjectsL e a r n t h r o u g h s h a r i n g

From : Gu l Mohammad

The Big Picture

Framework

Modularity: The process is broken down into various components.Iterative: Short cyclesTime-BoundAdaptive: React and adapt to change along with the new risks exposed during the cycle.IncrementalConvergent: Proactively attacking the risks, the system can therefore roll-out in increments.People-Oriented(Empowering the peoples): Stakeholders involved can help the organic evolution of the system.

Manifesto

Agile framework

Agile Methods

• Scrum• Scrum ban• Adaptive Software Development (ASD)• Agile Modeling• Agile Unified Process (AUP)• Crystal Clear Methods (Crystal Clear)• Disciplined Agile Delivery• Dynamic Systems Development Method (DSDM)• Extreme Programming (XP)• Feature Driven Development (FDD)• Lean software development• Kanban (development)

Advantages

• Helps mitigate changing requirements and priorities•  Lowers cost of change•  Encourages higher quality, simpler code•  Reduces risk and defects•  Maximizes return on investment (ROI)•  Provides visibility into project progress•  Delivers business value earlier and more frequently

Disadvantages

• Needs consistent business involvement• Requires more discipline• May not be applicable all projects, all people and all situations, although it can be applied

in many situations• Does not replace solid software engineering practice – you need to be a solid software

engineer to be a solid agile software engineer

Scrum….

Scrum

It is an Agile project management method

Characteristics: Prioritized work is done. Completion of backlog items Progress is explained Agile Software Development

Overview

Process• Sprint• Daily Scrum• Sprint review and retrospection

Roles• Product owner and product backlog

• Scrum Master• The Team• The Done• Good Engineering practices

Values

• Commitment • Respect• Focus • Courage• Openness

Flow

Sprint planning meeting

Backlog (list of stories)

The backlog in Scrum is a prioritized features list, containing short descriptions of all functionality desired in the product.

Story!!!

Short and simple description of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system.

A typical template:As a <type of user>, I want <some goal> so that <some reason>.As a user, I can backup my entire hard drive.

A big user story is called epic and can be broken down into multiple small stories.

Story Points

An arbitrary measures. This is used to measure the effort required to implement a story.A story point = Complexity + Uncertainty + Effort

Point Size : 1,2,4,8,16 or X Small, Small, Medium, Large, Extra Large. Mostly commonly used series is the Fibonacci series .

Backlog

Burn down chart

Velocity

At the end of each iteration, the team adds up effort estimates associated with user stories that were completed during that iteration. This total is called velocity.

Done

A typical conversation between developer and Product owner.

Product owner (PO): Is the software done? Developer (Dev): Yes, almost. PO: Can we go to production? Dev: No, not yet. PO: Why not? Dev: Well, some bugs have to be solved, some integration tests still have to be run, release packages have to updated, etc. PO: When can we go to production ? Dev: I don't know. . . .

PO: *******************************************To avoid this kind of situation there should be a solid definition of done.e.g. Done = Coded+tested+varified+integrated+Ready for Production

Fixed budget projects

A Note

Agile, by its very nature is inherently an open-ended time-and-material (T&M) type of contract which vendors love but clients are hesitant to sign up.Both the software developer and client organization want to know how much the project will cost, not to mention how long it will take.

Solution

First, it’s important to determine whether you are trying to complete the entire large program as a fixed contract or a first (single) release-type project as a fixed contract.

(we choose later)

Since it will allow both the vendor and the client to learn about the project goals and important Agile principles such as sustainable velocity.

Estimation

• Customer and Vendor finalizes the backlog and becomes to estimate velocity.

• Estimation can be done by comparing with previous stories or knowledge base or whatever technique you use.

• Ideal sprint size is 2 weeks.

• Prepare more than a week efforts. you will most likely still need to re-estimate based on the actual or sustainable velocity that comes into play after five to ten iterations.

• Form the ideal sprint in hours Developers=4 Daily work hours = 6.5 to 8 hours 5 days a week For 2 weeks sprint planning = 1 day and 1 day for retrospection; working days=8 Hours 182 to 224 a week. Man Hours. 28 to 40 Range of Ideal Sprint 246 to 314

Estimation

Backlog stories 30Hours calculated 1000Points 500Sprint size weeks 2(1 day planning + 1 day retro) = 8 daysDevelopers 4Hours/Day (4*8) 32Sprint Hours 320Per Sprint points 160Total Sprints for release 3.125Agility + scope buffer 0.25Grand Total 3.38Release Days 33.75

A rough Estimated Release

Calculating velocity

• Take the stories that have been broken into tasks• Take total estimated hours for all tasks. then we can select how many points can

we put into sprint• Now look at your entire backlog and count how many sprints you will need to complete all of the backlog.• By placing them into sprints based on the velocity and business value, you can

then understand where your natural releases are.

Note: please be wary that everything is based on rough estimation at this time

This would be a pilot release. Once you get through you, the client and your team will be much better on estimation for next release.

Contract Agility buffer

At this point, the contract agility buffer comes into play. Normally we include some level of capacity buffer, typically 20% to 40%. plus some form of a scope buffer.

60/40/20 Rule:• Breaks the release backlog and project scope into a 60%, 40% and 20% prioritized list.• 60% is “must-have,” (Actual project target) • 40% is “would like to have,” (Negotiable: features can change and remove here) • 20% is considered a “stretch goal.” positive buffer

Change Management

Now we have sense of time and size to be able to create a contract, with one outstanding issue: The change control management plan. In essence, there are three main components to consider:

1. A high level of trust to be developed between the client and vendor regarding change control.

2. The basis of the scope is the selected story. In case of change some level of change control is required. Once the new story has been fully defined and accepted, the client should then select an equally sized item from the original backlog to be removed and placed back into the program backlog instead of the release backlog. At that point, a zero-cost of change control is issued to change the fixed-scope portion of the contract.

3. The alternative is that the client wants to add an item to or change a completed item on the backlog without removing anythingfrom the release backlog. In this case, we would again fully develop the new story, and then once accepted, we would create acost-type change control based on the sizing. At a minimum, the cost would change scope, but it would potentially change priceand time, as well.

Final Notes

Make sure the teams complete all of the 60% portion before beginning work on the 40% negotiable portion.

Cost overrunAgile controls the cost overrun with close interaction

AssumptionsTake special care of assumptions. Clear conversations during analysis and RFP process.Building clear expectation and honest communication.One major component to success fully transitioning to the Agile practice is to have a strong and trusting relationship.

Thank You