SingleStone - Using Agile with Government IT

16
1 © Copyright 2016 SingleStone Agile Richmond The Hidden Agility in Government IT June 16 th 2016

Transcript of SingleStone - Using Agile with Government IT

1© Copyright 2016 SingleStone

Agile RichmondThe Hidden Agility in Government IT

June 16th 2016

2© Copyright 2016 SingleStone

Agenda

Initial Project Requirements

Organization Structure

Release Planning

Sprint 0

Hybrid vs. Waterfall Methodologies

Delivery Approach

Revised Project Requirements

Retrospectives

3© Copyright 2016 SingleStone

Let’s Baseline…

A Waterfall implementation approach varies greatly from that of Agile in some key SDLC areas

Waterfall Agile

Scope Defined Upfront Evolves Throughout

Timeline Defined Upfront Evolves Throughout

Cost Fixed Upfront Determined Throughout

Business Engagement Heavy Upfront andDuring Final UAT

Heavy Throughout

PROD Release One Deployment at Project End

Continuous Integration

4© Copyright 2016 SingleStone

Combined MethodologyMerge these two methodologies and you get the benefits of each

Hybrid Waterfall

Scope Defined Upfront but Evolves Throughout

Timeline Defined Upfront

Cost Fixed Upfront

Business Engagement Heavy Throughout

PROD Release One Deployment at Project End WITH Continuous Integration throughout, in a stable, yet lower, region

Typical Waterfall

Methodology

Agile Delivery Methodology

Hybrid Waterfall

5© Copyright 2016 SingleStone

Hybrid Waterfall - Summary

With a merging of the benefits between Waterfall and Agile methodologies, the Hybrid Waterfall approach requires discipline and leadership throughout, but can yield optimal results for large organizations/agencies

Provides greater flexibility with SCOPE

Maintains discipline in Capacity/Effort (LOE) MANAGEMENT

Enforces baseline BUDGET

Supports initial TIMELINE requirements

Avoids business-user surprises during UAT

Encourages SCHEDULE flexibility within implementation phase

Include CONTINGENCY and recognize and capitalize on DEFINING MOMENTS when the project is at a cross-road.

6© Copyright 2016 SingleStone

User Story 4 User Story 3

User Story 2

User Story 1

Project Requirements at Start

9

19 22

31

24

10 11

6

32

2821

30

8

38

16

33

25

13

23

20

34

4042

3536

2

44

45

14

12

29

3

37

7

5

41

4

18

26

39

17

1

27

15

43

7© Copyright 2016 SingleStone

Team Organization ApproachCarefully establish workstreams that provide comprehensive support for all effort impacting delivery areas

Business Sponsors / Steering Committee

Workstream –Function 1

Technical Resources

Analyst Resources

Workstream –Function 2

Technical Resources

Analyst Resources

Workstream –Function 3

Technical Resources

Analyst Resources

Workstream –Integration

Technical Resources

Analyst Resources

Workstream –Training

Analyst Resources

Workstream –Deployment

Analyst Resources

Workstream – X Workstream - Y

Agency Program/Project Manager

Contractor Program / Project Manager

8© Copyright 2016 SingleStone

Release Planning

Once User Stories have been strategically grouped, it’s important to establish a baseline, and TOTAL Release Plan.

Understand key dependencies

Group “like” stories/reqs

Prioritize “building-block” functionality

Accelerate integration functionality – it is generally a significant risk

Deliver meaningful features per Release

Optimize Workstream alignment and capacity

9© Copyright 2016 SingleStone

Initial User Story OrganizationS

prin

ts RELEASE 1

Sprint 1 – x POINTS Sprint 2 - y POINTS Ice Box – n POINTS

Hig

he

r P

rio

rity

Lo

we

r P

rio

rity

US 001 – <Title> - <Points>

US 103 - <Title> - <Points>

US 104 - <Title> - <Points>

US 003 – <Title> - <Points>

Etc..

US 002 – <Title> - <Points>

Etc.

US 004 - <Title> - <Points>

US 901 - <Title> - <Points>

US 903 - <Title> - <Points>

US 902 - <Title> - <Points>

US 102 - <Title> - <Points>

US 101 – <Title> - <Points>

10© Copyright 2016 SingleStone

Requirements Release Relationship

A typical Requirements to Release “stack”

would look something like this:

Release 1

Sprint N1

User Story N1

Req 1

Req 2

Req 3

User Story N2

Req 4

Req 5

Req 6

User Story N3

Req 7

Req 8

Sprint N2 User Story N4

Req 9

Req 10

11© Copyright 2016 SingleStone

Sprint 0 - CRITICAL

Arguably, the most critical Sprint throughout an entire project is Sprint 0. Setting the stage for the subsequent development activities, Sprint 0 should, at a minimum, define and/or achieve the following:

Establish Sprint Cadence When are grooming sessions?

When are demonstrations?

What are the critical milestone dates within each Sprint?

Who is responsible for what?

Set Expectations of Engagement Review overall release organization

Communicate overall schedule

Procure and Provision Infrastructure and Environments Obtain all necessary hardware and software

Install and configure all software

Complete Administrative Activities Onboard all team members

Complete Security Clearance (if necessary)

Create and activate logon IDs where necessary

12© Copyright 2016 SingleStone

Delivery ProcessTypical Agile Cycle

13© Copyright 2016 SingleStone

User Story 6

User Story 5

User Story 4 User Story 3

User Story 2

User Story 1

Project Requirements - NowAs time evolves, so do requirements and needs

9

19 22

31

24

10 11

6

32

2821

30

8

38

16

33

25

13

23

20

34

4042

3536

2

44

45

14

12

29

3

37

7

5

41

4

18

26

39

17

1

27

15

43

46

48

47

14© Copyright 2016 SingleStone

Path to Success

During development and test activities throughout the course of the implementation phase, typical Agile behavior prevails:

Monitor velocity within each Sprint

Demonstrate ONLY fully-completed User Stories

Attack obstacles and impediments

Follow the established Sprint cadence with great discipline

Prepare to modify baseline Release schedule

Listen to your business users, BUT, keep them focused and aligned with agreed upon decisions and the task at hand

Leverage contingency in the schedule – it is necessary to have a “bug-fix” and “change” Sprint

15© Copyright 2016 SingleStone

RETROSPECTIVE

Agile Retrospectives

are special meetings that take place at the

end of a period of work,

usually an iteration or software release

Purpose of a Retrospective

Help the team inspect and adapt

Let the team pause and move away from what they got done to consider how they

got it done

Poise the team to be (not do) even better next time

The value of Retrospectives comes from…

Each team member sees the project in a different way

Sharing the story of the project from many perspectives opens up new possibilities

Reflecting on experiences together encourages openness and strengthens

relationships

Open discussion of tough issues builds trust

Retrospectives help teams improve

Over time, they help good teams become great teams

..and who doesn’t want to be great?

16© Copyright 2016 SingleStone

Contact Information

Troy Henry

• Engagement Director

• Phone: 703.869.8769

• Email: [email protected]

Chris Snyder

• CRM Solution Lead, Solution Architect

• Phone: 804.869.3100

• Email: [email protected]

Headquarters

Richmond, VA4101 Cox RoadSuite 350Glen Allen, VA 23060Phone: 804.648.0600

www.SingleStoneConsulting.com