Agile Delivery Framework

December 2016
AGILE FOUNDATION

2
Overview

Core Values of Agile Development Methodology

Individuals & Customer Responding to

Working Software
Interactions Collaboration Change
over comprehensive
over process and documentation over contract
over following a plan
tools negotiations
Source: https://agilemanifesto.org
3
Principles
Our highest priority is to satisfy the customer through early and continuous delivery of valuable
software.
Welcome changing requirements, even late in development. Agile processes harness change for the
customer's competitive advantage.
Deliver working software frequently, from a couple of weeks to a couple of months, with
a preference to the shorter timescale.

Business people and developers must work together daily throughout the project.

Build projects around motivated individuals. Give them the environment and support they
need, and trust them to get the job done.
The most efficient and effective method of conveying information to and within a
development team is face-to-face conversation.
Working software is the primary measure of progress. Agile processes promote sustainable
development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

Continuous attention to technical excellence and good design enhances agility.

Simplicity--the art of maximizing the amount of work not done--is essential.

The best architectures, requirements, and designs emerge from self-organizing teams.

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its
behavior accordingly.
4
 Value Proposition
Ability to deliver incremental value
Greater visibility into project progress
Adjust and mitigate issues early in the process
Re-focus time & energy from documentation to building and testing software
Use of fixed time intervals to more effectively prioritize scope and measure progress
Multiple ways to implement agile
Lean, Scrum, Kanban, Extreme Programming (XP)
Build 20% of the features that deliver 80% of the functionality

5
 Key Terms & Concepts
Term Definition
Scrum Specific methodology used to implement the agile beliefs and principles
Scrum Master Person who is the team lead, their role is to coach and remove road blocks to the team can fulfill the work

Backlog Listing of stories and/or requirements that need to be developed

Epic A large feature or requirement that is required to be broken down into smaller components (stories) before
development
User Story Method to capture feature and functionality from the users perspective.

Points The values that are assigned to stories during estimation. Values are 1 8. 13 is used when a story is larger than an 8.
These values are used to calculate burndown.
Burndown Way of measuring progress during a sprint. Burndown = the number of point planned against the points completed.

Velocity Measure of how fast the team is completing points during the project across multiple sprints

Sprint Time interval in which a specific set of stories and points are allocated to complete. Frequently the intervals are set in
weeks, usually no less than two and no more than 4.
Retrospective Lessons learned session done at the end of each sprint to identify lessons learned that can be applied to future sprints
to maximize velocity
Sprint Plan Identification of the user stories, estimates and bugs that will be done in the sprint
Shippable Tested functionality that could be used by the customer
Product
Story Consistent review of the backlog in order to ensure priorities are current, and stories content is current
Grooming

6
Team Roles & Culture
Team Principles
Team is self-organizing and self-policing
Scrum Master is a facilitator to help the
technical team build the software
Product owner defines features, functionality,
and prioritizes backlog

Source: Manusis

Culture Principles
Collaboration is paramount
Cultivation of people and skills to
achieve excellence
People can be trusted to manage
and execute work
Environment that adapts and
responds to change
7
Work Flow
Initiation & Scope

Backlog

Plan Design

2-4
Shippable Weeks

Product Deploy Develop

Test

8
 Example Work Plan
Week 0 Week 1 Week 2 Week 3 Week 4 Week 5 Week 6 Week 7 Week 8
Sprint 0 Sprint 1 Sprint 2 Sprint 3
Initiation
(Planning) (Development) (Development) (Testing & Release)

Project Tool Set-Up Sprint Plan Sprint Plan Sprint Plan

Scoping Team Role Definition Story Design Story Design Bug Fixes
User User Story Story Development Story Development Bug Testing
Story Prioritization, Initial Story Testing Story Testing Testing
Backlog Estimation, Planning Story Deployment Story Deployment Product Deployment
Team Foundational Stories Story Review Story Review Backlog Updates
Assign Data Model Backlog Updates Backlog Updates Bugs
ments Environment Bugs Bugs New Stories
Set-up New Stories New Stories Code Review
Code Standards Code Review Code Review Burndown
Testing tool set-up Burndown Burndown Calculation
Velocity Estimate Calculation Calculation Velocity Updates
Velocity Updates Velocity Updates Retrospective
Retrospective Retrospective

9
 Example Sprint View
Day 1 Day 2 - 9 Day 10

Plan Design Development Test Deploy

Select & Assign User Programming &/or

Develop Requirements Execute Tests KPIs
Stories Configuration

Select Bugs Develop Technical Design Write Tests Code Review Review & Demonstrate

Assign Points (Estimates) Retrospective

Team selects the user stories based on priorities that were defined in initiation
Team provides estimates
Team commits to completing the user stories
Team maintains progress communication via Stand-Up, which is 15 minutes
What was completed yesterday
What is on deck for today
Road Blocks
Problem solving, issue resolution occurs OUTSIDE of the stand-up
10
Example Sprint Boards

11
AGILE @ TECTONIC

12
 Tectonic Value Proposition
1. Structure to collaborate &
demonstrate progress to our

Higher Value
customers

2. Increased accountability for Working Software Process & Tools

deliverables based on fixed time Respond to Change Documentation
intervals Customer Project Plans
Collaboration
3. More project hours available to work Interactions and

Lower Value
on design, configuration, code less Individuals
on documentation

4. Tools & process enable the team

The secret to getting ahead is getting started. The secret of getting started is breaking your
complex overwhelming tasks into small manageable tasks and then starting on the first one.
- Mark Twain, American Author

13
Tectonic Work Flow
Contract Signature
Initial backlog may consist mostly of Themes, and Epic
Details will not be known at time of initial backlog creation
Detailed requirements will be identified along the way

Backlog

Plan Design

3
Review Weeks
Working Develop
System & Deploy

Test

14
 Tectonic Sample Work Plan
Week Week Week Week Week Week Week Week Week Week Week Week
1 2 3 4 5 6 7 8 9 10 11 12

Sprint 0 Planning & Design Sprint 1 - Implementation Sprint 2 - Implementation Sprint 3 - Deployment

High Level Functional Design Backlog Prioritization Backlog Prioritization Release

High Level Technical Design Sprint Plan Sprint Plan Backlog Updates
Story Development & Story Design Story Design Transition to AMP
Prioritization Story Development Story Development Final Burndown
Initial Estimation & Planning Story Testing Story Testing Final Velocity
Testing Tool Set-Up Story Deployment (Non-Dev Story Deployment (Non-Dev Retrospective
Jira or Plan.io set-up environment) environment)
Team Role Definition Story Review Story Review
Define standards Backlog Updates/Grooming Backlog Updates/Grooming
Foundational Stories Bugs Bugs
Environments New Stories New Stories
Initial Data Loads Review Existing Review Existing
Release Plan Code Review Code Review
Velocity Estimates Burndown Calculation Burndown Calculation
Velocity Updates Velocity Updates
Retrospective Retrospective

*There could be multiple sprints dedicated to deployment if there is a formal UAT

15
 Tectonic Example Sprint View
Day 1 Day 2 - 14 Day 15
Detail Design
Plan Deploy
Review Acceptance Criteria
Develop Technical Design

Select & Assign User

KPIs
Stories

Select Bugs Review & Demonstrate

Test Develop
Execute Tests Create Code/Configurations
Assign Points (Estimates) Code Review Write Tests Retrospective

Sprint always starts with planning and ends with deployment

Deployment may include moving configurations to a different environment
Design, Develop, Test are non-linear tasks that occurring at various times for each story within the
sprint
Documentation is managed within the story

16
 Tectonic Roles/Responsibilities
Agile Role Tectonic Role Responsibilities

Product Owner Solution Architect Responsible for defining and prioritizing user stories, facilitates design for each
user story. Primary liaison with the customer. Responsible for doing the Sprint
Scrum Master Project Manager Facilitates team progress by coaching team members on agile methodologies,
managing KPIs through burndown/velocity, promotes issues/problem solving by
coordinating as needed. Manages overall project budget. Leads sprint planning
and retrospectives
Contributor Data Architect Facilitates data and information design, provides mentorship and guidance on data
standards, procedures and best practices
Contributor Technical Architect Provides coaching and mentorship on programming, configuration, integration
best practices. Executes code reviews with development teams.
Contributor Developer Responsible for creating software, receives coaching and guidance from
Architects. Includes configuration, code and integration development.
Contributor Business Analyst Responsible for documenting user stories, responsible for confirming software
meets requirements defined.

Contributor Business Analyst Responsible for writing and executing tests to evaluate fitness of the code to the
requirements

Contributor Release Manager Person who is responsible for creating the deployment packages (change sets) and
migrating them from environment to environment. Can be filled by a developer

17
The Role of the Customer

The Solution Architect will always be the

Product Owner, as well as the primary
liaison between the development team
and the Customer

Source: Agile Samurai

Customer Activities/Responsibilities
1. Approver of Story Priorities
2. Approver of Release Plan
3. Participant in Sprint Reviews
4. Contributor of themes, epics, stories, bugs The relationship between the Solution
Architect & Customer requires frequent
5. Approver of Releases
interaction
6. Approver of All Artifacts Build stories
7. Participant in Sprint Planning (optional) Validate priorities
8. Participant in Customer Retrospective (optional) Solicit timely approvals and feedback

18
 Tectonic Sprint Meetings
Meeting Name Time Medium Objectives Participants

Sprint Planning 4 5 hours on Video Conference Choose Stories Business Analyst, Project Manager,
Session Day 1 of the Assign Stories Solution Architect, Technical Architect,
sprint Estimate Stories Customer (optional), Developers
Daily Stand-Up 15 Minutes Conference Call Accomplishments Entire team
Road blocks
Tasks planned
Daily Huddle 15 Minutes Minor Issue Resolution

Solution 1 2 hours, 1 Conference Call Define solution design for Business Analyst, Solution Architect,
Review/Design 3X/week stories Technical Architect
Issue Resolution, 1 2 hours, as Conference Call Discuss major issues, Project Manager, Business Analyst,
Problem Solving needed roadblock and define plans Solution Architect, Technical Architect,
for resolution Developer, Quality Assurance Analysts

Code Review 1 2 hours Video Conference Review configuration/code Technical Architect + Developers

Sprint Review 2 hours Video Conference Review stories completed Business Analyst, Developers, Solution
to date Architect, Quality Assurance Analysts
Story Grooming 30 minutes 1 Conference Call Validate story priorities, Business Analyst, Project Manager,
Sessions hour 2 3 updates, scenarios Solution Architect, Technical Architect,
X/week
Retrospective 1 hour Video Conference Review of KPIs Entire Team
Lessons Learned

19
Work Products Overview
1. Jira & Plan.io are the tools available today
Going forward Clients should have access to those tools to ensure
transparency and ease of collaboration and approval

2. Documentation is managed with the story, unless required by the customer

Solution Design is done on a per story basis
Integration Design is done on a per story basis
Tests are written for the story
Detailed technical design is done on a per story basis

20
 Tectonic General Work Products
1. Jira & Plan.io are the tools available today
Going forward Clients should have access to those tools to ensure transparency and
ease of collaboration and approval
2. Documentation is managed with the story, unless required by the customer
Solution, Integration, Technical Design is done on a per story basis
Tests are written for the story and captured with the story
Data Migration work products may be managed and tracked separately
Artifact Name Tool** Owner
Tool Set-Up Jira, Plan.io Tool Administrator
Backlog Jira, Plan.io Business Analyst
Team Roster Word, Plan.io, Jira Project Manager
Code/Config. Standards Word Technical Architect
Milestone Plan MS. Project Project Manager
Release Plan Word, PPT, Plan.io, Jira Project Manager
Solution Design Plan.io, Jira Solution Architect
Data Migration Plan, Checklist Word, Excel Technical Architect
Integration Design Plan.io, Jira Technical Architect
Deployment Plan, checklist Word, Excel Technical Architect
21
 Tectonic Sprint Work Products
Artifact Name Tool** Owner

User Stories Plan.io, Jira Business Analyst

Story Requirements Plan.io, Jira Business Analyst

Story Design Plan.io, Jira Solution Architect

Sprint Test Plan Plan.io, Jira Business Analyst

Sprint Test Cases Plan.io, Jira Business Analyst

Sprint Test Results Excel, Word Business Analyst

Bugs Plan.io, Jira Business Analyst

Software Configuration/Code GIT Technical Architect

Code Review Results Word Document Technical Architect

Burndown Plan.io, Jira, Excel Project Manager

Velocity Plan.io, Jira, Excel Project Manager

Retrospective Word Project Manager

22
AGILE IN PRACTICE

23
Tectonic Project Approach

Pre-Initiation & Planning & Implementation Deploy (Last

Planning Design (Sprint 0) (Sprint 1 - N) Sprint)

SOW Signed
Internal Set-Up Release Plan Approved Releases
Kick-Off Backlog Approved
High Level Functional Deployment Plan
& Technical Design
Scope/Estimate
Validation

24
Pre-Initiation & Planning

Contract Set-Up & Signature

Customer understands
Preference on setting up Agile based milestones Tectonics' commitment
to Agile as our way to
Resource Allocation deliver & corresponding
value proposition

Methodology Selection Account Manager,

Project Manager
Methodology/Approach is determined based on
discussions with client and delivery leadership for best fit
communicate with the
Deliverables, work products and supporting tools are customer on how their
defined project will run
Sales Transition to Account Manager & Project
Manager

Kick-Off Meeting

25
Planning & Requirements Sprint 0
Initiation is Complete:
 Contract Signed
 Kick-Off Meeting Complete
 Customer High Level Understanding on Tectonic Process

Customer introduction to Tectonic Approach These occur in

collaboration with the
Backlog Developed Requirements Sessions
customer.
Theme & Epic Breakdown
Prioritization
They may take the
High Level Functional & Technical Design
format of in-depth
Tool Set-Up requirements
Plan.io/Jira workshops, or just be a
couple of days onsite
Code/Configuration Standards

Release Plan Stories, Release Plan

must be approved by the
Team Roles Defined customer

26
Sprint Planning Agenda Sprint 1 thru N
Planning & Design Complete:
 Backlog approved
 Release Plan approved
 High Level Functional & Technical Design Approved

Stories Selected
Team determines how many points they can Customer confirms
accomplish in each sprint the stories selected
Selects stories to equal number of points the can for the sprint
be accomplished
Influenced by past burndown and overall velocity If customer prefers
more of a waterfall
Stories Estimated approach, we adjust
During selection points are assigned based on the communication
learnings of previous sprints to the customer, but
still involve them in
Stories Assigned the prioritization.
Team members select the stories they want to
work on

27
Sprint Planning Agenda - Deployment
Implementation Complete:
 Releases approved
 Deployment Plan approved

Deployment can
Stories Selected mean to production
or to UAT, if there is a
Team determines how many points they separate UAT
can accomplish in each sprint environment that
Selects bugs and deployment readiness must be formally
tasks to equal number of points the can deployed to.
be accomplished
Influenced by past burndown and overall Customer is engaged
velocity to prioritize bugs and
deployment activities
Stories Estimated
Could be one or two
During selection points are assigned iterations focused on
based on learnings of previous sprints deployment
28
Requirements Capture Workflow

Scenarios
Discrete functions that
the user wants to be
Different ways that the story
able to perform
can be fulfilled i.e. different
Big Features or Functions screens, different data,
within the Theme
Story parameters

Set of Related Epic Scenarios

Features or Functions
Story
Theme

Epic Story
Requirements Capture Workflow Example

Story
I want to deactivate
users who are no Scenario
longer in sales so they
Epic cant see the reports
Users exists and can
Epic be added
I want to add users so
Add & Maintain Users that they can view
reports
Theme User is not yet in the
system
I need to bulk upload
users so that I dont
User Management
have to enter them 1
by 1

I want admins to have

an edit capability so
Manage Permissions
that they can modify
reports

All Stories have associated acceptance criteria and test cases.

Story Elements What goes into a story
Theme: User Management
Complexity Guidelines:
Epic: Add & Maintain Users 1 Point = 2 4 hours
Story Name: Add Users 2 points = 4 10 hours
Story Actors: Sales Support 3 Points = 10 - 16 hours
Priority: Business Priority 5 Points = 16 - 24 hours
Complexity: Level of Effort (Points) 8 Points = 24 40 hours
Scenarios: 13 Points = 40+ Hours
User account exists and can be added
User account doesnt exist and cant be added If something is a 13, it needs to
Acceptance Criteria be broken down into additional
User is successfully added and can view the reports stories
Users can only be added if they have an account
Tests & Expected Results *Complexity includes all tasks
Add a user without an account
User not added (documentation, config, code,
Add a user with an account
User added test)
Log-in as added user to view report
Report is viewable

31
Release Plan
Sprints can be grouped together into a Release that can be deployed to the
customer. There could be multiple releases, or a single release.

Sprint 0 Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5

Release 1 Release 2
Customer Releases:
Provide functionality that can be formally accepted by the customer. Minimize UAT at the
end.
Deploy to separate environment

Success Factors:
Rapid deployment capability
Rapid script/automate test data loads
Usable functionality is contained within the release
Testing is integrated into each sprint (and not just unit testing)
Clearly defined Definition of Done aka Acceptance Criteria from the customer
Ability to incorporate new bugs, stories into the backlog for sprint planning

32
 Testing Throughout the Release
Functional & Day in the
Int. Testing Life Testing

Sprint 0 Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5

Release 1 Release 2
(UAT) (UAT )

Functional Integration Functional Functional

Testing Testing Testing Testing
Workflow
Features & Automation Features & Features &
functionality Linked features & functionality functionality
functionality

Legend:
Integration Regression
Technical Testing Testing Testing
Workflow Previous features
Customer Testing Automation & functions
Linked features &
functionality

33
Managing Stories & Defects Across the Release
Guiding Principle: Defects should be fixed as much as possible within a sprint

Defects Stories
A Defect is
If a story has a It will remain
logged when it Defects are part
defect it cannot open until the
cant be fixed of the backlog
be closed defect is fixed
within a sprint

34
 Tool Inventory
Tool Name Function

Basecamp Collaboration, Communication

Google Drive Internal Document Repository

Basecamp Client Document Repository

Plan.io Client Document Repository

GIT Code Management

Plan.io Backlog Management, Story Management, Test Management, Burndown, Velocity

Reporting, Activity Collaboration
Jira Backlog Management, Story Management, Test Management, Burndown, Velocity
Reporting, Activity Collaboration

Each project should select either Basecamp or Plan.io as the Client Document repository

35
 FAQ
Question
Will we continue to use a BRD?
Will we continue to use a SDD?
We are doing data migration, and need
to develop data mapping documents and
migration templates.
I am business analyst, I dont want to
write test cases, manage a test plan or
defects
Its hard to get-up early/stay-up late to
do the stand-ups or working sessions
Video conferencing is recommended for
key meetings, cant we just have a
conference call?
Answer
In an agile project, the BRD is not used. Instead the Backlog is used as an
inventory for all the stories and requirements. Requirements are still
captured, its just in a different format. This artifact can be provided to
AMP
In an agile project, the Solution Design Document can be used, but ONLY
as a way to consolidate the designs at the end of each sprint to share with
the customer or as a deliverable for AMP.
It is recommended that the mapping requirements be housed in the User
Stories. The migration template should be used as a tool that will be used
to load data, thus part of the process to develop working software, not as
an end product.
While Agile promotes that people do only the work they have an interest
in, the Business Analyst is the best person to understand the acceptance
criteria and to validate the functionality meets the acceptance criteria.
Collaboration and team work is vital to successful agile implementations.
We must all recognize that during the project, we need to coordinate most
during the hours where we are all available
Video conferences help build rapport and improve communication
because you can see peoples body language and facial expressions which
lead to greater understanding and enhanced communication.
36
AGILE CAPABILITY ROLLOUT

37
 Required Capabilities to Enable AGILE
There are 4 capabilities that can be developed to implement Agile within the organization.
The intent is to focus on 1, and then add-in 2 4 as we mature and grow

1. Story Management
Capturing and manual testing of requirements
2. Source Code Management
Alignment of code mgmt. to stories to reduce
interdependencies of people working on the
same code
3. Continuous Integration
Automated testing of code when its checked in
to reduce risk of breakage associated with code
check-ins/branching, etc.
4. Automated Testing
Automation of functional, regression, and
integration tests

38
 Training Plan
Training Content Mechanism Objective Participants Time

Introduction to Agile @ Tectonic* Video Call Establish common Tectonic 2 hours

understanding, common Employees &
terminology, reinforce concepts Contractors
learned in practitioner training
Agile Hands-On Workshops Video/In- Work-shops where participants All Delivery 4 hours
Person work on a mock project
Identify Scrum Masters
Working Session on project
Share Results
Agile for Execs Conf. Call Deeper look at Value Prop, Executives, Sales 1 hour
contrast between Waterfall, Team
Contract Set-Up
Capturing & Testing Requirements In-Person Mechanics of gathering All Delivery 4 6 hours
the Agile Way requirements
Scrum Master Online/In- Mechanics of being a Scrum BAs, Solution 1 week + Test
(recommend professional training Person Master Architects,
& certification) Project Managers
Functional coaching Video/In- On-going mentoring by Coach assigned Weekly
Person discipline to each role
Project Coaching Project Audits On-going project support Tectonic Sponsor Weekly

* Recommend that company get formal Agile Practitioner training before rollout
39
SAMPLE ARTIFACTS

40
Artifact Examples In Progress

Product Back Log

User Story
Code/Configuration Standards
Release Plan

41
Artifact Examples Product Backlog

42
Artifact Examples User Story

43