Scrum en
vie

our
process model

„Scrum
en vie“ expresses

•        we
life Scrum

•        Scrum
is living

•        we
blend Scrum with V-Model concepts

to
provide you the best possible ROI.

Key Benefits

Scrum en
vie – Scrum enriched with carefully chosen methods from the V-Model

•        is
agile, as it completely conforms with the agile manifest.

•        is
formal, but despite it is backed by comprehensive tooling, your Business Scrum
Team just uses a single, web based tool.

•        is
a do-it-right-the-first-time (DRIFT) approach. Doing the same over and over
again to get it right is not just annoying. It wastes your time and your
resources.

•        provides
you a ramp-up time of less than a single day. We provide you Scrum en vie
combined with a pre-configured development environment as a virtual machine. So
ramp-up is merely deploy and configure user access rights. Start.

•        makes
you own and control the deliveries. As your organization hosts the development
environment, your organization is in control.

Rationale

Being
quality minded and customer focused we do a lessons learned sessions. We
experienced limits of both

•        the
pure Scrum approach and

•        the
strict V-Model approach.

Our
“Scrum en vie” is a result of our lessons learned.

On Scrum

Scrum is

•        customer
focused

•        with
continuous delivery as fundamental idea.

On the
odd side in praxis pure Scrum projects lack

•        quality
orientation and

•        deliveries
other than the application itself (e.g. user manuals).

On the V-Model

The
V-Model is

•        quality
oriented and

•        documentation
oriented.

Scrum on vie

The
V-Model provides what pure Scrum lacks. Consequently, to provide you the best
possible ROI  we use V-Model concepts
within Scrum.

Our process – Scrum en
vie

                “Everything should be made as
simple as possible, but no simpler.”

                [Albert Einstein, https://en.wikiquote.org/wiki/Albert_Einstein]

Scrum en
vie follows that basic principle.

The
diagram above shows it all

•        the
5 roles involved, including

◦          the
artifacts a member of a role creates, is responsible for and

◦          if
a member of a specific role is required to have presentation skills

•        the
artifacts used, including

◦          the
information flow visualized by solid arrows and

◦          the
“specification” a specific test is based on visualized by dashed arrows.

Scrum en
vie strictly adheres to the separation of concerns principle. This is the
rationale of the role Integration Manager, a role not present in pure Scrum.
The  Integration Manager is responsible
to negotiate on interfaces to the environment, interfaces to the systems our
system will interact with. As a result the Integration Manager enables the
Product Owner to focus on business needs.

Furthermore
despite Scrum en vie being agile, Scrum en vie is a formal process. As a formal
process Scrum en vie offers a comprehensive tooling that makes using Scrum en
vie even easier. Our tooling approach is described in a later chapter. We first
focus on the process itself.

Scrum en
vie is Scrum as V. Scrum en vie is agile as pure Scrum, but with the formalism
of the V-Model. That makes Scrum en vie

•        easy
to understand and use

•        fast
to adopt.

 

Scrum
on vie Team Setup

The Scrum
process is performed by

•        the
business oriented Business Scrum Team and

•        the
technical oriented Development Scrum Team

working
together.

Some
tasks are done

•        solely
by the Business Scrum Team,

•        solely
by the Development Scrum Team or

•        collaborative
by the  Business Scrum Team and the  Development Scrum Team.

This very
aspect is visualized using different colors.

Business Scrum Team
tasks

User Stories

The
Project Owner (PO) is responsible for the user stories. The PO collaborates
with the Key Users and the Integration Manager to get the input and write the
user stories.

Acceptance

To commit
the Scrum sprint results produced by the Development Scrum Team the Product
Owner analyzes the Key User test results.

Collaborative tasks

Refinement

An user
story has to be

•        refined,

•        reviewed,

•        marked
as ready for development (RFD) and

•        committed.

The tasks
are performed collaborative by the Business Scrum Team and the Development Scrum
Team. To refine an user story the Development Scrum Team looks for open points
and ambiguous specifications. The Business Scrum Team answers the questions of
the Development Scrum Team to make the user story contain no open points or
ambiguities.

An user
story successfully reviewed is marked ready for development (RFD) and
prioritized. The Development Scrum Team chooses a set of user stories to
implement in the Scrum Sprint and commits to implement these. The Key Users in
return commit to test these stories. This negotiation is done in collaborative
Team spirit.

Test

The Scrum
sprint is reviewed and tested.  To enable
the Key Users to do this, the Development Scrum Team Lead presents the sprint
results and how to test these. The redundancy of updating manuals and
presenting the results is intentionally. The interactive character of the
presentation enables Key Users to ask, enables them to understand.

Development Scrum Team
tasks

Developer ticket

The
Development Scrum Team Lead collaborates with the developer team to divide each
user story commited on into self contained developer tasks specified in form of
developer tickets. Each developer ticket describes either

•        a
new component to be created or

•        an
existing component to be altered or

•        an
existing component to be either

◦          replaced
or

◦          removed.

Design &
Documentation

 Prior to starting implementation a design is
created specifying how the task will be performed. The design is documented in
a single,  self contained design document
or SysML/UML model. Consequently

•        a
new component design is documented if a new component is to be created or

•        the
design documentation is altered

◦          if
an existing component to be altered or

◦          an
existing component to be either

▪       replaced or

▪       removed.

This
approach ensures the high level description of what is implemented and how it
is implemented is always up to date. As a result new developers added to the
Development Scrum Team will be productive fast.

Implementation &
Documentation

Implementation
includes updating affected documents. These include as examples

•        user
manual and

•        administrator
manual.

Performing
this the same rules as applied to the design document applies. The continuous
update of documents not only enables the Key Users to comprehensive testing,
but also ensures the documents to be usable and complete.

Developer tests

Each
developer also implements developer tests to test the own code. Developer tests
are part of the delivery and a delivery must not include User Stories with
failed developer tests.

Review, test &
deliver

The work
of a developer is independently reviewed by the Team Lead. This review covers

•        design
documentation,

•        implementation
including the implementation of the developer tests and

•        the
document updates.

The
review report is part of the delivery.

An example – or a
journey of an user story

Imagine
we are creating a CRM and the project/product is called myCRM.

Me, the
author intentionally chose a standard application like a CRM – the author
highly advises you to get as commercial of the shelf product – as example to
emphasize it a purely hypothetical example. Furthermore an address book
functionality is a feature we will not re-invent.

Imagine
we had a user story ( = business ticket "myCRM-business-0047")

"I as an user of myCRM want an address
book functionality.

The address book functionality SHALL provide
…"

… our
Development Scrum Team did it well and as a result it was accepted by the
Product Owner.

Later on
the Product Owner specifies another user story ( = business ticket
"myCRM-busi-0101") is to be implemented

"I as an user of myCRM want a sort by
telephone regional codes functionality within the address book."

The
business ticket "myCRM-business-0101" is derived of the
Error-Change-Improvement ticket "myCRM-eci-0012"

"a sort by telephone regional codes
would be a nice to have feature."

Consequently
"myCRM-business-0101" is an improvement.

Nevertheless
the "myCRM-business-0101" is an improvement, it is a developer ticket
and as such gets divided into developer tickets.

Developer
ticket "myCRM-dev-0511" –> assigned to a front-end developer

"change the user interface to enable a
sort by telephone regional codes functionality within the address book."

Developer
ticket "myCRM-dev-0512" –> assigned to a back-end developer

"change the affected business logic to
enable a sort by telephone regional codes functionality within the address
book."

Developer
ticket "myCRM-dev-0513" –> assigned to a database developer

"create
test data to test the sort by telephone regional codes functionality within the
address book."

As you
might recognized all 3 developer tickets depend on each other. But having 3
developer tickets being derived of a single user story nothing else is to be
expected. Consequently the 3 developers collaborate to do the design.

Our
process model Scrum en vie regards a design (to get more detail on the
principle we generalize in Scrum en vie please refer to http://se.ethz.ch/~meyer/publications/computer/contract.pdf) as a contract between
developers. Once the developers negotiated on a contract, despite the fact
dependencies exist they can work independently. As a result negotiating on a
contract first boosts efficiency significally. Another example how we provide
you the best possible ROI.

Given
that the assignee of "myCRM-dev-0511" will

•      update the design documentation
of the context menu

•      implement the update according to
the design

•      update
the user manual to document how to use the sort by telephone regional codes
functionality within the address book.

the
assignee of "myCRM-dev-0512" will

•      update the design documentation
of the addressBook.SortOptionsContextMenuHandler menu

•      create a new design for the
addressBook.SortByRegionalCode feature

•      implement
everything to be done according to the design(s)

the
assignee of "myCRM-dev-0513" will

•      evaluate if the data model has to
be altered

•      if yes, he will update the data
model documentation in the design document

•      if not, he will note as ticket
comment "data model not affected"

•      implement it according to the
design(s)

•      if data model is affected,
additionally a data base migration script is created

•      will create the test data

•      if
data model is affected, additionally the administrator manual will be updated,
to show the administrator how to run the migration script.

As soon
as a developer tickets is done, the Developer Scrum Team lead will review the
work.

All work
done within a Scrum Development Sprint is tested before it gets delivered. We
only deliver successfully tested work.

Thats the
whole journey of an user story (= Business Scrum Ticket) within a Development
Scrum Sprint.

Lessons Learned &
Refactoring

Every
fourth Scrum Sprint is performed as

•        dedicated
Lessons Learned Business Scrum Sprint

•        dedicated
Lessons Learned & Refactoring Development Scrum Sprint.

This is
our approach to avoid in praxis often observed negative Acceleration. Yes, in
many real world projects the effort invested to get a Story Point done grows
and grows.

The
evolutionary nature of the Scrum process sometimes requires refactoring to
complex to be done within a standard Scrum Sprint.

Our
experience proofed the optimal rate to perform these refactoring is every
fourth Scrum Sprint. Given 3 weeks Scrum Sprints – our advise – this leads to a
Lessons Learned Sprint every 3 month. That makes the Sprint sequence look like:

Business Sprint 1

Business Sprint 2

Business Sprint 3

Lessons Learned Sprint 1

Business Sprint 4

Developer Sprint 1

Developer Sprint 4

LL & Refactoring Sprint 1

Developer Sprint 3

Developer Sprint 2

Business Sprint 5

Issue Management

An issue
is either

•        an
error,

•        a
change request or

•        an
improvement request.

All issue
types are handled equally. As a business ticket an issue ticket being handled
is divided into developer tickets.

The
priorities by issue type each starting at the highest priority are as follows

•        error
(blocker, critical, major, minor)

•        change
(blocker, critical, major, minor)

•        improvement
(prioritized, standard)

The issue
types “error” and “change” share the same priorities. This is due to the fact a
required “change”, that if not done blocks further progress is as urgent as a
“blocker error”. Furthermore these priorities are shared with those of business
tickets.

These are
additional examples of our philosophy to handle equal items equally to make the
process as simple as feasible and provide you with the best possible ROI.

Tooling

Our
tooling we provide you as virtual machine consists of

•        OTRS

•        Jenkins

•        GIT

•        SonarQube

As you
might noticed we use a completely FOSS (Free Open Source Software) based
tooling. As a result

•        no
license handling efforts occur and

•        no
license fees have to be paid.

Further
the tools of our tooling are common used tools, consequently

•        learning
efforts are very likely to be re-usable.

OTRS

The
Business Scrum Team solely uses OTRS. OTRS is used to handle

•        User
Stories,

•        issues
and

•        developer
tasks.

We use
the Kanban Board functionality of OTRS to manage and visualize the state of

•        User
Stories

•        issues
and

•        developer
tasks.

As
example we define the following states for a user story (grouped by context)

•        create
User Story

◦          new

◦          ready
for refinement

•        refine
user story

◦          in
refinement

◦          ready
for development

◦          committed

•        final
acceptance by Product Owner

◦          implementation
accepted

◦          implementation
rejected

•        maintain
User Story

◦          updated

◦          obsoleted

 As you might noticed an User Story never
deleted, it gets obsoleted instead. We consider an User Story is a requirement.
And we follow the best practice to never delete a requirement. As a result also
the rationale why it got obsoleted is available.

We also
feature an “updated” state. Simple because we experienced the alternative
approach, to obsolete an User Story and create a new User Story is far more difficult
to handle.

Our
approach is result of our common experience and gives you the best possible
ROI.

Tools solely used by
the Development Scrum Team

The other
tools are solely used by the Development Scrum Team and thus only briefly
characterized in this white paper.

Jenkins

Jenkins
is a build server. A server that reacts on committed source code changes.
On  committed source code changes Jenkins

•        builds
a new deployment,

•        performs
the automated tests on the new deployment and

•        performs
a static source code analyzes utilizing SonarQube.

As result
SonarQube ensures

•        interference
of committed source code changes of different developers is detected,

•        the
test are performed,

•        the
source code quality is monitored.

GIT

GIT is a
source code revision management tool specially designed for agile software
development.

GIT
features

•        individual
changes can be integrated separately,

•        staging
(we use developer commit, reviewed, successfully tested, delivered as stages)
and

•        implicit
integry checking (based on hashes).

As a result
GIT optimally supports our Scrum en vie approach.

SonarQube

As
mentioned before SonarQube performs static source code analyzes. SonarQube
features a comprehensive rule set not only covering style aspects but also
features rules based on possible security leaks.

As a
result SonarQube ensures

•        the
source code is not only readable for the author itself and

•        free
of known security leaks.

In this case
we participate of the experience of a huge community.

Stay tuned

We are
working on our next generation tooling. The will provide you with the guidance
of a user friendly, automated BPMN process.

Your added value

Our
streamlined, automated process ensures

•        reduced
issues due to oversight,

•        accelerated
progress and

•        even
further improved.

Our next
generation tooling is another example of our philosophy to provide you the best
possible ROI.