The document discusses using a hybrid waterfall-agile methodology for large government IT projects. It describes combining the initial requirements definition of waterfall with the iterative delivery approach of agile. This allows for flexibility in scope while maintaining budget and timeline discipline. The methodology involves release planning, sprints, retrospectives, and continuous integration to deliver working software frequently.

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

2. 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. 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 and
During Final UAT
Heavy Throughout
PROD Release One Deployment at
Project End
Continuous Integration

4. 4© Copyright 2016 SingleStone
Combined Methodology
Merge 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. 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. 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
40
42
35
36
2
44
45
14
12
29
3
37
7
5
41
4
18
26
3
9
17
1
27
15
43

7. 7© Copyright 2016 SingleStone
Team Organization Approach
Carefully 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. 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. 9© Copyright 2016 SingleStone
Initial User Story Organization
Sprints
RELEASE 1
Sprint 1 – x POINTS Sprint 2 - y POINTS Ice Box – n POINTS
HigherPriorityLowerPriority
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. 10© Copyright 2016 SingleStone
Requirements  Release Relationship
A typical Requirements to Release “stack”
would look something like this:
Release1
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. 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. 12© Copyright 2016 SingleStone
Delivery Process
Typical Agile Cycle

13. 13© Copyright 2016 SingleStone
User Story 6
User Story 5
User Story 4 User Story 3
User Story 2
User Story 1
Project Requirements - Now
As 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
40
42
35
36
2
44
45
14
12
29
3
37
7
5
41
4
18
26
3
9
17
1
27
15
43
46
48
47

14. 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. 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. 16© Copyright 2016 SingleStone
Contact Information
Troy Henry
• Engagement Director
• Phone: 703.869.8769
• Email: thenry@SingleStoneConsulting.com
Chris Snyder
• CRM Solution Lead, Solution Architect
• Phone: 804.869.3100
• Email: csnyder@SingleStoneConsulting.com
Headquarters
Richmond, VA
4101 Cox Road
Suite 350
Glen Allen, VA 23060
Phone: 804.648.0600
www.SingleStoneConsulting.com