1. www.sygit.ch
Be Agile when implementing Agility
Be Wagile for a smooth Delivery
Agility : an Iron Fist in a Velvet Glove
Marc BURLEREAUX, marc.burlereaux@pmi-fr.org
European Release Manager at a Swiss Private Bank, Geneva
Head Of PMI sub-branch « Pôle des Pays de Savoie »
PMP, PMI-RMP, PgMP, ITIL V3
Sylvain GAUTIER, sylvain@sygit.ch
Consultant SME and Coach Agile / ITIL / BPMN at SYGIT, Geneva
Christine RIEU, christine.rieu@univ-savoie.fr
Lecturer, Laboratoire LISTIC, Université de Savoie, Annecy
Member of Steering Committee PMI « Pôle des Pays de Savoie »

2. www.sygit.ch
Summary
Foreword
1. Agile Basics
2. Agile Projects
Best practices
Use Case
Key for success
Agile Process
3. Challenges for a smooth Delivery
Context
Pitfalls
Tips and Tricks
Governance
4. Focus on Human factor
Conclusion

3. www.sygit.ch
Foreword
Private Banking expertise
Program &
Release
Manager,
Senior
Volunteer
at PMI
Lecturer, Research in the
Knowledge Management
area, Senior Volunteer at PMI
Agile SME &
Coach,
ITIL, BPMN

4. www.sygit.ch
1. Agile Basics
 All kind of projects – Nevertheless Context dependent
 Could be combined with traditional method
 Iterative & incremental development process
 Collaborative work : Value the human factor
 Use case driven
 Early engagement of Architecture
 Risk driven
ProcessA
Event1Event2
TU1
Event3
TU2
Event4
ProcessB
Processus
Driven
SOA
Company
Repository

5. www.sygit.ch
1. Agile Basics
con’t
 Pragmatic Methodology based on the fact that « Requirements are
evolving »
 Value the Business / Users Feedback
 The CHANGE REQUEST is not anymore a problem : the project embrace it
 Permanent and on the spot feedback
 Stay simple: focus on essential – maximise the work not to be done
 Main Objective : Speed – Velocity and Continuous Improvement

6. www.sygit.ch
2. Agile Projects
Best Practices
 Foundations
• Backlog (Requirements)
• Use Cases
• Process Activity (business process)
 Business Risks Analysis
 Non fonctional Requirements early identification
• Repository
• Clear Requirement : short sentences
 Poker Planning : most strategic piece of work
• Project costing
• Agreement on deliverables

7. www.sygit.ch 2. Agile Projects
Use case
Use case are not only a requirements gathering technic
It also permit to link all activities
Analysis
Model
Conceptual
Model
Specified by Realised by Implemented by Distributed by Verified by
Deployment
Model
Testing Model
Implementation
Model
Use case y Use case z
<<fragment>>
Ivar
Jacobson
Project Heart !

8. www.sygit.ch
2 Agile Projects
Key for Success
 Iterative Process : SPRINT !
 incremental delivery
 2 to 4 weeks : time box
 Synchronous Iteration for all combined Projects / Deliverables
 Scrum Master = Iteration coordinator
 Product Owner : Iteration Pilot – Risk Driven
 Planning of 2 SPRINTs maximum

9. www.sygit.ch
Process : Agile Iteration
ProjectTeam
SCRUMMasterScribe
Daily Scrum
CeremonySprint Planning
Ceremony
Iteration
START
Iteration Backlog
written
Iteration Plan
Inputted
Daily Scrum
Done
Progress
Inputted
CPUCPI
Produce Analysis
Produce the IT models
Perform functional testing
Perform technical review
Produce conception
Développement
Perform IT testing
Enter Iteration
Backlog
Enter progress
Task
Realised
Adjust perimeter
Review the Backlog
9H00 Game Over
Action Plan
Written
Close the iteration
Iteration
END
Iteration End
– 4 Days
Project
Backlog
updated
Major Event
Backlog
updated
Iteration
closed
Update project
management
deliverables
Deliverables
Updated
Demo
done
Demonstration
Retrospective
Game
Over ?
Yes
No
Next of
pressentation
2 Agile Process

10. www.sygit.ch
Process : Agile Iteration
Process ID xxxxxxxxx
Process summary Manage your month so Agile
Process owner Agile
Version 0.1
Status Draft / to review/ validated / communicated
Reviwed by Sylvain Gautier
Status date 23/01/2013
Mission statement
An iteration is a period of 4 weeks during which the team built a functional product increment
Process Objectives
An iteration begins with a planning meeting and ends with a review of the product and a retrospective
The team is "protected" during the iteration, the processing of new requirements is postponed to the next iteration
To set the good rhythm in the project and to compare the iterations, all must have the same length for a given project
Best practices:
1. The commitments result in deliverables with a level of agreed quality , as an executable from unit testing, acceptable specifications for development, etc..
2. At the end of iteration, we formally analyse the results on the basis of facts and tangible deliverables.
3. The results of the iteration are summarized in a report with recommendations and corrective actions to prevent the same mistakes are not repeated.
4. The objectives of iterations remain stable during the iteration.
5. The objectives of the iteration are not reviewed during iteration, no additional objective is added.
6. The changes will be requested on the next iteration, except in truly exceptional events.
7. A change objectives can only disempower the teams on outstanding commitments.
8. The iterations are synchronized between all projects. The timing of iterations enable to manage consistency of the work on several projects, particularly in the central teams
managing common components.
9. The iteration regularly collects all project participants and to exchange on factual information about the project.
10. We must create a genuine spirit of "project" and a common goal in which everyone can participates from its point of view and from its area of responsibility.
11. Each goal / task is a personal commitment, not forced, from each contributor, which is fully committed to its ability to deliver.
12. The reliability of the commitment is even stronger than the contributor agrees only on the month ahead, so the near future.
13. The commitments reflect the availability of resources and people
14. The iteration ends at its end date, not when all objectives are met. We look at the iteration end date, if the objectives have been achieved and the precise causes of delays
or disruptions.
15. The Scrum Master is the coordinator of the iterations of the project. He ensures that each contributor involved in the project has the potential to work properly.
Links to reference documents
Link 1
Link 2
Link 3
Link 4
Home Next

11. www.sygit.ch
Process : Conduct an iteration
Process Objectives
Best practices on how to conduct Elaboration Phase
1. Manage iterations by the risks
2. The first iterations, design, implement and test the priority use cases
3. Design, implement and test the central and risky architecture, the architecture is built iteratively by implementing the use structuring case in terms of architecture
4. Adapt to each iteration based on test results, and feedback from users & developers
5. It has only two iterations planned ahead, beyond is unpredictable.
6. Not to produce too many specifications in advance: The User project manager should have time to assist the IT (the goal is to have 80% of the specifications at the end of
the elaboration phase).
7. The Scrum Master is the custodian of the method.
8. The first priority of the Scrum Master is to remove obstacles that stand in front of his team.
The term "Sprint" given to the conduct of an iteration is inappropriate:
1. We make in fact a long distance race.
2. One iteration = one lap.
3. Once an iteration is completed, we immediately begin another, there is no pause.
4. The Scrum Master household his team.
Facteurs de succès
1. The iteration objectives are confirmed by the demonstration
2. The project team is motivated
PreviousHome

12. www.sygit.ch
Activity: Sprint Planning Ceremony
Activity ID xxxxxxxxx
Activity Summary Build your work's "Cocoon"
Main used tool Manual
Risk impact on process Probability 10% Impact Strategic
Activity objectives
• "As a team, we plan the next iteration based on priorities and our capacity in order to commit ourselves to carry on the perimeter. "
• Planning for the next iteration immediately = detail the tasks to be performed.
• Select the features to perform, identify tasks, and their completion criteria for acceptance, and all that from the Product Backlog: features prioritized and estimated (points
Tasks / Procedure
Preparation
The Product owner shall review the Product Backlog, adds, deletes and edits stories, adjusts priorities as required.
Planning
The Product owner select the stories to be developed in the iteration, and propose this list the Scrum Master
The Scrum Master identifies additional stories (defects to be corrected, engineering, etc.).
Task dependencies from one iteration will not be evaluated here: this aspect will be dealt on the daily scrum meeting
Determine the level of quality expected for items developed during the iteration
The definition of "finished" is established, reviewed and validated jointly (look at: Good task)
The objectives of the iteration are specified
To determine the ability of the team
Calendar Capacity: CC = (effective duration of the iteration) - vacations - other commitments
Planned capacity: PC = CC * focusing factor (estimated), default = 6/8 = 0.75
Decomposition
For each Use Case or component, the team imagines the tasks (specification, design, coding, business, coding, data interface, GUI coding, unit testing, technical tests,
integration tests, documents and manuals, etc.).
Estimate
Each task is estimated by the "experts" of the team. A consensus value is used.
Note: the estimate of a task varies from 0.25 to 2 "ideal day". If a task requires two people, multiply by 2!
Audit the accounts
Make the sum of task estimates and compare with the calculated capacity. Check the feasibility depending on the nature of the tasks and needed skills on the period
Negotiate
The Scrum Master and the Product Owner negotiate a reduction (or increase!) of the iteration scope in case of under-or over-capacity.
Commit
Collectively, the team gives his opinion on the feasibility of the plan ...
Get commitment from each of the tasks assigned, including tasks carried over from the previous iteration.
Links to reference documents
Link 1
Link 2
Link 3
Good
Task
Good
Story
Product Backlog
Home

13. www.sygit.ch
Product Backlog
Use
Case
Variant 2
Variant 1
Nominal
Case
• No more than ½
iteration
• Can be demonstrated
Requirement
3
Requirement
2
Requirement
1
Story 2
Story 3
Task 1Story 1 Task 2 Task n
…
Non functional
Requirements
Task 1Story n Task 2 Task n
…
Previous

14. www.sygit.ch
Activity: Daily Scrum Ceremony
Activity objectives
Every day, a meeting allows the team and the Scrum Master to monitor progress on the tasks and challenges.
This meeting last for 15 minutes maximum: the Daily Scrum.
Are present: The Scrum Master, the coach, and the contributors.
Tasks / Procedure
1. Be sure to name the "scribe" at the beginning of the session.
2. Each member answers three questions:
1. What did I do yesterday?
2. What will I do today?
3. What are the challenges / difficulties I meet?
3. The turn of speech must be strictly observed to avoid drift.
4. Activities can be run in parallel: analysis, design, coding, integration, testing, etc..
5. The choice of dependencies between tasks is performed here (dependencies, skills, ...).
6. The choice of suspending a task blocked by technical difficulties is made at this meeting.
7. If a task is not feasible, it can be put back in the backlog.
Best practices:
1. If possible, the team works in the same room.
2. If the need arises, the discussion can then be made freely, after the Daily Scrum.
3. This meeting is a synchronization point for the team and should not be considered as a progress report.
Links to reference documents
Link 1
Link 2
Link 3
Home
Activity ID xxxxxxxxx
Activity Summary Team Coordination Meeting
Main used tool Manual
Risk impact on process Probability 10% Impact Sensible

15. www.sygit.ch
Activity: Demonstration
Activity objectives
1. The team describes and demonstrates the new features to stakeholders and gather feedback = product review (quality of design / defaults ....).
Tasks / Procedure
1. Perform the demonstration of the product increment produced during the iteration:
1. The increment product is verified, demonstrated and validated
2. The defects are noted to be entered as tasks of the story "bug fixes" for the next iteration
2. To review the tasks of the previous iteration:
1. Done / not done.
2. Number of defects found.
3. Defer not done tasks on the next iteration (new tasks).
4. Report faults on the next iteration (new tasks), with priority 1.
5. Calculate the project progress: Example: 70% of the points are shown (% of the status of the manufacturing process).
3. Write a summary of the iteration and improvement measures in the Flash Report.
Links to reference documents
Link 1
Link 2
Link 3
Home
Activity ID xxxxxxxxx
Activity Summary Demonstrate the product increment
Main used tool Manual
Risk impact on process Probability 10% Impact Critical

16. www.sygit.ch
Activity: Perform Retrospective Ceremony
Home
Links to reference documents
Link 1
Link 2
Link 3
Activity ID xxxxxxxxx
Activity Summary Analyse the process, search the causes, suggest improvements
Main used tool Manual
Risk impact on process Probability 10% Impact Critical
Tasks / Procedure
Initialization (15 ’)
1. A team member summarizes what has been delivered, the status of what remains to be done (planned and not done), and an update on the decisions taken at previous
retrospective.
Identification of positive and negative points (20 '- 30’)
1. Each member of the project list the positives and negatives of the iteration (alone or in pairs)
Analysis (60 '- 90’)
1. The team members present their ideas, and the team look for the causes of malfunctions or the factors that led to good results.
2. The team selects the most significant elements
Decisions (30 '- 60’)
1. The team decides on the action plan:
2. Improve practices
3. Renew the practices that have had positive effects
Closing
1. Team commitment
Note
1. Duration : from 1 to 3 hours
Activity objectives
1. As participants in the project, we regularly analyse our processes and our work procedures to improve efficiency.
2. The team has a look on methodology, tools and Human aspects on the iteration that ends = Process Review (effectiveness, efficiency).
3. Good practices and practices to be changed are identified
4. Decisions are made to optimize the process

17. www.sygit.ch
Activity: Adjust perimeter
Exceptions
Home
Links to reference documents
Link 1
Link 2
Link 3
Activity ID xxxxxxxxx
Activity Summary Change the iteration backlog, in cases of major event
Main used tool Manual
Risk impact on process Probability 10% Impact Critical
Tasks / Procedure
1. Remove a story from Iteration Backlog and replace it in the Project Backlog
2. Move a task of a story of the iteration to a story in the next iteration
3. Practice exchange for free
4. Trace the movements of story / task in the flash report of the current week
Activity objectives
1. Change the objectives of the iteration, the lower priority items are eventually excluded.

18. www.sygit.ch
Activity: Review the Backlog
Home
Links to reference documents
Link 1
Link 2
Link 3
Activity ID xxxxxxxxx
Activity Summary Prepare the next iteration
Main used tool Manual
Risk impact on process Probability 10% Impact Critical
Tasks / Procedure
Ensure Stories cover all needs
1. All Use cases and fragments are represented by Stories
2. Stories can be created for training activities, building development platform, etc..
Check estimates in points
1. All stories are estimated in points
2. The estimates are consistent (with the knowledge of the moment ...)
3. New stories are estimated
Review priorities
1. ≈ 20% of stories to achieve: high priority
2. ≈ 30% of stories to achieve: Medium priority.
3. ≈ 50% of stories to achieve: Low Priority
Decompose high priority Stories in Stories of appropriate size
1. Choose one or more axes of decomposition
2. Create the identified stories , describe them, plan them, estimate them in points
3. Remove obsolete stories
Notes:
1. Duration : 2 to 4 hours
2. This additional time in meetings is largely cushioned by the decline in the planning tasks and the time saved on the preparatory work for the next iteration.
3. The Backlog review is a team effort, led by the product owner, assisted by the project members if required. It is not necessary to involve the whole team (except for
re-estimation of stories)
Activity objectives
1. "As a team, we maintain the product backlog up to date in order to have a realistic view of the outstanding work and priorities and to plan the next iteration."
2. Consider what has changed in the Project Backlog
3. Preparing for the next iteration, facilitate planning, and to make the ceremony of the next iteration planning more efficient and less time consuming
4. Perform change for free : as the budget of the project must be kept unchanged, if new user cases or requirements are coming ask which other requirements have to return
to the product backlog and be realized within another release.

19. www.sygit.ch
Activity: Perform technical review
Home
Links to reference documents
Link 1
Link 2
Link 3
Activity ID xxxxxxxxx
Activity Summary Ensure compliance with quality standards throughout the project
Main used tool Manual
Risk impact on process Probability 10% Impact Critical
Tasks / Procedure
1. Perform code review between two team members
2. Review of "logs" of the tools (version control, DBMS, CMDB) list the items that were actually created, modified, deleted, by whom and when.
3. Verify the proper implementation of norms and standards of the used tools.
4. Create tasks for necessary adjustments in a story "Adjustment / quality standards" planed in the next iteration: Pay the technical debt.
5. If too much defects have been identified during preceding iterations, it can be a good idea to propose an iteration only dedicated to bug fixing and refractor.
Activity objectives
1. Conduct reviews on the deliverables of all used tools

20. www.sygit.ch
Activity: Perform IT testing
Home
Links to reference documents
Link 1
Link 2
Link 3
Activity ID xxxxxxxxx
Activity Summary Test the story
Main used tool Manual
Risk impact on process Probability 40% Impact Critical
Tasks / Procedure
1. Test what is produced, according to what was described in the design and modelling documents.
2. Correct immediately what can be.
3. Report defects not immediately corrected on the next iteration (new tasks), in a story of a priority 1.
Activity objectives
1. Ensure that stories are developed according to the validated design and modelling
Exceptions
None

21. www.sygit.ch
Activity: Perform functional testing
Home
Links to reference documents
Link 1
Link 2
Link 3
Activity ID xxxxxxxxx
Activity Summary Test the Use case, and its related requirements
Main used tool Manual
Risk impact on process Probability 40% Impact Critical
Tasks / Procedure
1. Test what is produced, according to the specifications (Use cases, fragments, variants, requirements, business rules), if possible as the development is produced and
deployed on the test environment.
1. Report bugs and the non-alignments of specifications with the code and / or design, at the Daily Scrum of the next day.
Activity objectives
1. Ensure that the increment is developed in line with the Use Case specifications (and the associated requirements and business rules).
Exceptions
None

22. www.sygit.ch
Activity: Produce the IT models
Home
Links to reference documents
Link 1
Link 2
Link 3
Activity ID xxxxxxxxx
Activity Summary A good model is better than 100 documentation pages
Main used tool Manual
Risk impact on process Probability 30% Impact Critical
Tasks / Procedure
1. Organize workshops
2. Realize the models (class diagrams, sequence diagrams, activity diagrams, data models, component architecture ....).
3. Reformulate the models
4. Forward models to architects
5. Correct the models according to the remarks made by the architects
Activity objectives
1. The IT and the architects perform the necessary design models, using the right tools.
Exceptions
None

23. www.sygit.ch
Activity: Produce conception
Home
Links to reference documents
Link 1
Link 2
Link 3
Activity ID xxxxxxxxx
Activity Summary Describe the "story" that exists between the models
Main used tool Manual
Risk impact on process Probability 20% Impact Sensible
Tasks / Procedure
1. Write technical specifications in addition to the models.
2. Describe how the models work together.
3. Describe the behaviour of IT components.
4. Establish the necessary explanatory diagram, by using the referenced tools, as far as possible.
Activity objectives
1. Write technical specifications, related explanatory diagrams showing the logical design of the solution.
Exceptions
None

24. www.sygit.ch
Activity: Produce Analysis
Home
Links to reference documents
Link 1
Link 2
Link 3
Activity ID xxxxxxxxx
Activity Summary Write the functional specifications
Main used tool Manual
Risk impact on process Probability 20% Impact Sensible
Tasks / Procedure
1. Accurately describe the Use Cases (nominal and variants)
2. Clearly describe the business rules associated with use cases
3. Describe the sequence of screens
4. Achieve the Models of the GUI
5. Coordinate and exchange with other product owners to avoid duplication of functions between the projects (Shared read access on tools for all projects is an
important aid to deal with this point).
1. Export specifications in a MS-WORD document within a shareable archive.
Activity objectives
1. Write functional specifications, within the enterprise repository tool.
2. Keep concise, unambiguous and clear.
Exceptions
None

25. www.sygit.ch
What is a “good task” ?
 This is a limited task whose realization is limited in time (2 days)
To remove the tunnel effect of early identification and overruns associated with
difficulties
The effort for a task is between 2 and 12 hours 'ideal' in general
Beware of scheduled tasks to be run by two people (we multiply the effort by two!)
 The expected result is described in an intelligible way, clear and can be
quantified
Examples: a document, source code, description of test cases, deployment of a tool, ...
We can say: "it's over"
 This is a task that contributes to the completion of the ongoing iteration
objectives
Development of a story (from specification to integration)
Technical tasks "to test the development environment," ...
Increase in skills: training, working in pairs senior / junior
 What's a "not good task"?
Recurring and mandatory tasks of the project are not planned (Scrum ceremonies,
demonstration, etc.).
Tasks such as "I keep 10 hours in case I have a problem, nobody knows"
Project management meetings
Previous

26. www.sygit.ch
What is a “good story” ?
 This is a business function understandable and usable by a user
(or a computer if it is a technical function of the architecture)
 This is necessary so that the progress of the project is based on the delivered
features
(with the expected level of finish)
 It's a Use Case, or a fragment or a part of UC / fragment where
The tasks from designing to demonstration can be performed during a single
iteration
The "right" time to complete the story is around 1/2 iteration:
To reduce the tunneling effect
To facilitate the scheduling of work
To maximize the number of stories completed by the end of iteration
 In a nutshell
A use case is strictly a functional or user view
A story is a function that takes into account the needs of engineering (cutting
the Use
Case into multiple stories that can be implemented in one iteration)
Previous

27. www.sygit.ch
 Global Private Banking
 Combined CHANGES delivered in same Release Cycles
– Weekly and Monthly Releases
– Change The Bank: « Projects or Minor Enhancements Deliverables »
– Monthly Fix pack for certain Products
 Delivery Figures
– 100 à 150 Projects deliverables per year
– 100 à 150 Minor Enhancements per year (small projects : less than 6 MM)
 Methodological context : MIX
– Risk based « classical » methodology (Waterfall)
– Tollgates Process
– Agile delivery for certain Products
– Trend to implement more Agility in all Software Delivery
– Trend to enhance the Release Process to be more Lean and Agile
 Out of scope
– Incidents fix (ITIL niveaux 1, 2 et 3)
– Infrastructure change without any business impact
3. Challenges for a smooth Delivery
Context

28. www.sygit.ch
 Too frequent delivery
– Stakeholders overloaded (including the business)
– Testing Teams
– Training Teams
– Implementation and Release Teams
– Change Delivery organisation
– Less « shared visibility »: challenge to identify, track & control the DEPENDENCIES
– Risk of production impact, SLA breach
 Lack of Architecture / Security / Testing early engagement
– Technical Debt
– Costly refactoring with business impact
 Lack of Integration / Infrastructure early engagement
 Lack of Deployment and Support early engagement
Results :
Production sometimes managed by Project Teams (or Third Party Vendor …)
Production instability
Technical Debt
Refactoring
Bad IT image , …
3. Challenges for a smooth Delivery
Pitfalls

29. www.sygit.ch
 Early Engagement of Key Stakeholders since first SPRINTs
– Architecture team
– Security team
– Integration, infrastructure & deployment teams
 Quality required : Early alignement of all key stakeholders to avoid
– Late rejection of deliverables
– Technical Debt
 Test Team Early Engagement – Test automation – Test Driven Development
 Support Team Early engagement
 Not too frequent deliveries in production
 Non Functional Requirements mandatory for a successful delivery
 ITIL concepts
3. Challenges for a smooth Delivery
Tips & Tricks

30. www.sygit.ch
 Tollgate Process :
FIRST : Project Set-up for success and aligned with business strategy
 Have Change Delivery « Project Managers »: Business Coordination
 Continuous Integration, a challenge if many Products impacted
 Strong Acceptance to ensure quality & compliance
– Business acceptance (Functional requirements)
– Technical acceptance (Non Functional requirements)
 « Wagile » implementation: Rigorous transition to Production
– Share the Change and the Rollout Roadmap
– Quality control
– Dependencies identification & Management
– Limiting Factors Management (internal and external, Human and Others)
– Risk management
3. Challenges for a Delivery
Governance

31. www.sygit.ch
4. Human Factor
 Project Manager Evolution
 Value Added generator
 Coach, « Protecting role»
 Team Self Management, Self Organized
 Have fun working together
 Pragmatic approach
 Quickly capitalise on Lessons learned – Continuous Improvement
 Long term performance
 Quality as common objective
 DO BETTER does not mean DO MORE OR TOO MUCH : STRESS proof
 Collective Intelligence should not prevent the Individual Creativity
Manager
Controller
Inspiring Leader
Facilitator
!

32. www.sygit.ch
Conclusion
 Agile Methods = Philisophy and Mindset – nor Dogm neither Toolbox
 Take into account the context / environment
 Best of Breed from both « Agile and Traditional / Waterfall Worlds »
 Be Agile (and open) when implementing Agile
 Change Delivery still needs Project Managers
 Be Wagile for a smooth transition to production
 Agility is too important to be left to the Techies 
 PMI (Project Management Institute) look for Agility
• New credential PMI-ACP (Agile Certification Practitioner)
• PMBOK 5th Edition : iterative planning