Agile SAP ACTIVATE

><PIERRE.NEIS@AGILESQR.COM
next
agile² GmbH
AGILE ACTIVATE
CONTEXT
1
Cookbook Slide-deck

><agile² GmbH PIERRE.NEIS@AGILESQR.COM ><agile² GmbH PIERRE.NEIS@AGILESQR.COM
Author
Pierre E. NEIS
Certified Agile Coach & Trainer
CEST CBAC
He worked with Mike Beedle (Agile Manifesto,
Scrum) on the Enterprise Scrum Concept.
Pierre co-author and contributor on many books
related to Agile and he is co-founder of Play14.

><
next
agile² GmbH PIERRE.NEIS@AGILESQR.COM
01
02
03the challenge of
agile
model
details
04 example
table of content
4

><agile² GmbH PIERRE.NEIS@AGILESQR.COM 5

AGILE IS NOT
ABOUT THE WHAT,
IT IS ABOUT THE
HOW.
next 6

><
next
01agile ACTIVATE
ACTIVATE is a linear approach distilling the idea that an SAP
project run like a factory with strong upfront planning.
Agile is, on the opposite, a non-linear approach driving fast
delivery of working software to ensure rapid feedback from the
customer.
This document will explain how to run ACTIVATE under proper
agile.
the
challenge
of agile
7

><agile² GmbH PIERRE.NEIS@AGILESQR.COM
ACTIVATE
an Agile analyse through the lens of
the manifesto
8
Individuals and interactions
Working software
Customer collaboration
Responding to change
0 25 50 75 100
processes and
tools
comprehensive
documentation
contract
following a
plan
If you are considering ACTIVATE as a
methodology, agile might be a tool
enabling the methodology.That is all
wrong.
From a genuine agile approach, ACTIVATE
makes it all wrong:
• it is all about the ACTIVATE method
and SolMan, Focus Build tools and a
small interaction to identify who’s
who’s.
• working software comes only late in
the method at least at Realise phase.
• Plan is key and change is considered
as a deviation of the standard
“quality”.
More of Less of
status

the organizational model is
a program, not a project
9
DISCOVER PREPARE EXPLORE REALIZE DEPLOY RUN
project project project project project transactions
program

issues and risks 1/3
10
program
LATE CUSTOMER ENGAGEMENT

11
program
HAND-OVERS TO DIFFERENT STAKEHOLDERS
“Adding manpower to a late software project makes it later,”
states that when a person is added to a project team, and
the project is already late, the project time is longer,
rather than shorter.” BROOK´S LAW
Hand-overs are increasing the risk of misinterpretation and
reduces dramatically the delivery performance (velocity).

12
program
WHERE THE BUDGET FLOWS?
2 years, time and fees 6 months SOW 1 month SOW 1 month SOW
Agile fosters stable budget: ideally the same team from the
beginning until the end. 
Experts have to spread knowledge in the team. This allows to
control high costs of expertise and team engagement.

from a customer's
perspective
13
program
VALUE IS CREATED HERE
STRESS IS CREATED HERE
The risk in the first phases is that the customer don’t see
any value created, only the validation of the contract.

><
next
agile² GmbH PIERRE.NEIS@AGILESQR.COM 14
OVERVIEW

DISCOVER
PREPARE
EXPLORE
REALIZE
DEPLOY
RUN
project
project
project
project
project
transactions
DELAY STARTS
DELAY STARTS
DELAY STARTS
DELAY STARTS
OVERVIEW
ORGANIZATIONAL
WATERFALL

Team relay race
16
Team A
Team B
Team C
Team D
Team E
organizational
waterfall
Team A : identifies the needs and gaps
Team B : mostly business analysts and business process analysts
define the working items and the end-to-end processes
Team C : is developing the solution based on Team B´s work
Team D : is testing Team C´s work
Team E: is making the solution into production.
sign off
sign off
sign off
sign off
sign off
Team A
Team B
Team C
Team D
Team E
Team out
Team out
Team out
Team out
To reduce costs, consultants are in Team A, Experts in Team B and off-shore
mostly in the other teams.
Unfortunately, to ensure the ROI of experts, they won’t be available once
“sign off” and are moving into another project.
In theory, knowledge transfer is documented in Solution Manager but in
reality, the other teams do not have the maturity to understand everything
easily.
Because, the developers are “low costs”, the financial impact is low at the
beginning but all projects won’t reach the deadlines.
Because of the puzzled organization, the project has to invest massively in
coordination with project managers, PMOs and other QAs.
OVERVIEW

summary
what not to do!
17
contract
blue print validates contract. expectations: no
change. reality: loosing customer’s engagement
in the hurry development
poortesting
expecteddeliverydate
win/win We win / they loose we win / they loose loose/
loose
loose/
loose
Tada!
VALUE/EFFICIENCY CURVE
CONSIDERING A PROJECT LIKE A
PROCESS
Team A
Team B
Team C
Team D
Team E
teams “relay race”
OVERVIEW

organizational
waterfall consequences
18
-100
-75
-50
-25
0
25
50
75
100
0
25
50
75
100
Discover Prepare Explore Realize Deploy Run
OVER-BUDGET
STARTS
PROGRAM BUDGET
OVERVIEW
THE PUSH BACK METHOD
From the early beginning, both seller and buyer know that
the model doesn’t work. Because organization and
coordination aren’t functional, most of the stakeholders
do not care.
To allow starting a very expansive program and still
giving the feeling of cost efficiency, each phase is
independent.
It means that you need a sign off at the end of a phase
and a new proposal for the next stage.
A consequence of that behaviour is deferring the lousy
news the later possible. Usually, the first bad news
starts at the “Realize” phase where curiously value is
created.

THE MODEL
DOESN’T WORK
next 19

“agile “ACTIVATE
20
Individuals and interactions
Working software
Customer collaboration
Responding to change
0 25 50 75 100
processes
and tools
comprehensive
documentation
contract
negotiation
following a
plan
Agile is the way how to work and how we are
interacting with each other during the project.
We can use some agile methods like Scrum or Kanban,
to ensure this behaviour.
ACTIVATE has to be considered the high-level program
roll-out vision highlighting the most critical
beacons supporting better customer collaboration and
not contract negotiation.
On the other hand, Focus Build is also not a
methodology. It is a set of bricks supporting fast
delivery of standards functional or processes fits.
From an agile perspective, FB relates to Agile
Architecture as modular architecture.
More of Less of
objective

It is a program, not a
project
21
program
From an agile perspective, we can consider the phases like
an individual project. “Done” for DISCOVER is then “Ready”
for PREPARE, etc…
I highly recommend Scrum to ensure a clear scaffolding and
to reduce timeframe.
Agile is on the “How”, not on the “What”.

solutions
22
program
CUSTOMER ENGAGED SINCE DAY ONE
Scrum will help you to ensure customer engagement since Day
one.

solutions
23
program
SAME TEAMS ALL ALONG THE PROGRAM WITH SOME TEMPORALLY FLOATERS
EARLY ON-BOARDING OF RUN
IN PAIR-TO-PAIR

phasing solution
24
program
WHERE THE BUDGET FLOWS?
two months max three times more than “discover” and “prepare”. Parallelisation of “Explore”
0 25 50 75 100
Explore
Realize
Deploy
Run
Explore + Realize + Deploy + Run

><
next
OVERVIEW

summary
26
custom development based on customer’s engagement & continuously
inspect&adapt cycles
contract
rapid delivery of
standard & continuous
delivery (test
automation) as
blueprint!
JUSTINTIME,JUSTENOUGH
win/win customer is engaged: each sprint delivers
, a testable increment. customer delivers
constructive feedback each cycle
win/win
yeah!
VALUE/EFFICIENCY CURVE
win/win customer delight
CONTEXT RELATED
ACTIVATE
Team A
what to do
OVERVIEW

><
next
02Agile ACTIVATE Model
27

Activate, Focus Build
the agile way
28
Program Roadmap. Phases are milestones or points of attention
Focused Build is not a
methodology, it is an
efficient product development
tool.
It helps to identify the
standard components to start
early REALIZE.

Activate, Focus Build
the agile way
29
DISCOVER
PREPARE
explore realize deploy run
0 25 50 75 100
Explore
Realize
Deploy
Run
Explore + Realize + Deploy + Run
PARALLELISATION

><
next
End-to-end process • design and refine the process aligned with Release Roadmap
Collaboration
• enhance Product Owner’s vision with Process Owners/Users
• define Personae and create specific User stories and Themes
• work as a team member of a cross-functional team
Knowledge • Interact with the Business Process community of practice (aka
Chapter) to share, learn and improve standards
Build • set up the standard process as a hypothesis
Measure •set up a Definition-of-Done (DoD) for the E2E process
•collect customer’s/user’s improvement (Sprint Review) and
update
•run User Testing workshops to test the hypothesis
•Improve the measures
Visible metrics • Set metrics and capture mechanisms for both Customer and
Delivery Teams
• Display metrics so that all the teams share the same wall
• Make it highly visible in the Communication Tool (Jira,
Confluence)
Communication &
collaboration
• Use intra-team, web-based collaboration (Jira, Confluence)
Scrum Team Rooms • Secure Scrum Team Rooms for each team; one room per Work
stream
• Group Work Stream Rooms in a common location/building
• Use significant wall-space for creative boards and facilitate
display of visible metrics
• Install conference phones, video conference, whiteboards
Customer Lab • Recruit and schedule customers for regular testing
• Use trained facilitators to conduct interviews (Training or
Scrum Masters)
• Set up a customer lab with recording equipment
A. PRACTICES
B. PROCESSES
C. TOOLS
D. INFRASTRUCTURE

composition of a scrum
team
31
Build the
right thing
Build the
thing right
Build it fast
process owner
developer
tester
delivery manager
Product
Owner
scrum
master
dev team
The scrum master
is not an option.

E2E Strat.
32
1 E2e process
more E2e
processes
more E2e
processes
more E2e
processes
more E2e
processes
component
component
component
component
component
component
component
component
component
component
component
component
component
component
component
sprint
release<SPRINT>
<RELEASE>
<SPRINT>
<SPRINT>
<SPRINT>
<SPRINT>
<SPRINT>
<SPRINT>
<SPRINT>
<SPRINT>
<SPRINT>
<SPRINT>
<SPRINT>
<RELEASE> <RELEASE> <RELEASE> <RELEASE>
time
productbacklog
Like for product
increments,
processes have to
be delivered
incrementally!

><
next
BUILD
MEASURE LEARN
WORKING
SOFTWARE
THE END-TO-END (E2E)
PROCESS IS THE OUTCOME AND
NOT THE INPUT OF A
DEVELOPMENT PROCESS

Acceptance Test Driven
Development or
Behaviour Driven
Development
minimal Toolbox to get
the job done
34
BPM Maturity process Impact Mapping

Discover
one single team
35
One Product Owner, Experts and an
Agile Coach.
Product Owner's mission is to
translate customers needs into
vision. Even if the project is a
migration, it is important to
consider each project as a new and
unique development.
Its activities focuses on
functionalities and the
identification of sponsors and key
users.
The Product Owner manages the project
from a Functional perspective. He/she
works with the Agile Coach in charge
with the organization, the
communication and the coordination.
The Development team is composed of:
- process experts
- domain experts
- test manager
- solution architect
- infrastructure
- data
Outcome of DISCOVER is to understand:
- what the needs of the customer
are
- challenge and validate the
project offer if RFD or CFD
- understand how the customer and
the users are using the previous
solution (customer experience)
- identify the possible automation
opportunities (service
experience)
- data quality: how the customer is
using data, is it stable?
- identify Focus Build blocks
covering the pillars of the
development: fits, no gaps,
WRICEFs
- design a prototype and a list of
assumptions.

Prepare
at least two teams
36
One team is testing the assumptions of
discovery phase and gather feedbacks on
the prototype.
In parallel, a second team composed of
- solution architect
- developers
- testers
is setting up the development environment
and all the necessary tools to ensure
early start.
The Agile Coach is setting up
communication and project management
tools for all stakeholders on the
project:
- Atlassian Jira or equivalent : to
support team work and cross
development, automatised reporting,
and remote work possibilities
- Videoconferencing tools like Skype
or Zoom
- Remote tools for Brainstorming,
decision making, etc…
- Link Jira with SolMan through PlugIn
The Product Owner is setting up SolMan
and Focused Build.
TOOLS ARE SUPPORTING THE DEVELOPMENT. THEY ARE NOT A CONSTRAINT FOR THE
DEVELOPMENT.TOOLS SHOULD NOT BE PART OF THE PROBLEM.
Tools are made to support the creation of value for the customer. The tool has no purpose and cannot be part of the deliverables.

Explore,Realize, Deploy
37
two or more teams
In the two initial phases, standards
and fits are already identified, and
a development team can start working
on it.
In parallel, the Product Owner will
work to collect custom developments
and gaps.
Because the project is growing in
term of capacities, the initial
Product Owner becomes Chief Product
Owner in charge of the coordination
of all sub-teams activities while
considering the project as a whole
product.
The working model evolves to Waves
and Sprints, adding new alignment
meetings such as scrum-of-scrums,
impediment bashing and Wave review.
All development is deployed on a
post-production environment
(production like) in a DevOps
approach. DevOps means development
and operations where operations are
not Run people but infrastructure.
Development teams are using
continuous deployment techniques:
ship when done avoiding the
traditional release transport.
Testing is integrating test
automation at every level, including
automatised end-to-end process
testing.
This approach will ensure Deployment
ready development.
Once the standards are deployed,
customs and gaps are starting
(ideally through parallel running
teams).
That development will ensure that in
case if the customer ends the
contract or if the service provided
terminates it, a working solution is
already usable.
On the other hand, that strategy
allows fast delivery of workable
pieces ensuring customer
satisfaction, stress reduction and
improved collaboration throughout the
project.
Two key roles are often missed in SAP
projects: Product Manager (Product
Owner) and Technical Architect.
Considering that agile is
evolutionary, we must acknowledge
that both Product Development and
Architecture are evolving too.
Note that any kind of projects are
always development projects even if
the nature of it is migration,
conversion or configuration.
Wave = releases

><
next
03Agile ACTIVATE
Details
39

><
next
in Bold Accountable
in Light : Responsible
Product
Owner
Agile Coach Developers Solution
Architect
Tester Data
Manager
Infrastructur
e
Comments
Discover Strategic
Planning
Pre-sales activities lead ideally by
Product Owner.
Application
Value and
scoping
Trial system
provisioning
Stakeholder
Identiﬁcation
(users,
sponsors)
Stakeholder
Identiﬁcation
(developers,
management)
Value
Discovery
ACTIVATE

><
next
Product Owner Agile Coach Developers Solution
Architect
Tester Data Manager Infrastructure Comments
Prepare Project Initiation
& Governance
Project Initiation &
Governance
Big Board collective planning:

- Goal

- Project Definition-of-Done

- Collective Retro-Planning

- Working agreement
Project Kick Off
& On-boarding
Projects
standards,
infrastructure,
and solution
Projects
standards,
infrastructure, and
solution
Projects
standards,
infrastructure,
and solution
Projects
standards,
infrastructure, and
solution
Projects
standards,
infrastructure, and
solution
Product Development Strategy:

1 - deliver standards first

2 - add customs

3 - integration and consolidation
Project Team
Enablement
Team is composed towards project goal.
Project Training
Strategy & Plan
Project Training
Strategy & Plan
Project Training
Strategy & Plan
Project Training
Strategy & Plan
Project Training
Strategy & Plan
More coaching than training: knowledge is
transferred all along the project when needed.
Technical
Requirements &
Solution Plan
Technical
Requirements &
Solution Plan
Technical
Requirements &
Solution Plan
High level technical architecture plan nimble
enough to adapt to emerging changes.
Demo
Environment
Demo
Environment
Project Support
Tools & System
Setup
Project Support
Tools & System
Setup
Project Support
Tools & System
Setup
Project Support
Tools & System
Setup
Project Support
Tools & System
Setup
Tools should be supportive to increase value
delivery and not part of the problem.
Initial Hardware
Proposal
Initial Hardware
Proposal
Business
Process Map
Business Process
Map
Business Process
Map
Part of the Product Development Roadmap.
BPM has too be made visible to ensure
alignment.
Activate Solution Activate Solution Activate Solution Activate Solution Activate Solution To avoid. ACTIVATE is not a solution. It distils
the idea that every projects are equally
reproducible when the opposite reflects the
truth.
Interface
Inventory
Interface
Inventory
Interface
Inventory
Part of the Functional Components Architecture
set.
Prepare Testing
Policy
Prepare Testing
Policy
Testing policy stands on ever levels-of-done
including test automation policy.
Data Migration
Approach &
Strategy
Data Migration
Approach &
Strategy
Data Migration
Approach &
Strategy
Data Migration
Approach &
Strategy
Value
Determination
Value
Determination
Value
Determination
Value
Determination
Value
Determination
Value determination is evolving all along the
project in every stages. It is full part of Product
Owner´s duty to prioritize the Product Backlog
based on value.
Organizational
Change &
Management
Roadmap
Organizational
Change &
Management
Roadmap
Organizational change is continuously based on
the different stages of development. Even if
agile design cross-functional teams, in some
aspects some expertise is more required at
different moments in time:

- more business analysis and architecture at the
beginning

- On-boarding on Run colleagues before
Cutover to ensure on-the-work knowledge
transfer.
in Bold Accountable
ACTIVATE

><
next
Product Owner Agile Coach Developers Solution Architect Tester Data Manager Infrastructure Comments
Explore Plan Solution
Validation
Workshop
Plan Solution
Validation
Workshop
The plan is evolving. Agile leads the idea of planning
instead of following a plan. Every plan should be
challenged at Wave Review/Planning.
Baseline Plan &
Build
Baseline Plan &
Build
Baseline Plan &
Build
Baseline Plan &
Build
Baseline Plan &
Build
Baseline Plan &
Build
Baseline is almost high-level.
Execution /
Monitoring/
Controling of
Results
Execution /
Monitoring/
Controling of
Results
Execution /
Monitoring/
Controling of
Results
Execution /
Monitoring/
Controling of
Results
Execution /
Monitoring/
Controling of
Results
Execution /
Monitoring/
Controling of
Results
Sprints, Waves, Boards
Technical Solution
Design
Technical Solution
Design
Technical Solution
Design
Technical Solution
Design
Wave Planning (High), Sprint Planning (Low)
Development
Environment
Development
Environment
Development
Environment
Development
Environment
Development
Environment
Fit Gap Analysis Fit Gap Analysis Fit Gap Analysis Fit Gap Analysis Fit Gap Analysis Fit Gap Analysis
Baseline Build Sign
Off
Baseline Build Sign
Off
Baseline Build
Sign Off
Baseline Build Sign
Off
Baseline Build Sign
Off
Baseline Build Sign
Off
Product Backlog
Prioritization
Sprint Backlog
Prioritization
Sprint Backlog
Prioritization
Sprint Backlog
Prioritization
Sprint Backlog
Prioritization
Sprint Backlog
Prioritization
User Access &
Security
Testing Strategy Testing Strategy Testing Strategy Testing Strategy Testing Strategy Testing Strategy Testing Strategy
Legacy Data
Migration
Legacy Data
Migration
Legacy Data
Migration
Legacy Data
Migration
Legacy Data
Migration
Stakeholder
Analysis
Stakeholder
Analysis
Communication
Plan
Change Impact
Analysis
End User Training End User Training End User Training End User Training End User Training End User Training End User Training
Value Realization Value Realization Value Realization
in Bold Accountable
ACTIVATE

><
next
Realize Sprint Invitation,
Execution &
Closing
Sprint Invitation,
Execution &
Closing
Sprint Invitation,
Execution &
Closing
Sprint Invitation,
Execution &
Closing
Sprint Invitation,
Execution &
Closing
Sprint Invitation,
Execution &
Closing
Sprint Invitation,
Execution &
Closing
QA Environment
Set Up Roles &
Transport
QA Environment
Set Up Roles &
Transport
SAP Going Life
check
SAP Going Life
check
SAP Going Life
check
SAP Going Life
check
SAP Going Life
check
SAP Going Life
check
SAP Going Life
check
Production
Environment
Production
Environment
Production
Environment
Fall-over
environment
Fall-over
environment
Fall-over
environment
Fall-over
environment
Detailed design
Core
Configuration and
Documentation
Detailed design
Core Configuration
and Documentation
Detailed design
Core Configuration
and Documentation
Detailed design
Core Configuration
and Documentation
Detailed design
Core Configuration
and Documentation
Enhancement
Development
Business Process
Procedure
Business Process
Procedure
Business Process
Procedure
System and
Performance Test
System and
Performance Test
System and
Performance Test
System and
Performance Test
System and
Performance Test
System and
Performance Test
Approved
Integration Test
Approved
Integration Test
Approved
Integration Test
Approved
Integration Test
Approved
Integration Test
Approved
Integration Test
Part of DoD
Approved User
Acceptance Test
More feedback than approbation
Scenario Test Scenario Test Scenario Test
QA Environment
Data Load
QA Environment
Data Load
QA Environment
Data Load
QA Environment
Data Load
QA Environment
Data Load
QA Environment
Data Load
Preliminary
Cutover Plan
Preliminary Cutover
Plan
Preliminary Cutover
Plan
Preliminary Cutover
Plan
Preliminary Cutover
Plan
Preliminary Cutover
Plan
Preliminary Cutover
Plan
System User Roles
& Authorisations
Administration
System User Roles
& Authorisations
Administration
System User
Roles &
Authorisations
Administration
Technical
Operations &
Handover Plan
Technical
Operations &
Handover Plan
Technical
Operations &
Handover Plan
Technical
Operations &
Handover Plan
Technical
Operations &
Handover Plan
Organizational
Alignment
Educational
Readiness Review
Educational
Readiness Review
Knowledge
Transfer
Knowledge Transfer
End User Training
Delivery Enabled
End User Training
Delivery Enabled
End User Training
Delivery Enabled
End User Training
Delivery Enabled
End User Training
Delivery Enabled
End User Training
Delivery Enabled
in Bold Accountable
ACTIVATE

><
next
Deploy / Run Release Closing Release Closing Release Closing Release Closing
SAP Going Life
Check-Verification
Session
SAP Going Life
Check-Verification
Session
SAP Going Life
Check-Verification
Session
SAP Going Life
Check-Verification
Session
SAP Going Life
Check-Verification
Session
SAP Going Life
Check-Verification
Session
Technical
Operations
Optimized
Technical
Operations
Optimized
Approved Technical
Systems Test
Approved Technical
Systems Test
Approved Technical
Systems Test
Approved
Technical Systems
Test
Product Cutover Product Cutover Product Cutover Product Cutover Product Cutover
Product Support
After Go Live
Product Support
After Go Live
Product Support
After Go Live
Organizational &
Production Check
ALM Optimised ALM Optimised ALM Optimised ALM Optimised
Set Up Control
Center
Set Up Control
Center
Pre-Go Live End-
User -training
Delivery
Change Control
Management
Optimised
Post Go-live End-
user training
Value
Management
in Bold Accountable
ACTIVATE

><
next
04Agile ACTIVATEExample
46

Wave Planning
47
OCT 20 NOV 20APR 20 MAY 20 JUN 20 JUL 20 AUG 20 SEP 20MAR 20
Sprint 1
OTC
Sprint 2
OTC
Sprint 3
OTC
Sprint 4
OTC
Sprint 1
FICO
Sprint 2
FICO
Sprint 3
FICO
Sprint 4
FICO
Sprint 1
MM /
VIM
Sprint 2
MM / VIM
Sprint 3
MM / VIM
Sprint 4
MM / VIM
Sprint 1
EWM / TM
Sprint 2
EWM / TM
Sprint 3
EWM / TM
Sprint 4
EWM / TM
Sprint 3
Dev
Sprint 4
Dev
Sprint 1
Dev
Sprint 2
Dev
Sprint 5
OTC
Sprint 5
FICO
Sprint 5
MM / VIM
Sprint 5
EWM / TM
Sprint 5
Dev
Sprint 6
OTC
Sprint 6
FICO
Sprint 6
MM / VIM
Sprint 6
EWM / TM
Sprint 6
Dev
Sprint 3
Migration
Sprint 4
Migration
Sprint 1
Migration
Sprint 2
Migration
Sprint 5
Migration
Sprint 6
Migration
FUNCT.INT.TEST
Sprint 7
OTC
Sprint 7
FICO
Sprint 7
MM / VIM
Sprint 7
EWM / TM
Sprint 7
Dev
Sprint 7
Migration
WAVE PLANNING
WAVE REVIEW
WAVE RETROSPECTIVE
SCRUM-OF-SCRUMS
IMPEDIMENTS BASHING
FUNCT.INT.TEST
FUNCT.INT.TEST

><
next
DAILY MEETINGS
•daily stand up
•Attendees: Scrum Team (Development Team,
Scrum Master, Product Owner)
•Moderation: Scrum Team (self organised)
•Purpose: status meeting, highlight
impediments
•Duration: 15 minutes
•When: each day, same time, same location
WEEKLY MEETINGS
•refinement meetings
•Attendees: Scrum Team (Development Team,
Scrum Master, Product Owner) + people to
respond on team issues
•Moderation: Scrum Master
•Purpose: grooming both Sprint and Product
Backlog in Development perspective, Planning
Poker (effort estimation), collaborative
solution focused meeting
•When: once a week
•scrum-of-scrums
•Attendees: Product Owners, Management
(passive) & Customers (passive)
•Moderation: Chief Product Owner
•Purpose: status meeting on development,
identify and respond on overlaps and hints
•When: once a week, same day, same place
•Grooming
•Attendees: Product Owners,& Customers
(passive)
•Moderation: Product Owner
•Purpose: user stories and product backlog
grooming, set up business values on user
stories
•When: once a week, same day, same place
BI-WEEKLY MEETINGS
•sprint Planning
•Attendees: Management & Customers (on-
demand), Scrum Team
•Purpose: defining Sprint Objective and
Sprint Backlog
•When: at Sprint start
•sprint review
•Attendees: Management & Customers (active),
Scrum Team
•Purpose: show and tell of sprint outcomes,
inspect/adapt from the stakeholders
•When: at the end of the Sprint
•sprint retrospective
•Attendees: Scrum Team
•Moderation: Scrum Master
•Purpose: inspect/adapt from the development
process,
•When: after Sprint Review
MONTHLY MEETINGS
•Wave Planning
•Attendees: Management, Customer, Agile Teams
•Purpose: Update the roadmap according to
Sprint outcomes
•When: before Sprint Planning
•Wave Review
•Purpose: Update the roadmap according to
Sprint outcomes
•When: after Sprint Review
•Wave Retrospective
•Moderation: Agile Coach
•Purpose: Review of wave activities,
impediments, lessons learned, amelioration
plan, team building
•When: after Wave Review
M
EETINGS

Level of done
“done” layers
50
DEV. TEAMPRODUCT OWNER
P RODU CT
ROADM AP
SPRINT
EPIC
ITEM

definition of done for
a product log item
51
criterion description responsible
implemented
a product log item is implemented when its fully coded, deployed in the code
management repository
scrum team
unit test passed
successful unit testing was performed in a development environment. Test results
are stored for review.
scrum team
integrated the code is integrated in an integration test environment scrum team
integration test
passed
successful integration testing was performed in an integration environment
covering functional validation of the product backlog item
scrum team
regression pack
tests cases are selected for future re-use, are stored in Solution Manager and
are ready to re-using in the regression test of next sprints scrum team
reviews
the delivery code and the unit tests were reviewed and are respecting guidelines
and security aspects.
scrum team
permanent
documentation
existing permanent documentation was updated and new documentation was delivered scrum team

definition of done for
a sprint / Wave
52
•Burndown chart delivered
•Retrospective minutes of
meetings: Lessons
learnt, actions, payment
agreement
•Product log updated
(Done, items back to the
list from sprint back
log)
•Code baselined
•Accepted by the Business
at least after the demo

“done” thinking grid
53
user story
clarity
task
identified
product
owner
approval
product
backlog
updated
environ-
ment ready
design
complete
•unit test
cases
written
documen-
tation
pre-release
builds
code
complete
unit tests
executed
refactor-ing
code checkin
code merging
& tagging
automa-ted
code review
peer review
code coverage
burndown
chart ready
release build
functional
testing
regression
testing
perfor-
mance
testing
accep-
tance
closure

Sprint planning “Done”
54
User stories selected
for the sprint are
complete with respect to
product theme,
understood by the team,
and have been validated
by the detailed
acceptance criteria.
User Story Clarity
Tasks Identified
Tasks for selected
user stories have
been identified and
estimated by the
team.
These first
two topics are
typically covered in
the sprint planning
meeting but are
mentioned as done
criteria for the
sake of
verification.
Build and package changes
Build and package changes
have been communicated to
the build master. These
changes have been
implemented, tested and
documented to ensure that
they cover the features of
the sprint.
Product owner approval
Each finished user story
has been passed through
UAT (User Acceptance
Testing) and signed off
as meeting requirements
Updating Product Backlog
All features not done during the
sprint are added back to the
product backlog. All incidents/
defects not handled during the
sprint are added to the product
backlog.

• Development environment is
ready with all third-party
tools configured.
• Staging environment is ready.
• Continuous integration
framework is in place. The
build engine is configured to
schedule hourly, nightly, and
release builds.
• Desired build automation is in
place. Why "desired"? Because
there is no end to build
automation :)
• Test data for the selected
features has been created
Environment ready
Design complete
Design analysis is complete as per
the user story or theme. UML
diagrams are either created or
updated for the feature under
development.
You might need to prototype various
components to ensure that they work
together. Wireframes and prototype
have been created and approved by
the respective stakeholders.
Unit test cases written
Unit test cases have been written
for the features to be developed.
Documentation Ready
Documentation (Just enough or whatever
the team agrees to) to support the
sprint demo is ready
Pre-Release builds
• Pre release builds (hourly/nightly) have been happening
and nightly build reports have been published on regular
basis. The following could/should be part of pre-release
builds:
• Compile and execute unit test cases (mandatory)
• Creation of cross reference of source code
• Execution of automated code reviews for verification of
coding rules
• Code coverage reports are generated
• Detection of duplicate source code
• Dependency analysis and generation of design quality
matrix (static analysis, cyclomatic complexity)
• Auto deployment in staging environment
• It comes down to build automation; there is no end to
what can be achieved from automated hourly, nightly
builds. The team along with the product owner needs to
decide on how much build automation is required.

Dev Team Done
56
Source code changes are done for all
the features in the “to do” list.”
Source code has been commented
appropriately.
Code Complete Code Refactoring
Source code has been refactored to
make it comprehensive, maintainable
and, amenable to change.
A common mistake is to not keep
refactoring in the definition of
done. If not taken seriously,
refactoring normally spills out to
next sprint or, worse, is completely
ignored.
Unit testing is done
Unit test cases have been
executed and are working
successfully
Code checkin
• Source code is checked in the code
library with appropriate comments added.
• If project is using tools which help in
maintaining traceability between user
stories and the respective source code,
proper checkin guidelines are followed.
Code merging and tagging
Finalized source code has been
merged with the main branch and
tagged appropriately (merging and
tagging guidelines are to be used)
Automated Code reviews Code coverage is achieved
Code coverage records for each package
are available and whatever the team has
decided as the minimum benchmark is
achieved.
Peer reviews
Peer reviews are done. If
pair programming is used, a
separate peer review session
might not be required.
Project metrics are ready
Burndown chart has been updated
regularly and is up to date.
Release Build
Build and packaging. A Build (successful) is done
using continuous integration framework. Change log
report has been generated from Code Library and
Release notes have been created. Deliverables have
been moved to release area.
Build deployment in staging environment. Build
deliverables are deployed in staging environment.
If it is easy, this step should be automated.
Automated code review has been
completed using the supported tools/
technologies. Violations have been
shared with the team and the team has
resolved all discrepancies to adhere to
the coding standard. (Automated code
reviews should be hooked up with CI
builds.)

Release Done
57
Automated testing 
All types of automated test cases have been
executed and a test report has been
generated. All incidents/defects are
reported.
Manual testing 
Quality assurance team has reviewed the
reports generated from automation testing
and conducted necessary manual test cases
to ensure that tests are passing. All
incidents/defects are reported.
Build issues 
If any integration or build issues are
found, the necessary steps are repeated and
respective “Done” points are adhered to.
Functional testing done Performance testing done
A common mistake is to not keep
performance testing in the definition of
done. This is an important aspect. Most
performance issues are design issues and
are hard to fix at a later stage.
Regression testing done
Regression testing is done
to ensure that defects
have not been introduced
in the unchanged area of
the software.
Acceptance testing done
Each finished user story has been passed
through UAT (User Acceptance Testing) and
signed off as meeting requirements (see also
).
Closure
All finished user stories/tasks are marked
complete/resolved. Remaining hours for task
set to zero before closing the task.
Other necessary/optional activities. Anything
which is very specific to the project
environment. These might include: Security
audit sign off, Deployable on multiple
platforms such as Windows, Linux, and Mac OS
X

><
next
CUSTOMER ENGAGEMENT
DAILY
daily meeting (optional) 
permanent alignment with PO
WEEKLY Backlog Grooming sessions
BI-WEEKLY
Sprint Planning
Sprint Review (acceptance testing)
MONTHLY Release planning & Release Retrospective
7 PEOPLE MAX
PER TEAM
april october
mostly
functional
topics
function
al / E2E
topics
consolidation
ROLLOUT CONCEPT
IM
PORTANT

FOR FURTHER
QUESTIONS  
PIERRE.NEIS@AGILESQR.COM
60

Other articles
62
Experiences: UX, CX, SX, PX, OX, EX i
Portfolio Management i
AO Programs i
AO Projects with Scrum X i
Is agile possible in an SAP
(ERP) or Business Process
related context (Banks)
possible
i

><
next

Agile SAP ACTIVATE

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Agile SAP ACTIVATE

Similaire à Agile SAP ACTIVATE (20)

Plus de Pierre E. NEIS

Plus de Pierre E. NEIS (20)

Dernier

Dernier (16)

Agile SAP ACTIVATE