Agile at scale

2,591 views
2,457 views

Published on

http://www.blogger.com/blogger.g?blogID=6526598125676897545#editor/target=post;postID=193155394060419093;onPublishedMenu=allposts;onClosedMenu=allposts;postNum=0;src=postname

Published in: Technology
0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,591
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
38
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide
  • {"16":"Consider things from the point of view of a team member. The daily stand up meeting is followed by work that, at the end of the day, is stabilized and committed. This cyclic rhythm takes place in another rhythm of an iteration. At a still higher level, you have the cyclic rhythm of Inception, Construction, and Transition.\nRhythms are important to keep a large team in sync as well as avoiding burnout. \nSuggested reading:\nSoftware Development Rhythms: Harmonizing Agile Practices for Synergy. Kim Man Lui and Keith C. C. Chan (2008)\n","11":"See www.ambysoft.com/essays/agileLifecycle.html\nThis is the Scrum construction lifecycle. There are a lot of good ideas here, but it’s not complete.\nScrum practices:\nProduct Backlog – Prioritized stack of requirements\nValue-Driven Lifecycle – Deliver potentially shippable software each sprint\nSelf Organization – The people who do the work are the ones who plan and estimate it\nRelease Planning – Develop and then maintain a high-level project plan\nSprint Planning – At the beginning of a sprint, the team plans in detail what they will deliver and how they will do the work\nDaily Scrum Meeting – Each day, hold a 15-minute coordination meeting\nSprint Demo – At the end of the sprint demo show what you’ve built to key stakeholders\nRetrospectives – Take the opportunity to identify opportunities for improvement throughout the project.\nRoles:\nScrum Master – Team lead\nProduct Owner – Responsible for prioritizing items in the product backlog, represents the stakeholders\nTeam Member – Developers, … on the team\n","39":"Optional slide. Graphic is available in English only.\n","17":"There are several activities that occur iteratively throughout Inception:\nBuild the initial team – people build solutions\nDevelop a shared vision – what are the goals? Who are the stakeholders? What are you trying to achieve?\nInitial requirements envisioning – What is the scope?\nInitial architecture envisioning – What is the technical vision?\nSetup the environment – The team needs tools, a place to work, and other resources\nInitial high-level release planning – How long will the project take? What will be the cost?\n","6":"Active User Involvement•Small Empowered Teams•Frequent Delivery of Products•Iterative Development and Prototyping•Computer Assisted Systems Engineering (CASE)\n","1":"Author Notes:\nThis is the PowerPoint template for the Innovate 2013 Track Sessions\nThis template has been built in PowerPoint 2003. If you’re using PowerPoint 2007 or above, you may experience different usability results than what is provided as guidance here.\nTo allow all masters of your exiting presentation to be updated correctly, download this template to your hard drive and copy your existing slides into the new template using slide sorter.\nIBMers can find additional information on presentation guidelines and resources at:https://w3-connections.ibm.com/wikis/home?lang=en-us#!/wiki/Rational%20Presentation%20Templates,%20Guidelines,%20and%20Resources\nIBM Rational presenters can leverage existing brand-level assets and sparklers (including Rational Brand Messaging Slides, Client Success Slides and Client Quotes, Statistics) from SSW’s Brand Content Page:https://w3-03.sso.ibm.com/software/xl/myportal/content?synKey=R789607U42052O71\nImagery guidelines: Avoid using cartoon like clip-art, use photo-art instead. Third party material cannot be used in a presentation without written permission (this includes product and Web page screen shots, and photos). Images must be acquired from a ‘royalty-free to use’ source such as:\nMicrosoft or Lotus Symphony Clip Art library\nhttp://www.freebyte.com/clipart_images_photos_icons/#freevectorgraphics\nhttp://www.freedigitalphotos.net/\nIBMers can use royalty-free images from the following repositories:\nIBM Brand Systems Center / Assets / PhotographyLogin instructions: https://w3-connections.ibm.com/forums/html/topic?id=c1082624-e54c-4e04-bad1-ddb150ac7540\nIBM Software Story Imageshttps://w3-connections.ibm.com/files/app#/collection/b7570645-b2f8-4450-a27f-9269a163fc2d\nIBM Rational Presentation Image Library: https://w3-connections.ibm.com/wikis/home?lang=en_US#!/wiki/Rational%20Presentation%20Templates,%20Guidelines,%20and%20Resources/page/Presentation%20Image%20Library\n","40":"Mandatory closing slide (1 of 2)\nAcknowledgements and disclaimers\nIBMers must include This mandatory “Acknowledgements and Disclaimers” slide at the end of your presentation before the closing “Thank You” slide.\n- You will need to customize the “Acknowledgements and Disclaimers” text in red appropriately.\n","18":"Iterations are also referred to as time boxes and sprints (in Scrum).\nAt the beginning of the iteration the team plans what they are going to do and how they’re going to do it that iteration. This may include some modeling.\nThroughout the iteration the team does the work to address the work items for that iteration.\nToward the end of the iteration the team stabilizes the solution, ensuring that it works and is sufficiently tested. The team will also demo the solution to key stakeholders to show what they accomplished and to get feedback. They may also hold a reflection meeting, such as a retrospective, to identify potential ways to improve their process.\nThe iteration rhythm is determined by the iteration length. Fixed iteration length helps drive the reliable rhythm of a project. Without this rhythm, you are constant revising, re-estimating, and reconciling \nDiagram used with permission from the forthcoming book “Disciplined Agile Delivery (DAD): An Introduction” by Mark Lines and Scott Ambler (tentative publication date June 2011)\nAgile principle #7: Working software is the primary measure of progress. \nAgile principle #12: At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly\n","7":"http://www.ambysoft.com/surveys/success2008.html#Results\nThe Survey Results\nThe results of the survey is summarized in the article XXX published in the February XX 2009 issue of Information Week.\nSome findings include:\nAs Figure 1 depicts, iterative and agile project teams had higher success rates than traditional, which in turn had higher success rates than ad-hoc. \nPeople really don't define success in terms of "on time, on budget, to specification" regardless of what the theory folks may claim.  For example: \n83% of respondents believe that meeting actual needs of stakeholders is more important than building the system to specification. \n82% believe that delivering high quality is more important than delivering on time and on budget \n70% believe that providing the best ROI is more important than delivering under budget \n58% believe that delivering when the system is ready to be shipped is more important than delivering on schedule \nFor all the "RUP bashing" that goes on within the agile community, as Figure 1 shows iterative projects are just as successful as agile projects. \nFigure 2 depicts how iterative and agile approaches are more effective delivering higher quality, greater ROI, better stakeholder satisfaction, and deliver in a timely manner compared with traditional and ad-hoc approaches.  Traditional approaches were better than ad-hoc when it came to quality, but ad-hoc approaches were better at delivering functionality. \nFigure 3 depicts the success rate by paradigm and distribution level.  Regardless of paradigm, the more distributed the team the lower the success rates.  For any given distribution level, agile/iterative always did as good or better than traditional approaches, and traditional always did better than ad-hoc. \n","2":"Please note the following\nIBMers must include the next slide (verbatim) after your title slide.\nIBMers must also include the mandatory “Acknowledgements and Disclaimers” slide (see slide 10) at the end of your presentation before the closing “Thank You” slide.\n- You will need to customize the “Acknowledgements and Disclaimers” text in red appropriately.\n","41":"Mandatory closing slide (2 of 2)\nThank You Slide (available in English only). \n","30":"RRC\nused for requirements management\ncustom artifacts defined and implemented to support current Agile Process\ncustom templates defined and implemented to support current Agile Process (e.g. user story, Acceptance Criteria, requirements package)\nRQM\nUsed for solution validation\nProcess initiated to implement automated testing with Rational Tester for regression purposes\nTest cases linked to requirements in RRC\nRTC\nUsed for project collaboration\nHouses: \nproduct backlog\nSprint plan\nSupports reporting which is regularly reviewed by leadership\nUsed for code management using BuildForge\nUsed to run key agile ceremonies: daily scrum; retrospective\n","19":"The day starts with a short meeting to coordinate everyone’s activities.\nThe majority of the day is focused on working on the tasks.\nAt the end of the day you hopefully have a working build of the solution. You may also have working builds throughout the day as well.\nNotice that activities around picking up email, attending non-team related meetings, … aren’t included. These sorts of activities are outside the scope of a “DAD day” although clearly they still need to occur. Many DAD teams will leave enough time in the morning and at the end of day for people to deal with email. Interactions with other teams, such as reviewing their work and providing feedback, should be scheduled on an as-needed basis.\nDiagram used with permission from forthcoming book “Disciplined Agile Delivery” by Mark Lines and Scott Ambler (expected publication June 2011)\n","20":"Coordinate:\nFor teams that deploy continuously, on the order of days or a few weeks, then your construction efforts will be so disciplined that you don’t need to do much planning for this phase because you simply follow your regular procedures, many of which are likely to be automated \nCollaborate:\nThis could be a huge range of effort.\nFor continuous deployment environments, this may be virtually nothing more than doing a final build and regression test run (which in itself could run for days or weeks depending on the complexity of the solution). \nFor environments where you don’t deploy very often this often gets drawn out because you likely won’t have automated this effort and because the deployments include more functionality (thereby increasing the complexity of the deployment effort, potentially exponentially).\nConclude:\nDo light-weight review for production readiness.\nThis is one deployment step that you don’t want to automate typically, but instead someone(s) must make a conscious decision to deploy.\n","9":"Agile v. Formalised Methods×Not anti-method but ‘just enough’ method –part of general ‘lean’ movementדEverything in life should be as simple as possible but no simpler”×Many examples: SCRUM, ASD, DSDM, XP, dx, FDD, Crystal, Lean Programming, Agile Modelling, Pragmatic Programming•Value Statement Tradeoffs ×Individuals and interactions OVER processes and tools×Working software OVER comprehensive documentation×Customer collaboration OVER contract negotiation. ×Responding to change OVER following a plan•2/3 of IT companies will use agile methods within 18 months (Sliwa, 2002)\n","15":"The disciplined agile delivery lifecycle expands upon the Scrum construction lifecycle in three important ways: \nIt has explicit project phases, recognizing that agile delivery is really iterative in the small and serial in the large. \nIt includes a full range of practices. This includes initial requirements and architecture envisioning at the beginning of the project to increase the chance of building the right product in the right manner, as well as system release practices. \nIt includes more robust practices. The lifecycle of this figure explicitly reworks the product backlog in the previous slide into the more accurate concept of a ranked work item list. Not only do agile delivery teams implement functional requirements, they must also fix defects (found through independent testing or by users of existing versions in production), provide feedback on work from other teams, take training courses, and so on. \nSee www.ambysoft.com/essays/agileLifecycle.html\n"}
  • Agile at scale

    1. 1. Agile at Scale Eric Cattoir Client Technical Professional, IBM Software Group - Rational eric_cattoir@be.ibm.com © 2013 IBM Corporation
    2. 2. Please note the following IBM’s statements regarding its plans, directions, and intent are subject to change or withdrawal without notice at IBM’s sole discretion. Information regarding potential future products is intended to outline our general product direction and it should not be relied on in making a purchasing decision. The information mentioned regarding potential future products is not a commitment, promise, or legal obligation to deliver any material, code or functionality. Information about potential future products may not be incorporated into any contract. The development, release, and timing of any future features or functionality described for our products remains at our sole discretion. Performance is based on measurements and projections using standard IBM benchmarks in a controlled environment. The actual throughput or performance that any user will experience will vary depending upon many factors, including considerations such as the amount of multiprogramming in the user’s job stream, the I/O configuration, the storage configuration, and the workload processed. Therefore, no assurance can be given that an individual user will achieve results similar to those stated here. 2
    3. 3. Agenda  Agile Development  Typical Agile Methods  Extended Agile Frameworks –Disciplined Agile Development –Agile at Scale –Scaling Agile Framework  Supporting Agile at Scale with Rational Tools  Conclusion 3
    4. 4. Agenda  Agile Development  Typical Agile Methods  Extended Agile Frameworks –Disciplined Agile Development –Agile at Scale –Scaling Agile Framework  Supporting Agile at Scale with Rational Tools  Conclusion 4
    5. 5. What Agile is NOT !!
    6. 6. What is Agile Software Development? Principles driving Agile adoption  Individuals and Interactions over processes and tools  Working software over comprehensive documentation  Customer collaboration over contract negotiation  Responding to change over following a plan www.agilemanifesto.org 6
    7. 7. Why are Organizations moving to Agile? Project success rates are up Iterative More effective at delivering higher quality software Quality 2.3 0.4 Agile Traditiona l Ad-Hoc Functionality Money Time 1.8 0.2 4.9 5.0 6.0 5.6 2.7 3.0 3.9 0.8 0.8 0.8 4.4 4.0 Agile Iterative Traditiona l Ad-Hoc Bottom Line: Agile teams produce higher quality work, are quicker to deliver, are more likely to deliver the right functionality, and more likely to provide greater ROI than traditional teams Source: Dr Dobb’s 2008 Project Success Survey, http://www.ambysoft.com/surveys/success2008.html#Results 7
    8. 8. Agenda  Agile Development  Typical Agile Methods  Extended Agile Frameworks –Disciplined Agile Development –Agile at Scale –Scaling Agile Framework  Supporting Agile at Scale with Rational Tools  Conclusion 8
    9. 9. Agile Methodologies  Are approaches used by software teams to coordinate their activities and how they work together (e.g. software processes)  Are approaches used by software teams to coordinate their activities and how they work together (e.g. software processes)  Stress continuous customer feedback used to refine and deliver software  Stress continuous customer feedback used to refine and deliver software  Share common principles, see Agile Manifesto, but use different practices  Typically use the iterative and incremental software development practice  Typically use the iterative and incremental software development practice Some Common Agile Methodologies  Lean Development (LD)  Scrum  eXtreme Programming (XP)  Evolutionary Project Management (Evo)  Test Driven Development  User Story Driven Development  Crystal  RUP - Rational Unified Process  ASD - Adaptive Software Development  DSDM - Dynamic System Development Method  FDD - Feature Driven Development 9
    10. 10. Agile Practices Scrum Lifecycle Practices: Roles: Product Backlog Scrum Master Value-Driven Life Cycle Product Owner, Team Member Self Organization Release Planning Sprint Planning Daily Scrum Meeting Sprint Demo Retrospectives
    11. 11. The Scrum construction lifecycle Project Initiation? Project Selection? Technical Practices? Release into Production? Enterprise Disciplines? Operate in Production?
    12. 12. Agenda  Agile Development  Typical Agile Methods  Extended Agile Frameworks –Disciplined Agile Development –Agile at Scale –Scaling Agile Framework  Supporting Agile at Scale with Rational Tools  Conclusion 12
    13. 13. Problems of Scaling  SoS – Scrum Of Scrums – Becomes more difficult after 6 or so Teams – Planning & Ceremonial Events conflict  Doesn’t really address a Portfolio & Program View – Still thinks of smaller “projects” – Planning Roadmap horizons are still short  Fails to recognize that Waterfall still exists  Governance & Authority start to fail – No Clear Content Authority once you scale to a Program or Portfolio level – Who resolves priorities across dozens of teams? – Who then drives releases?  Reporting & Metrics aren’t sufficient across large numbers of teams or programs  Traditional sources of information (Scrum/Agile Alliance) aren’t mature to help this – Note: In Jan ‘2013 Ken Schwaber introduced CIF –Continuous Improvement Framework 13
    14. 14. What Should a Scaled Framework Address?  Multiple Agile Teams – Should be able to handle dozens of teams (Scrum starts to break around 7) – Incorporation of XP Engineering practices  Waterfall Teams – They still exist. Not everything can be Agile  Program Level planning and views  Governance and shared resources (like Enterprise/System Architects, UX, etc.)  Specialized teams for Release planning, system integration  Clear content authority  Portfolio Management and the management of WIP
    15. 15. The Disciplined Agile Lifecycle: An extension of Scrum
    16. 16. Concept: The Agile 3C rhythm The coordinate-collaborate-conclude rhythm occurs at several scales on a DAD project: Daily rhythm Transition Collaborate Conclude Iteration Planning Development Stabilize Coordinate Iteration rhythm Construction Coordinate Release rhythm Inception Collaborate Conclude Coordination Meeting Daily work Stabilize Coordinate Collaborate Conclude
    17. 17. The Inception Phase
    18. 18. Typical Construction Iteration
    19. 19. Typical day during construction
    20. 20. The Transition phase
    21. 21. Agile Scaling Factors * Slide Courtesy of IBM 21
    22. 22. Disciplined Agile Delivery (DAD) is the Foundation for Agile at Scale Compliance Domain Complexity Technical Complexity Geographic Distribution Team Size Organizational Distribution Outside In Dev. SAFe XP Scrum And more… Agile Modeling Kanban Lean Disciplined Agile Delivery (DAD) DAD leverages proven strategies from several sources providing a decision framework to guide your adoption and tailoring in a context-driven manner.
    23. 23. Scaled Agile Framework
    24. 24. Roots of the Scaled Agile Framework
    25. 25. Scaled Agile Framework – Big Picture
    26. 26. Agile Teams
    27. 27. Scale to Program Level
    28. 28. Scale to Portfolio
    29. 29. Agenda  Agile Development  Typical Agile Methods  Extended Agile Frameworks –Disciplined Agile Development –Agile at Scale –Scaling Agile Framework  Supporting Agile at Scale with Rational Tools  Conclusion 29
    30. 30. Rational tooling to support Agile Collections linked to Stories Requirements Management • User Stories and AC linked to support coverage and impact analysis • Rqts. Comm. / sign-off • Custom artifacts and templates implemented to support Agile Process Rational Rqts. Composer Rational Team Concert • Defects linked to Test Cases Jazz Platform AC linked to Test Cases Tool integration supports end-to-end Tool integration supports end-to-end Tool integration supports end-to-end traceability. traceability. traceability. 30 • • • Work Items & Collaboration Agile backlogs Tasks to track work effort Agile dashboards for executive reporting Code management via BuildForge Quality Management • Test Plans • Test Cases • Evaluating Rational Tester for regression automation Rational Quality Manager
    31. 31. Process Templates – Out of the Box There are a number of process templates that come out of the box with RTC v4.x: •Cloudburst Sample Process •Formal Project Management •OpenUP Process •Scrum •Simple Team Process •Unconfigured Process Other process templates: •Disciplined Agile Delivery •SAFe Portfolio •SAFe Program 31 Process Template Extract Create Project
    32. 32. DAD Timeline 32
    33. 33. DAD Work Item Types 33
    34. 34. SAFe Template for RTC  RTC already has Scrum & Kanban process templates but it didn’t have one for SAFe  New workitem types needed to be created: – Feature – Theme – Risk & Risk Action  New Roles and Security – Product Manager – Release Train Engineer (Conductor)  Specialized Virtual Teams – System Team – Release Management – Architecture & UX 34
    35. 35. SAFe Portfolio (RTC Process Template) Roles Timeline 35 Teams Work Item Types Categories
    36. 36. Solution outline for Outsourced Software Delivery Governance Built on a core solution set; augmented with IBM Best Practices PORTFOLIO STRATEGY and MANAGEMENT Develop outsourcing strategy and consolidate organizational demand to prioritize capability needs REQUIREMENTS MANAGEMENT Translate Business Needs into Actionable SW Requirements, driving SOW agreements QUALITY MANAGEMENT Achieve “quality by design” with integrated user acceptance testing, facilitating customer sign-off COLLABORATION, PLANNING & CHANGE MANAGEMENT Collaborate across geographically distributed software development suppliers using common planning and scheduling PERFORMANCE REPORTING and ANALYSIS Automated, transparent collection of role-based dashboards to drive SLA and Supplier performance reporting and analysis across the SW Supply Chain 36 Open Services for Lifecycle Collaboration Integration Strategy
    37. 37. Solution Overview – Extended Solution Team Concert Focal Point Business Needs >> Plan Items Demand management Portfolio decisions Work order tracking Project, portfolio, supplier metrcs Link to Release Plan Release and iteration planning Plan item / story implementation tracking Detailed metrics System Architect Architectural & impact analysis Schedule and status Rational Insight Link to Test Plan Business Needs >> Collections Enterprise reporting Reqts and Stories Reqt details and estimates Stories and Tests Rational Publishing Engine Published reports Requirements Composer Quality Manager Business need elaboration Requirements collaboration Acceptance criteria definition Acceptance test planning and execution Detailed metrics Reqts and Tests Rational Test Workbench Test automation and virtualization
    38. 38. Agenda  Agile Development  Typical Agile Methods  Extended Agile Frameworks –Disciplined Agile Development –Agile at Scale –Scaling Agile Framework  Supporting Agile at Scale with Rational Tools  Conclusion 38
    39. 39. 39
    40. 40. Acknowledgements and disclaimers Availability: References in this presentation to IBM products, programs, or services do not imply that they will be available in all countries in which IBM operates. The workshops, sessions and materials have been prepared by IBM or the session speakers and reflect their own views. They are provided for informational purposes only, and are neither intended to, nor shall have the effect of being, legal or other guidance or advice to any participant. While efforts were made to verify the completeness and accuracy of the information contained in this presentation, it is provided AS-IS without warranty of any kind, express or implied. IBM shall not be responsible for any damages arising out of the use of, or otherwise related to, this presentation or any other materials. Nothing contained in this presentation is intended to, nor shall have the effect of, creating any warranties or representations from IBM or its suppliers or licensors, or altering the terms and conditions of the applicable license agreement governing the use of IBM software. All customer examples described are presented as illustrations of how those customers have used IBM products and the results they may have achieved. Actual environmental costs and performance characteristics may vary by customer. Nothing contained in these materials is intended to, nor shall have the effect of, stating or implying that any activities undertaken by you will result in any specific sales, revenue growth or other results. © Copyright IBM Corporation 2013. All rights reserved. – U.S. Government Users Restricted Rights - Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp. IBM, the IBM logo, ibm.com, Rational, the Rational logo, Telelogic, the Telelogic logo, Green Hat, the Green Hat logo, and other IBM products and services are trademarks or registered trademarks of International Business Machines Corporation in the United States, other countries, or both. If these and other IBM trademarked terms are marked on their first occurrence in this information with a trademark symbol (® or ™), these symbols indicate U.S. registered or common law trademarks owned by IBM at the time this information was published. Such trademarks may also be registered or common law trademarks in other countries. A current list of IBM trademarks is available on the Web at “Copyright and trademark information” at www.ibm.com/legal/copytrade.shtml If you have mentioned trademarks that are not from IBM, please update and add the following lines: [Insert any special third-party trademark names/attributions here] Other company, product, or service names may be trademarks or service marks of others. 40
    41. 41. © Copyright IBM Corporation 2013. All rights reserved. The information contained in these materials is provided for informational purposes only, and is provided AS IS without warranty of any kind, express or implied. IBM shall not be responsible for any damages arising out of the use of, or otherwise related to, these materials. Nothing contained in these materials is intended to, nor shall have the effect of, creating any warranties or representations from IBM or its suppliers or licensors, or altering the terms and conditions of the applicable license agreement governing the use of IBM software. References in these materials to IBM products, programs, or services do not imply that they will be available in all countries in which IBM operates. Product release dates and/or capabilities referenced in these materials may change at any time at IBM’s sole discretion based on market opportunities or other factors, and are not intended to be a commitment to future product or feature availability in any way. IBM, the IBM logo, Rational, the Rational logo, Telelogic, the Telelogic logo, and other IBM products and services are trademarks of the International Business Machines Corporation, in the United States, other countries or both. Other company, product, or service names may be trademarks or service marks of others. 41

    ×