Your SlideShare is downloading. ×
20130821 agility an_iron_fist_in_a_velvet_glove
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.

Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

20130821 agility an_iron_fist_in_a_velvet_glove


Published on

Published in: Technology, Business
  • Be the first to comment

  • Be the first to like this

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide


  • 1. Be Agile when implementing Agility Be Wagile for a smooth Delivery Agility : An Iron Fist in a Velvet Glove
  • 2. Authors Marc BURLEREAUX, (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, (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, (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.
  • 3. 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
  • 4. 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
  • 5. 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
  • 6. 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
  • 7. 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
  • 8. 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 !
  • 9. 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
  • 10. 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
  • 11. 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
  • 12. 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
  • 13. 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
  • 14. 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
  • 15. 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
  • 16. 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
  • 17. 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
  • 18. 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.
  • 19. 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.
  • 20. 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
  • 21. 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
  • 22. 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
  • 23. 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
  • 24. 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
  • 25. 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
  • 26. 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
  • 27. 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
  • 28.  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
  • 29.  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
  • 30.  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
  • 31.  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
  • 32. 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 !
  • 33. 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