End to End Agility

Nabeel Ansar
About Me

Just an other Agile Guy 

By the end of this session you will have
understating of :

• Branching and Code • Pre - Planning

Merge • Inception
• How story points should • Construction iterations
be used ?
• Release iterations
• The Scope of life Cycle
• DevOps
Branching and Code Merge
GitFlow
The Gitflow Workflow defines a strict branching model designed around the project release. While somewhat
more complicated than the Feature Branch Workflow, this provides a robust framework for managing larger
projects.

5
Main Branches
• The Gitflow Workflow still uses a central repository as
the communication hub for all developers.
• The central repo holds two main branches with an
infinite lifetime:
• Master (consider origin/master to be the main
branch where the source code of HEAD always
reflects a production-ready state.)
• Develop (consider origin/develop to be the main
branch where the source code of HEAD always
reflects a state with the latest delivered
development changes for the next release. Some
would call this the “integration branch”. This is
where any automatic nightly builds are built from.)

6
 Supporting Branches

• Next to the main branches master and develop, other branches are :

 Feature branches
 Release branches
 Hotfix branches

• Each of these branches have a specific purpose and are bound to

strict rules as to which branches may be their originating branch and
which branches must be their merge targets
7
Feature Branch
• May branch off from:
• Develop
• Must merge back into:
• Develop
• Branch naming convention:
• anything except master, develop, release-*, or hotfix-*

8
Release Branches
• May branch off from:
• Develop
• Must merge back into:
• develop and master
• Branch naming convention:
• release-*

9
Hotfix Branch
• May branch off from:
• Master
• Must merge back into:
• develop and master
• Branch naming convention:
• hotfix-*

10
Please take Care

• when a release branch currently exists, the hotfix

changes need to be merged into that release
branch, instead of develop

11
Example

12
Step 1 : Create a develop branch
• First step is to complement the default master with
a develop branch. A simple way to do this is for one
developer to create an empty develop branch
locally and push it to the server
git branch develop git push -u origin develop

Develop branch will contain the complete history of

the project, whereas master will contain an abridged
version, A stable deployable version

13
Step 2 : Feature branch
• Asif and Raza working on separate features.
• They both need to create separate branches for their
respective features. Instead of basing it on master,
they should both base their feature branches
on develop

• Both of them add commits to the feature branch in

the usual fashion

14
 Step 3 : Release Branch

• He uses a new branch to encapsulate the release preparations

• He will create a release branch from the develop branch,
• He will update the version,
• He will merge it all to the master branch,
• He will create a tag,
• He will merge back to the develop branch,
• And finally delete the release branch.
• Code pushed to the master branch should be considered ready for
release.

15
Hotfix in a release
• To fix the bug, Asif creates a maintenance branch off of master
• He Fixes the issue with as many commits as necessary,
• He will then merges it directly back into master.
• He will merge this with Develop as Then,
• He will delete the hotfix branch

16
17
Story Points

18
Measures of size

Sequential Agile

•Lines of code •Story points

•Function points •Ideal days
Story points
As a user, I want to be
• The “bigness” of a task able to have some but
• Influenced by not all items in my cart
• How hard it is
gift wrapped.
• How much of it there is
• Relative values are what is important:
• A login screen is a 2.
• A search feature is an 8.
• Points are unit-less
Zoo points
What value in “zoo
points” would you put on
these zoo animals? Lion
Kangaroo
Rhinocerus
Bear
Giraffe
Gorilla
Hippopotamus
Tiger
Comparing the approaches
• Story points help drive cross-functional behavior
• Story point estimates do not decay
• Story points are a pure measure of size
• Estimating in story points is typically faster
• My ideal days cannot be added to your ideal days
• Ideal days are easier to explain outside the team
• Ideal days are easier to estimate at first
• Ideal days can force companies to confront time wasting activities
Estimate by analogy
• Comparing a user story to others
• “This story is like that story, so its estimate is what that story’s estimate
was.”
• Don’t use a single gold standard
• Triangulate instead
• Compare the story being estimated to multiple other stories
Use the right units
• Can you distinguish a 1-point story from a 2?
• How about a 17 from an 18?
Use 0 and ½
if you like
• Use a set of numbers that make sense; I like:
• 1, 2, 3, 5, 8, 13
• Stay mostly in a 1-10 range
• Nature agrees:
• Musical tones and volume are distinguishable on a logarithmic scale
Planning poker
• An iterative approach to estimating
• Steps
• Each estimator is given a deck of cards, each card has a valid estimate written
on it
• Customer/Product owner reads a story and it’s discussed briefly
• Each estimator selects a card that’s his or her estimate
• Cards are turned over so all can see them
• Discuss differences (especially outliers)
• Re-estimate until estimates converge
Planning poker—an example

Estimator Round 1 Round 2

Erik 3 5

Martine 8 5

Inga 2 5

Tor 5 8
Estimate these
Product backlog item Estimat
e
Read a high-level, 10-page overview of agile software
development in a celebrity magazine.
Read a densely written 5-page research paper about
agile software development in an academic journal.
Write the product backlog for a simple eCommerce site
that sells only clocks.
Recruit, interview, and hire a new member for your team.
Create a 60-minute presentation about agile estimating
and planning for your coworkers.
Wash and wax your boss’ Porsche.
Read a 150-page book on agile software development.
Write an 8-page description of agile development for your
boss.
www.planningpoker.com
Release planning
Release Planning Meeting

Release Plan
Sprint 1 Sprint 2 Sprint 3 Sprints 4−7
An example with velocity = 14
Story A Story F
Sprint 1 Sprint 3−4
5 3
Story G
Story A Story B Story H Story J
Story C 3
5 8 13 8
Story E 3 Story I
Story D
1 5
5 Story H
13
Sprint 1
Story C Story F Story I
3 5
3
Story G
Story D Story E Story J
3
5 1 8
Projections based on velocity
40
Mean (Best 3) = 37
Mean (Last 8) = 33
30 Mean (Worst 3) = 28

20

10

0
1 2 3 4 5 6 7 8 9
STORY POINTS

Story points are a unit of measure for

expressing the overall size of a user story,
feature or other piece of work. ” Story points
tell us how big a story is, relative to others,
either in terms of size or complexity: Mike
Cohn

32
Extrapolate from velocity
Assume 5
sprints left

At our slowest velocity, we’ll end here (5 × 28)

At our average velocity, we’ll end here (5 × 33)

At our average velocity, we’ll end here (5 × 37)

Fixed-date planning
How much can I get by <date>?
• Determine how many sprints you have
• Estimate velocity as a range
• Multiply low velocity × number of sprints
• Count off that many points; These are “Will Have” items
• Multiply high velocity × number of sprints
• Count off that many more points; these are “might haves”
Fixed-date planning example
Desired
30 June
release date
Will have
Today’s date 1 January
6 × 15
Number of
6 (monthly) Might have
sprints

Low velocity 15 6 × 20

Won’t have
High velocity 20
Three issues
Estimating in a common unit

Sprint planning

Dependencies
Establish a common baseline
• All teams should agree on story points or ideal days
• Establish a common baseline
• Select a dozen or so user stories that were done recently or are on the
product backlog
• Estimate them en masse with Planning Poker
Be careful with cross-team comparisons

• When did this firm

start comparing
velocity?
• When did the yellow
team figure out they
were being
compared?
Two approaches to sprint planning
Stagger by a day

• Sprints end by ± a day

• Helps a key resource (e.g., a product owner
or architect) fully participate in many
planning meetings
The Big Room
• All sprints end on same day
• All planning is on same day and in one room
• Key resources shift between teams on demand
Dependencies
• Critical dependencies between teams
• Must be done in this order and likely to influence overall ship date
• Fewer of these than you may think
• Emergent dependencies
• “OK, we’re going to start on such-and-such soon. As you know we
need this-and-that first.”
Buffer critical dependencies
Sprint 1 Sprint 2 Sprint 3

20 points 10 points 20 points

Sprint 1 Sprint 2 Sprint 3

17 points 17 points 17 points

Rolling lookahead planning
Task Hours
Code the … 8

Sprint 1
Test the … 16
Integrate with … 5
Code the … 8
Design the … 4

Sprint 2 Sprint 3
After Sprint 1
Sprint 1 Sprint 2 Sprint 3 Sprints 4−7
Code… 8
Test… 4 • While planning
Design 4 Sprint 2, a team rolls
Code… 5
Sprint 4 into view.
• They discover a
After Sprint 2 dependency on
another team.
Sprint 2 Sprint 3 Sprint 4 Sprints 5−7 • The other team work
Code… 3 on that item during
Test… 7 Sprint 3.
Test… 6
Code… 8
The Scope of Life Cycles
• Solution development is complicated
• There's more to IT than development
Scrum
Mapping with what you are currently doing
• Sprint = Iteration
• Backlog = Stack
• Daily Scrum Meeting = Daily Meeting
A detailed agile SDLC
The Agile continuous delivery life cycle.
The Agile SDLC (HL)
Pre-Project Planning
• Define the business opportunity
• Identify a viable for the project.
• Assess the feasibility
Project Initiation (the "Warm Up" iteration)
• Garnering initial support and funding for the project
• Actively working with stakeholders (Detail model on next slide)
• Starting to build the team
• Modeling an initial architecture for the system
• Setting up the environment
• Estimating the project
The Agile Model Driven Development (AMDD)
life cycle.
How long did it take your project team to get
started? (Average: 4.6 weeks)
<1 Week 6%

1 Week 7%

2 Weeks 13%

3 Weeks 13%

4 Weeks 14%

5-6 Weeks 11%

7-8 Weeks 3%

> 8 Weeks 18%

Don't Know 14%

Copyright 2013 Scott W. Ambler www.ambysoft.com/surveys/

Construction Iterations
What we Achieved ...
• Collaborating closely with both our stakeholders and with other
developers
• Implementing functionality in priority order
• Analyzing and designing (TDD in next slide )
• Ensuring quality
• Regularly delivering working solutions
• Testing, testing, and yes, testing
TDD
Testing during construction iterations
Development sandboxes
Regular software releases
• Start planning early
• Recognize that deployment is harder than it looks
The Agile
Deployment
workflow
Role of Dev and Ops

• Dev • Ops
• Create Change • Create Stability
• Add or modify features • Create or enhance services
But we have some problems…
• Disconnect between Groups
• Results in conflicts and inefficiencies
• Dev Don’t Deploy consistent software
• Ops are motivated to resist change
• Development Process is Agile
• Operations Process is Static
“And we are missing the point of it all”
We Need Change !
DevOps can rescue
What is DevOps

DevOps is the practice of operations and development engineers

participating together in the entire service lifecycle, from design
through the development process to production support.
 Some more Definitions
Wikipedia (renewed):
DevOps is a culture, movement or practice that emphasizes the collaboration and
communication of both software developers and other IT-professionals while automating
the process of software delivery and infrastructure changes.[1][2] It aims at establishing a
culture and environment where building, testing, and releasing software, can happen
rapidly, frequently, and more reliably.[3][4][5]

DevOps is “a cross-disciplinary community of practice dedicated

to the study of building, evolving and operating rapidly-changing
resilient systems at scale.” – Jez Humble

…with the ultimate goal to proactively support the organization in

becoming digital, client-focused and data-driven enterprises. –
Anko Tijman
DevOps is automation
Automation practices (just few …)
• A/B testing
• E2e testing
• Automated dashboards
• Blue-green deployment
• Dark launching
• Deployment pipeline
• Develop for production
• Feature toggles
• Feedback from production
DevOps is collaboration
• Cross functional teams
• Dev and Ops and all of their roles 
• Analyst, Developer, Tester, Application mgr, Sys Admin, Infra, etc.
• Projects AND Changes AND Incidents in one team
• BizDevOps?!
• Team goals
• Team metrics
• Learning as a team
• Continous improvement (people, process, technology)
• Joint tooling
• Process
• Deployments
• Monitoring
Learning from production
Feedback from production
Business value: Users, conversion, etc.
Technical excellence: CPU, logging, etc.
Feature feedback
Product Backlog  continuous improvement
Continuous improvement
System
Process
Team
Stakeholders
Impact on Design and Architecture
Emerging design
Emerging architecture
Built to last  built to change
Benefits of DevOps
Continuous software delivery
Less complex problems to
fix
Faster resolutions of
problems
Stable environments
More time to add value
What is Continuous Integration?
a software development process where members of a team integrate
their work frequently, usually each person integrates at least daily –
leading to multiple integrations per day. Each integration is verified by
an automated build (including tests) to detect integration errors as
quickly as possible.
Feature of CI

A connection to Some sort of

a version control feedback
repository mechanism
A build script (such as e-mail) A process for
integrating the
source code
changes (manual
or CI server)
CI Practices
• Commit code frequently
• Don’t commit broken code
• Fix broken builds immediately
• Write automated developer tests
• All tests and inspections must pass
• Run private builds
• Avoid getting broken code
Reduce Risk using CI

Lack of deployable Late discovery Lack of project Low-quality

software of defects visibility software

1 2 3 4
Build software at every change
• Automate builds
• Perform single command builds
• Fail builds fast
• Build for any environment
• Run fast builds
• Stage builds
Continuous Testing
• Automate Unit tests, Component tests, System tests and Functional
tests.
• Categorize developer tests
• Run faster tests first
• Write tests for defects
• Make component tests repeatable
• Limit test cases to one assert
Continuous Inspection
• Reduce code complexity
• Perform design reviews continuously
• Maintain organizational standards with code audits
• Reduce duplicate code
• Assess code coverage
Continuous Feedback
• E-mail
• SMS
• Sound
• RSS
What is Continuous Delivery?
Continuous Delivery is a software development discipline where you
build software in such a way that the software can be released to
production at any time.
Martin Fowler
 According to Martin Fowler, CD is When

Deployable Prioritized

The software is deployable Software deployment is prioritized

throughout its lifecycle over working on new features

Automated feedback Push Button Deployments

Anyone can get fast automated feedback on Push-button deployments of any
the production readiness of their systems version of the software on any environment
any time somebody makes a change to them on demand
So how does CD matter ?
To Developers
• They can check-in code and see it deployed immediately so that they can
improvise or change on certain aspects as and when they want.
• Feedback is very important in keeping code neat and less complex.
• Ability to provision themselves with production-like stacks and push-
button deployment so they can run automated tests
Continuous Delivery Pipeline
Some tools