FELINESOFT

AGILE PROCESS WITH A FIXED BUDGET

2

• The challenge• Overview of process • The process• Environments• Release• Managing change• Summary

• Planning• Sprint allocation• Sprint

• Planning• Development• Scrum• Testing• Deployment

• Sign-off• Feedback

Contents

3

CFO VS Developer

4

The challenge

Software development works best using an iterative process with constant feedback (agile, scrum, CMMI) but CFO’s like to know what they are getting and how much it costs before they sign off a project.

In other words, developers want agile and CFOs want waterfall.

How do you square this circle………………………?

5

The solution

An agile process with a fixed cost for a fixed amount of effort. This allows you to use an agile process and manage change like waterfall by tracking items added to the backlog.

Let’s take a look at this in detail…

6

1) Planning2) Sprint allocation3) Planning4) Sprint

1) Development2) SCRUM3) Deployment4) Testing

5) Sign-off6) Feedback7) Track changes

Overview of process

Overview of the stages

THE PROCESS

8

1) Information Architecture and designs are produced either by an external agency or FelineSoft.

2) These are broken up into discrete blocks of work known as User Stories. These will reference the documents provided.

3) All of this is loaded into Team Foundation Server and this is made available on-line through a web portal.

Entering the user stories

Planning

IA

User Stories

9

1) The development team reviews the user stories.2) Assumptions are noted in the User Story in TFS.3) Points are assigned using the Fibonacci sequence. 4) Assumptions are fed back to the product owner

and signed off.

5) User Stories are re-estimated.

Estimation

Planning

10

The sprint plan defines the expected number of sprints based on the estimated user stories. The first sprint is a kick-off sprint and sets up all the environments along with automated deployment. The final 2 sprints are used for any minor change requests and polishing the solution. This is done while final testing is taking place and content is being loaded.

Sprint plan is created

Planning

Start22 Jul

Finish06 Dec

01 August 01 September 01 October 01 November 01 DecemberPlanning22 Jul - 16 Aug

Kick-off Sprint05 Aug - 16 Aug

Sprint 121 Aug - 03 Sep

Sprint 206 Sep - 19 Sep

Sprint 324 Sep - 07 Oct

Sprint …n10 Oct - 23 Oct

Content Loading25 Oct - 21 Nov

Polishing Sprint 128 Oct - 08 Nov

Polishing Sprint 213 Nov - 26 Nov UA

T

Training on Content loading24 Oct

Final Testing24 Oct - 06 Dec

Go-live

Today

11

The estimated user stories are allocated to the next sprint. A spread of user stories sized is selected to ensure you have some 1 and 2 points stories to do at the end of the sprint. The capacity is defined by earlier sprints or for the first one the company average.

Allocation of user stories to sprint

Sprint allocation

1 pts2 pts5 pts8 pts8 pts

13 pts5 pts8 pts8 pts

13 pts

1 pts13 pts5 pts8 pts8 pts

13 pts Capacity 40pts

Backlog Sprint

12

The development team works through each User Story and creates technical documentation for each one. This is all stored in a Project WiKi within your portal. Ensuring you always have complete documentation for the project. This is also the final chance to confirm User Story estimations.

Confirming the technical approach to each user story

Sprint planning

13

Test plan writing is done during the planning stage. Tests are created in test manager and associated with User Stories. Each test plan is signed off by the client- this ensures that all parties understand the acceptance criteria during development, testing and sign-off.

Test plan writing

Sprint planning

SPRINT

15

• User Stories are completed by the development team.

• Each night the code is automatically deployed.

• The test team tests the completed user story and logs any bugs associated with the user story and assigned to the developer.

• Each day a SCRUM takes place to ensure that there are no impediments.

The delivery of release quality code

Sprint

16

Development is done in VS.NET Premium 2012 with ReSharper. This ensures the development team has the maximum productivity with the best tools for the job. Each developer also has a minimum of iCore5 with 8GB of RAM and 17” monitors.

Development

Sprint

17

Each day a SCRUM takes place where impediments are raised. These are tracked in TFS as issues and associated with a User Story. They can also be found in the risk register Excel sheet in our portal. This ensures that our client can easily access the list even without VS.Net.

SCRUM

Sprint

18

Code is checked by the development team once each User Story is completed. It is then deployed automatically each night to the integration server. As there is a zero overhead no time is wasted ensuring the testing team have the latest code ready to test. This ensures bugs are fedback to the development team as quickly as possible.

Deployment

Sprint

TFS Build

Integration

Checked in code is built

Nightly and deploy

19

Testing is completed using VS.Net Test and Test Manager; all bugs are recorded directly in to TFS and associated with the User Story. Screen shots can be captured along with videos of how to reproduce the bug and all are stored directly in TFS. This is all accessible through your on-line portal.

Testing

Sprint

CLIENT SIGN OFF AND FEEDBACK

21

Once all User Stories have been passed by the test team the branch is released to staging where the client can sign it off based on the agreed testing plan. At this stage only bugs that don’t comply with agreed testing scope are raised.

Deploy to stage for review

Client sign-off and feedback

TFS Build

Integration

Checked in code is built

Nightly and deploy

Stage

Bugs

All User Stories passed

22

Feedback is provided using the Microsoft Visual Studio 2012 Feedback Tool. This allows you to add bugs, change requests and minor alterations directly into the development environment, using screen capture, voice and attaching files. This greatly reduces the number of emails and increases clarity of understanding.

Feedback

Client sign-off and feedback

ENVIRONMENTS

24

Environments

The agile process does not work without continuous testing. To enable this you must reduce the overhead of deployment as much as possible.

This is achieved through automated deployment and the right environment setup.

25

Environments

Developers1 ͙� .. n

Features1 ͙� .. n

Integration Stage Production

26

• Each developer has their own setup.• Features are deployed to a

new environment for testing before being merged into the main branch.• Integration is used by the

test team to ensure the main branch is good.• Stage only takes release

branch for final testing and UAT by the client.• Production is the live

environment.

Environment per person and task

Environments

Developers1 �͙ .. n

Features1 �͙ .. n

Integration Stage Production

RELEASE

28

The final sequence before go-live ensures each of the major areas are covered and future updates of the site are made as quickly and cost effectively as possible through the automation of testing of the site’s major features. The site is tested for performance and security along with a final set of regression testing. The final sweep is then completed with the client before sign-off of the site and go-live.

Final testing before go-live

Release

Finish06 Dec

November December

Write release test plans

Content Loading

Polishing Sprint 1

Performance testing

Functional / Regression Testing

Polishing Sprint 2

Automate Smoke Tests

Security Test

Client UAT

Training on Content loading24 Oct

Final Testing24 Oct - 06 Dec

Dry run 22 Nov

Go-live06 Dec

MANAGING CHANGE

30

All projects have some amount of change and thus managing this is important. FelineSoft achieve this by tracking all the User Stories added following project planning. These user stories can then either be completed out of an agreed contingency or additional change request budget. FelineSoft recommend that at least 1 additional sprint is budgeted for in order to handle the changes. These are shown in the project plan as polishing sprints. All changes can thus be exported from TFS into an Excel sheet for analysis by stakeholders.

The change request

Management of change

2 pts5 pts8 pts8 pts

13 pts5 pts8 pts

8 pts13 pts

Created during planning

Added after planning

Change Request

Scope

31

Summary

The agile fixed price process is perfect for clients that need to keep their CFO happy with a fixed price and fixed budget or have a defined scope from IA and design. This allows you to leverage all the benefits of agile while keeping to the principles of waterfall intact.

If you don’t have design or IA then there is always “Change for free money for nothing” but that is for another time.

32

Contact Us

This presentation was written by Ralph Johnson of Felinesoft and this is the process Felinesoft use to manage clients that want to work agile but still require a fixed price.

Please get in contact if you have questions or what to work with us.E: sales@felinesoft.com T: 0117 325 1902