20130821 agility an_iron_fist_in_a_velvet_glove

www.sygit.ch

Be Agile when implementing Agility Be Wagile for a smooth Delivery

Agility : An Iron Fist in a Velvet Glove

www.sygit.ch

Authors

Marc BURLEREAUX, [email protected] (Swiss Private Bank) has more than 27 years of expertise in Project, Program and Portfolio

Management with a proven track record in the field of Swiss Private Banking. Marc is a

Senior Volunteer at PMI, Director of “Pôle des Pays de Savoie” (PMI France Chapter) and also

a member of the PgMP® & PMI-RMP® Credentials PRC (Panel Review Committee). Marc has

been applying agile technics for the past 10 years, and more recently has spent two years as

Head of European Release Management in a Swiss Private Bank.

Sylvain GAUTIER, [email protected] (SYGIT) has more than 27 years of expertise in IT and started his career working as a

consultant, and then as an architect, within the Software Industry (Computer Associates,

Sybase). Sylvain focused mainly on data design, DBA, and project management

methodologies for major European projects before becoming Head of IT Operations for an

important private bank in Geneva. Sylvain is now a freelance consultant applying Agile,

ITIL, Archimate and Service Design best practice to companies within the Banking and

Insurance sector.

Christine RIEU, [email protected] (University of Savoie, France): works as an Associate Professor in the Listic laboratory and

has carried out research on Knowledge Management for the past 15 years. Christine teaches

Project Management at the IUT of Annecy where she also holds the position of Head of

International Relationships. . Christine is also a founding member of “PMI Pôle des Pays de

Savoie”, France Chapter.

mailto:[email protected]







www.sygit.ch Foreword

Private Banking expertise, Program & Release Manager, Senior Volunteer at PMI France Chapter

Associate Professor, Research in the Knowledge Management area, Senior Volunteer at PMI France Chapter

Agile SME & Coach, ITIL, BPMN

www.sygit.ch

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

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

Pro

ce

ss

A

Eve

nt

1E

ven

t 2

TU

1

Eve

nt

3

TU

2

Eve

nt

4

Pro

ce

ss

B

Processus Driven

SOA

Company Repository

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

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

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 !

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

www.sygit.ch

Process : Agile Iteration

Pro

ject T

eam

SC

RU

M M

aste

r S

cribe

Daily Scrum

Ceremony

Sprint Planning

Ceremony

Iteration

START

Iteration Backlog

written

Iteration Plan

Inputted

Daily Scrum

Done

Progress

Inputted

CP

U

CP

I

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

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

http://sygit.ch/sygit/Profile.html


http://www.olympic.org/

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

Previous Home

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.


Link 1

Link 2

Link 3

Good Task

Good Story

Product Backlog

Home




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 1 Story 1 Task 2 Task n

…

Non functional Requirements

Task 1 Story n Task 2 Task n

…

Previous

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.


Link 1

Link 2

Link 3

Home


Activity Summary Team Coordination Meeting


Risk impact on process Probability 10% Impact Sensible




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.


Link 1

Link 2

Link 3

Home


Activity Summary Demonstrate the product increment


Risk impact on process Probability 10% Impact Critical




www.sygit.ch Activity: Perform Retrospective Ceremony

Home


Link 1

Link 2

Link 3


Activity Summary Analyse the process, search the causes, suggest improvements



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




www.sygit.ch Activity: Adjust perimeter

Exceptions

Home


Link 1

Link 2

Link 3


Activity Summary Change the iteration backlog, in cases of major event



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.




www.sygit.ch Activity: Review the Backlog

Home


Link 1

Link 2

Link 3


Activity Summary Prepare the next iteration



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.




www.sygit.ch Activity: Perform technical review

Home


Link 1

Link 2

Link 3


Activity Summary Ensure compliance with quality standards throughout the project



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




www.sygit.ch Activity: Perform IT testing

Home


Link 1

Link 2

Link 3


Activity Summary Test the story



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




www.sygit.ch Activity: Perform functional testing

Home


Link 1

Link 2

Link 3


Activity Summary Test the Use case, and its related requirements



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




www.sygit.ch Activity: Produce the IT models

Home


Link 1

Link 2

Link 3


Activity Summary A good model is better than 100 documentation pages



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




www.sygit.ch Activity: Produce conception

Home


Link 1

Link 2

Link 3


Activity Summary Describe the "story" that exists between the models



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




www.sygit.ch Activity: Produce Analysis

Home


Link 1

Link 2

Link 3


Activity Summary Write the functional specifications



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




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

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

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

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

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

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

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

!

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

20130821 agility an_iron_fist_in_a_velvet_glove

Technology

agile technics

success agile process

savoie pmi france chapter

years of expertise

portfolio management

senior volunteer

knowledge management

field of swiss private