Agility via Software Engineering Practices - Agile Tour Montreal 2015

Agility via Software
Engineering Practices
Agile Tour Montréal - November 2015
Steve Mercier

Who am I?
I participated in multiple software development projects:
• from very small (<10 person) to large (~400 persons)
• from a long time ago (>20 years) up to now
• from different angles/roles: Developer, Architect, PM, DevOps/
BuildMaster, Software Release Manager
• I have seen software methods/processes come and go: Waterfall,
RUP, OpenUP, XP, Scrum, Scaled Agile, etc.
But the essential remains:
I believe that to produce good software, it takes good people +
resources AND discipline/professionalism/focus!

Are You Agile?
Agile is not easy… and is not only about ceremonies + tools!

A few questions
• Raise your hand, if you participate in:
• Daily stand-up meetings
• Sprint planning meetings
• Sprint reviews and demos
• Sprint retrospectives and lessons learned
• Regular backlog grooming sessions

Now THE question
• By raising your hand
• Who believes that he/she works in an Agile
environment?

What would be a good
measure of Agility
anyway?
We will come back to this at the end

What is your (real) release
frequency?
• At what frequency are you delivering software updates that add value to
your clients?
• Once a year?
• Once a quarter?
• Once a month?
• Once a sprint?
• Once a day?
Without breaking any previously delivered
business value that you want to retain…?

Agile Simpliﬁed Overview
How can we ensure this loop works smoothly and fast?
Client
PO
Team
Delivery

What are the typical
Agile issues?
Elements preventing Agility that could be ﬁxed
by a speciﬁc software development practice?

Agile Issue #1:
Communication Issues

Dozens of ways to communicate
With more and more possibilities, growing!

Communication Issue Example
“But, I published my design document on SharePoint!”

Communication Issue Example
“But, I sent you an email!”

Communication Issue Proposition
Only one truly Agile communication technique: Dialog!

What technique can improve dialog?
You could consider BDD to close the communication
gap between business people and technical people

Agile Issue #2:
Manual Interventions

Everything not automated
reduces your Agility

Manual triggers can take a long time
Manual = Time++;

As your manager might say
Time == Money();

What techniques can reduce manual steps?
You could consider using DevOps:
CI server, CD server, Infrastructure as Code to automate
as mush as possible your release process
DevOps
Client
PO
Team
Delivery

Continuous Integration

Continuous Delivery/Deployment

Infrastructure As Code

Agile Issue #3:
Customers not really
validating increments

Not fully involved customer…

Customer not validating increments
Proposition
You should again consider using BDD to involve your
customers as much as possible; this would ensure a
relationship between the needs and the demo
• Various things could contribute to this issue (cumulative!):
• Specifications created without customer’s involvement
• Specifications not properly handed over to teams for execution
• Specifications not validated automatically or systematically every sprint
• Customers not involved in sprint demos or not giving feedback during demos
• Not delivering produced software regularly to customers for evaluation

Agile Issue #4:
PO wants it all
(aka priority
management issue)

Be careful about
scope creep and
absence of
prioritization!

PO wanting it all
I do not really have a speciﬁc technique
for this one…
I suggest selecting the right PO in the ﬁrst
place
AND
then to use proper backlog grooming
techniques
(Buy him the book 50 quick ideas to
improve your user stories by Gojko Adzic)

Agile Issue #5:
Demos done from
unreleased software
(aka Works at my desk)

Demos from unreleased software /
Difﬁculty to release in production
Involve Ops people in sprints
Releasing in prod should be doable by
anyone, anytime, using a single click
(rollback is obviously a feature you will want!)

Agile practices to
overcome the presented
Agile issues
Intro to a few + associated
tools

BDD—Behaviour
Driven Development

BDD—Behaviour Driven Development
Bridges the gap between customers/business people
and teams
1-An
technology
agnostic
feature ﬁle
developed
with your
users
This is
somehow an
executable
speciﬁcation

2-A technology
speciﬁc code
generator
(SpecFlow/C#,
JBehave/Java,
Behave/Python,
etc.)

3-Complete cycle
with inner TDD

Continuous Builds, Continuous Testing, Continuous
Inspections

Not only build on commit by the continuous integration
server, but also:
• Systematic unit tests (e.g. NUnit, JUnit)
• Aim at 70-90% code coverage
• Measure your coverage (e.g. dotCover, NCover)
• Code inspections (static analysis, linter, code complexity)

cont’d:
• Publish built artifacts on artifacts server (e.g. Artifactory)
• Deploy into staging environments
• Run integration/functional testing
• Run performance testing
• Publish reports of selected metrics for the above
elements (e.g. SonarQube)

CD—Continuous
Delivery/Deployment

Always have a shippable version available for your customers
Ex: GO CD (from Thoughtworks - now Open Source)
You can integrate your CI servers (Jenkins) with a CD server

A good practice to deploy gradually using cascaded
environments:
• (Development)
• Test
• Less resources, used mostly to validate business logic
• Staging/Pre-Production
• More representative of the production environment. Can be
used for load/performance testing. Typically uses a data set
that is a copy of the Production data set.
• Production

Infrastructure as Code
Your code is under CM, but your
infrastructure is typically not! It also needs
to be versioned, tracked and automated!

There are so many tools available. But essentially,
keep ALL under source control, including what it takes
to reproduce your production environment from ZERO
• How to restart a hardware environment/virtual machines
• How to install the platform on the machines
• How to install the applications on the platforms
• How to conﬁgure the whole stack
• The databases schemas and content
• Everything!

If you are not convinced, think about your disaster
recovery plan (you have one, right?)
What if your server room is destroyed by water/
ﬁre? (or the one from your cheap cloud provider…)
With IaC at least, the software part is covered in
case of disaster

DevOps
• A Good app without an infrastructure to run it is useless…
• A superb, scalable infrastructure without an app adding
business value to a customer is also useless…
• You need both!
• DevOps should not be a separate team! It serves to
bridge the gap between development and operations
teams.
• And if you are not convinced that DevOps cannot
typically be a single person’s responsibility…

Agile Values vs.
Agile Practices

Agility is more than Agile values and
ceremonies
It is acting as per the Agile values and
producing software with related best practices

But where to start?
Every Agile cycle, try to improve on those issues, trying
to automate everything you can, while having the
conversation with your key stakeholders

What would be a good
measure of Agility
anyway?

Suggestion #1:
The frequency at which you are
delivering software updates
that add business value to your clients
without breaking any previously
delivered business value that you
want to retain
(aka The capability to release)

Suggestion #2:
The time it takes you to deliver
the smallest change/ﬁx to your
software in production
(aka The time to release)

Engineering requirements to attain
Agility:
Good people with good tools,
applying proven software
development best practices
consistently with discipline
using continuous improvement
principles

Titre sur mesure
POINTS FORTS 1
T h a n k&yo u !
Questions
pyxis&tech.com

Agility via Software Engineering Practices - Agile Tour Montreal 2015

Recommended

More Related Content

What's hot (20)

Similar to Agility via Software Engineering Practices - Agile Tour Montreal 2015 (20)

Recently uploaded (20)

Agility via Software Engineering Practices - Agile Tour Montreal 2015