Post on 15-Jan-2015
description
transcript
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, marc.burlereaux@pmi-france.org (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, sylvain@sygit.ch (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, christine.rieu@univ-savoie.fr (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.
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
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.
Links to reference documents
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.
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
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
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
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.
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.
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
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
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
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
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
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
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