Evolution of Longer-Term Planning in a Large Scale Agile Project – F-Secure’s experience
Upcoming SlideShare
Loading in...5
×
 

Evolution of Longer-Term Planning in a Large Scale Agile Project – F-Secure’s experience

on

  • 770 views

Presentation at XP2011 in Madrid

Presentation at XP2011 in Madrid

Statistics

Views

Total Views
770
Views on SlideShare
770
Embed Views
0

Actions

Likes
0
Downloads
12
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Evolution of Longer-Term Planning in a Large Scale Agile Project – F-Secure’s experience Evolution of Longer-Term Planning in a Large Scale Agile Project – F-Secure’s experience Presentation Transcript

  • Evolution of Longer-Term Planning in a Large Scale AgileProject – F-Secure’s experienceGabor Gunyho & Juan GutierrezImprovement Coach Manager, Agile Practices2011-05-09Protecting the irreplaceable | f-secure.com
  • What is this presentation all about?• Many publications in the SW development literature offer ready-made “recipes” for solving a certain problem• We believe this is way too often not helpful as the context varies a lot Text source: http://easteuropeanfood.about.com/od/hungariansoups/r/gulyasleves.htm2 2011-05-09 © F-Secure Public
  • What is this presentation all about?• Instead we offer a story. This is how we did it in a big project.• The story is told through the projects major events called “Release Planning”• We hope that you‟ll learn some ideas on project planning and steering on a larger scale … even if it does not offer a ready-made recipe Image source: http://lorabetht.blogspot.com/2010/11/violence-and-sophocles-antigone.html3 2011-05-09 © F-Secure Public
  • About F-Secure• Company • Founded in 1988, listed on NASDAQ OMX Helsinki • Market cap ca 350 m€, annual revenue ca 130 m€ (2010) • Headquartered in Helsinki, 18 country offices, presence in more than 100 countries • 850 people, 300+ in R&D, 5 R&D offices in 4 countries, Agile since 2003-2005• Products and Services • Online Security: Anti-Malware, e-mail filter, Browsing Protection, Parental Control • Content Protection: Online Backup, Anti-Theft • Online Storage and Services: Storage Platform, Sharing, Social Media Access • Multiple OS platforms (Win, Mac, Linux, mobile), 20+ language versions• Customers • Consumers (retail, reseller, e-store), millions of homes • Network operators (ISP, mobile), world leader with 200+ operator partners • Corporate4 2011-05-09 © F-Secure Public
  • About the Authors Gabor Gunyho, Juan Gutierrez Plaza Improvement Coach with the “R&D Currently „Agile Practices Manager‟ at F- Global Methods” team at F-Secure, Secure‟s Storage & Digital Content unit, experienced Agile and Lean product focusing on the R&D transformation of the site. development expert, contributor and Experienced coach who has helped different reviewer of books on scaling Agile and teams to improve in engineering and process Lean SW development practices. Active member in different agile forums and member of the board of Agile Spain5 2011-05-09 © F-Secure Public
  • About the project• Major new product, significant changes in • Business model • Architecture • Method for Longer-Term Planning, including new backlog tooling• About 10 teams • Mostly in Helsinki, some in Kuala Lumpur, later also one in Poland • Mostly feature teams • Fairly mature in basic Scrum [1] and Agile engineering practices • Some experience in multi-team projects [2] [3] but not on this scale6 2011-05-09 © F-Secure Public
  • Longer-Term Planning: Why?“We need to improve the way how we manage our requirements, and especiallyhow we create concept (release) plans and link longer term architecture into ourshort term plans“ Pirkka Palomäki, CTO• Plan for developing a complex system with lots of unknowns and lots of dependencies, both in features and in architecture• Provide estimates and visibility to progress on a higher level of abstraction of the content and timeline• Handle the inherent organizational complexity in multi-team setup We need to get alignment in teams to a common objective7 2011-05-09 © F-Secure Public
  • Longer-Term Planning in brief – the context• Basic, Scrum-based Agile methodology does not cover scaling [1]• Dean Leffingwell„s “Agile Release Train” [4] [5] covers multiple layers of abstraction in all key dimensions of the project: content, timeline and organization. Product Backlog Product Product Epic Feature Story Owner 1 Owner 2 Epic Reporting Aggregate Reports As an user I want to see a list of my average spending for each of my budget-lines so that I Team B Team A can get a fast control of my average expenses Reporting Aggregate As a end-user I can get a summary report my Story Feature Reports total spending on a selected set of accounts Reporting List Report As a end-user I can get a summary report my total spending on a selected set of accounts Reporting List Report As a end-user I can get a summary report my total spending on a selected set of accounts Logging ... Beta1 Business Iteration Beta2 Release B B B I I1 I2 I3 I4 I I5 I6 I7 I8 I I9 I10 I11 I12 P P P BIP = Business Iteration Planning8 2011-05-09 © F-Secure Public
  • Longer-Term Planning in brief – the event Day 1 Day 2 Introduction Status check Project setup Planning Business Vision team breakout sessions AM AM Architecture Vision User experience and UI Engineering practices Planning process intro Final plan review Planning Risk review team breakout sessions Confidence vote PM PM Draft Plan review Retrospective9 2011-05-09 © F-Secure Public
  • The outcome: Plans vs. PlanningPlans are of little importance, but planning is essential – Winston ChurchillPlans are nothing; planning is everything – Dwight D. EisenhowerNo battle plan survives contact with the enemy – Helmuth von Moltke the ElderA good plan, violently executed now, is better than a perfect plan next week – George S. Patton Source: http://en.wikipedia.org/wiki/Plan10 2011-05-09 © F-Secure Public
  • The project journey – from theLonger-Term Planning perspective11 2011-05-09 © F-Secure Public
  • P Biz Iteration #1 Dec Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec Jan Feb Mar 2010 2011New Method for the New Project• New planning method: “Agile Release Train”• Project kick-off and first “Release Planning” event: December 2009• Planning Scope = 90 days • 6 sprints, 2 weeks each, plus next planning• Program for the "release” planning event • One day training on Scaling SW agility • “Release” Planning: 2 days +1 day reserve (that had to be used after all)• Attendants: ~120, including all functions (R&D, Product Mgmt, business, etc) • Everybody (almost) in one space• Facilitator: Dean Leffingwell, supported by internal improvement coaches12 2011-05-09 © F-Secure Public
  • 1 2 3 P Biz Iteration #1 P Dec Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec Jan Feb Mar 2010 2011Learning from the Business Iteration #1• Beta releases: 2 internal (though delayed), 1 failed• Huge amount of content becomes apparent, many dependencies and risks• Feature vs. story concept is not clear to many• Planning event can be done in 2 days (keep a 3rd day in reserve though)• The 90-day “Business Iteration” with mid-term re-planning is not meaningful • Change the cadence to 8-week Business Iterations with proper planning for each• Changes in the planning process: • Internal event facilitator takes over from external guru • Moving towards continuous “Flow” in planning e.g., “Draft plan review” scrapped, instead, synchronize planning work of teams in every hour • Special-skill experts (business, architecture, UX, etc) available throughout the event13 2011-05-09 © F-Secure Public
  • 1 2 3 P Biz Iteration #1 P Biz Itrtn #2 Dec Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec Jan Feb Mar 2010 2011Planning event #2 (End of March 2010)• Preceded by a ½ day retrospective done with Open Space [6]• Slow feedback in development• Improve Build System, Test Automation and reduce release effort• “Release” Planning fixes: focus on dependencies, limit sprint load to team‟s capacity• Architecture challenges: different levels of abstraction needed, establish virtual team for architects• Changes for “Release” Planning event #2 • Imbalance between scope and velocity recognized and acknowledged • Change project setup: Full system release June 2010 -> Variant-A release by Aug (+2 months), Variant-B by Dec (+ 6 months) • Plan for releasing a beta (for customer preview) in every sprint14 2011-05-09 © F-Secure Public
  • 1 2 3 4 5 6 7 P Biz Iteration #1 P Biz Itrtn #2 P Biz Iteration #3 Dec Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec Jan Feb Mar 2010 2011Planning event #3 (early June 2010)• Beta releases: 2 of 4 successful“Based on R&D analysis of project scope and schedule it is apparent that the current roadmap is not feasible” Project split • Spin off “mini-project” for downscaled Variant-A • Variant-B development continues, with staged delivery, Variant-B basic release Oct 2010, full set release Jan 2011• Changes in the planning process • At every hour synchronization meetings alternate, one for the planning work and another for architecture issues • Helpers for planning the improvement items rotate in teams • Risk, impediment and dependency handling in short cycles (along with the synch meetings), and not at the end of the planning event • “Feature wall “ (or “master wall”) to depict which feature will be done by whom and when, also visualizing dependencies15 2011-05-09 © F-Secure Public
  • 1 2 3 4 5 6 7 P Biz Iteration #1 P Biz Itrtn #2 P Biz Iteration #3 Dec Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec Jan Feb Mar 2010 2011Example of a Master Wall • Master wall that shows which team works on which feature in which iteration • List of identified risks and impediments • ROAMed - Resolved, Owned, Accepted, Mitigated16 2011-05-09 © F-Secure Public
  • 1 2 3 4 5 6 7 13 14 15 16 17 18 P Biz Iteration #1 P Biz Itrtn #2 P Biz Iteration #3 P Biz Iteration #4 Dec Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec Jan Feb Mar 2010 2011Planning event #4 (early Sept 2010)• Beta releases: 3 of 6 successful• Full-time ScrumMasters for each team• Event delayed by 1 week, time used for • hardening (bug killing) • re-teaming event: moving towards more feature teams • ScrumMaster training• Changes in the planning process • Separate intro briefing session, including solution demo • All input in physical tokens (all features printed) • Improved master wall, physical visualization of dependencies • Clear priorities for planning: “honesty over precision” • Smoother planning in general17 2011-05-09 © F-Secure Public
  • 1 2 3 4 5 6 7 13 14 15 16 17 18 P Biz Iteration #1 P Biz Itrtn #2 P Biz Iteration #3 P Biz Iteration #4 Dec Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec Jan Feb Mar 2010 2011Planning event #4 - memories18 2011-05-09 © F-Secure Public
  • 18.5 1 2 3 4 5 6 7 13 14 15 16 17 18 19 20 21 22 23 P Biz Iteration #1 P Biz Itrtn #2 P Biz Iteration #3 P Biz Iteration #4 P “Last mile” Dec Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec Jan Feb Mar 2010 2011Planning event #5 (early Dec 2010)• Beta releases: 3 of 5 successful• 1st public beta release• “Last mile” before release• Company restructuring BI #1 Nr of features• Feature leaks (slipping content) BI #2 Planned Last-minute change in the planning process BI #3 Done“We believe the last mile before release is BI #4 better executed with feature focused planning.”• Changes in the planning process • New internal event facilitator • New “feature planning” (see next) • More emphasis in backlog grooming within sprints and Product Backlog preparation by Product Owners • Release when last good build is deemed by Product Owners as good to go Business Iteration (BI) Planning method is not abandoned, it’s just not applied for the last mile of the project19 2011-05-09 © F-Secure Public
  • 18.5 1 2 3 4 5 6 7 13 14 15 16 17 18 19 20 21 22 23 P Biz Iteration #1 P Biz Itrtn #2 P Biz Iteration #3 P Biz Iteration #4 P “Last mile” Dec Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec Jan Feb Mar 2010 2011 Feature Planning for the “last mile” before release Beta(n) Beta(n+1) Beta(n+2) Beta(n+3) Beta(n+4) Beta(n+5) Beta releases (public) I(n) I(n+1) I(n+2) I(n+3) I(n+4) I(n+5) Iterations Develop Develop Develop Feature A Feature D Feature E Backlog groomingTeam is about:X - User needs and requirements - Architecture Grooming for Feature D Grooming for Feature E - Dependencies - UX Develop Develop Develop - Risks of the next feature Feature B Feature C Feature FTeamY Features prepared or refined by Grooming for Feature C Grooming for Feature F Product OwnersProduct in Product BacklogOwners, regularlyetc 20 2011-05-09 © F-Secure Public
  • 18.5 1 2 3 4 5 6 7 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 P Biz Iteration #1 P Biz Itrtn #2 P Biz Iteration #3 P Biz Iteration #4 P “Last mile” Dec Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec Jan Feb Mar 2010 2011Towards the end of the project• As of mid-Feb, 2011 for the first time the burndown shows that the remaining work can be done by the planned release date Note: data on picture was adjusted for work in progress items not reflected on picture when the above conclusion was made21 2011-05-09 © F-Secure Public
  • 18.5 1 2 3 4 5 6 7 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 P Biz Iteration #1 P Biz Itrtn #2 P Biz Iteration #3 P Biz Iteration #4 P “Last mile” Dec Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec Jan Feb Mar 2010 2011… and at the end of the project• As of March 30, 2011 CR1 (Commercial Release #1) was released22 2011-05-09 © F-Secure Public
  • Summary of the method• New method for handling layers of abstraction in all key dimensions • Business Iteration for steering in mid-term time scale • Levels of abstraction in the “Value item” hierarchy: epics, features, stories • Planning for the Business Iteration with the features and stories in a multi- team setting• Essential to pay attention to quality and the engineering practices like Continuous Integration and Test Automation • Never sacrifice quality, never • Every bug found invokes adding a new test case to the Test Automation suite • No extra hardening outside of sprints, every sprint results in a customer beta23 2011-05-09 © F-Secure Public
  • Conclusions - the morale of the story Better visibility and steerability for business management, helping making tough decisions• Inspect and adapt, ie, evolve the method as you go • Get real feedback after almost every sprint, even if product is big • Get help from an experienced “process master”, ie, event facilitator • Prepare the content well and do it continuously, don‟t overload the system • Synchronization meetings within the planning, later extended to continuous handling of risks, dependencies and impediments • Presence of all stakeholders (business, architects, user experience) • Master wall and feature coverage tracking • Move to “feature planning”, a precursor to continuous planning24 2011-05-09 © F-Secure Public
  • References[1] Schwaber, K., Beedle, M.: Agile Software Development with Scrum. Prentice Hall (2001)[2] Larman, C., Vodde, B.: Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum. Addison-Wesley Professional (2008)[3] Larman, C., Vodde, B.: Practices for Scaling Lean & Agile Development: Large, Multisite, and Offshore Product Development with Large-Scale Scrum. Addison-Wesley Professional (2010)[4] Leffingwell, D.: Scaling Software Agility: Best Practices for Large Enterprises. Addison-Wesley Professional (2007)[5] Leffingwell, D.: Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley Professional (2011)[6] http://en.wikipedia.org/wiki/Open_Space_Technology25 2011-05-09 © F-Secure Public
  • Questions?26 2011-05-09 © F-Secure Public
  • Contact Informationgabor.gunyho@f-secure.comjuan.gutierrez@f-secure.com http://creativecommons.org/licenses/by-nd/3.0/This presentation, and the project behind it are the work of many people whom all we can‟t possibly list here.We‟d like to thank all who made this possible, most notable the whole team of this project.Special thanks to F-Secure‟s R&D Management for supporting the work and this presentationThe authors did their best to attribute the authors of texts and images, and to recognize any copyrights, see moredetails of copyrights, license terms and conditions for each source under the reference link provided. If you thinkthat anything in this material should be changed, added or removed, please contact the authors at the addressesabove27 2011-05-09 © F-Secure Public
  • Background slides(actual fact sheets)29 2011-05-09 © F-Secure Public
  • Schedule look before planning event #1.5 (re-plan) Week Iteration Comments 50 7.12. Iteration 1 Schedule 51 18.12. 100% 52 21.12. Iteration 2 30.6. 53 1.1. 1 4.1. Iteration 3 2 15.1. 3 18.1. Iteration 4 PSI-1 re-planning End-to-end testable ∼60% of 4 29.1. beta-1 internal (LAB) release PSI-1 5 1.2. Iteration 5 6 12.2. beta-1 (12.2.2010) 7 15.2. Iteration 6 29.1. 8 26.2. beta-2 (26.2.2010) 25 9 1.3. Iteration 7 % 10 12.3. beta-3 & PSI-1 (12.3.2010) 7.12. 11 15.3. Release-retrospective & PSI2 planning 12 19.3. PSI-2 iterations begin… PSI = Potentially Shippable Increment, earlier term for Business Iteration30 2011-05-09 © F-Secure Public
  • Scoping before planning #2• Number of features before planning #2 Mandatory Variant-A Important Common Variant-B Nice to have31 2011-05-09 © F-Secure Public
  • Schedule and scope adjustment before planning #2 Var-A Original Var-B RTM PSI planning PSI planningPSI planning PSI planning PSI planning PSI-1 PSI-2 PSI-3 PSI-4 PSI-5 PSI-6                       Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec Jan 2010 2011 Planning for this now Var-A Var-B Current approved RTM RTM +2 months +6 months PSI = Potentially Shippable Increment, earlier term for Business Iteration RTM = Release to Manufacturing 32 2011-05-09 © F-Secure Public
  • Trade-off matrix for Variant-A as of planning #2PERFORMANCE of the back-end Improve Keep SacrificePERFORMANCE of the client Improve Keep SacrificeUSER EXPERIENCE Improve Keep SacrificeUSABILITY Improve Keep SacrificeBUSINESS support for F-Secure Improve Keep SacrificeSECURITY Improve Keep SacrificeFEATURE SET of the client Improve Keep SacrificeFEATURE SET of the back-end Improve Keep SacrificeINTEROPERABILITY Improve Keep SacrificeRELIABILITY Improve Keep SacrificeSUPPORTABILITY Improve Keep SacrificeTESTABILITY in R&D Improve Keep Sacrifice Legend: Comparing to our client & backend offer of August 2009 • IMPROVE this area • KEEP this area roughly equally good • SACRIFICE things in this area to succeed in others33 2011-05-09 © F-Secure Public
  • Trade-off matrix for Variant-B as of planning #3PERFORMANCE of the client Improve Keep SacrificeUSER EXPERIENCE Improve Keep SacrificeUSABILITY Improve Keep SacrificeBUSINESS support for F-Secure Improve Keep SacrificeSECURITY Improve Keep SacrificeFEATURE SET of the client Improve Keep SacrificeFEATURE SET of the back-end Improve Keep SacrificeINTEROPERABILITY Improve Keep SacrificeRELIABILITY Improve Keep SacrificeSUPPORTABILITY Improve Keep SacrificeTESTABILITY in R&D Improve Keep Sacrifice Legend: Comparing to our client & backend offer of August 2009 • IMPROVE this area • KEEP this area roughly equally good • SACRIFICE things in this area to succeed in others34 2011-05-09 © F-Secure Public