Role of Agile analysis in continuous delivery

2,105 views

Published on

"What does analysis mean in a Continuous Delivery environment?" This is the presentation that Danilo Sato and I used in our talk at Agile Brazil 2012, in São Paulo, Brazil.

http://submissoes.agilebrazil.com/2012/sessions/516

Published in: Technology, Business
6 Comments
11 Likes
Statistics
Notes
No Downloads
Views
Total views
2,105
On SlideShare
0
From Embeds
0
Number of Embeds
284
Actions
Shares
0
Downloads
0
Comments
6
Likes
11
Embeds 0
No embeds

No notes for slide
  • \n
  • Who we are\n
  • 2000+ across these places\n
  • English + Portuguese\n
  • Today we are going to talk about ...\n
  • CD has been predominately technical so far, and less focus on the other end of the story, where business stakeholders and product manager play a huge part in, to truly enable the entire picture. CD has a purpose that extends beyond software development and deployment. These things are here to enable business.\n
  • CD has been predominately technical so far, and less focus on the other end of the story, where business stakeholders and product manager play a huge part in, to truly enable the entire picture. CD has a purpose that extends beyond software development and deployment. These things are here to enable business.\n
  • CD has been predominately technical so far, and less focus on the other end of the story, where business stakeholders and product manager play a huge part in, to truly enable the entire picture. CD has a purpose that extends beyond software development and deployment. These things are here to enable business.\n
  • [Breeze through]\n
  • [Breeze through]\n
  • [Breeze through]\n
  • [Breeze through]\n
  • [Breeze through]\n
  • [Breeze through]\n
  • [Breeze through]\n
  • [Breeze through] Agile teams have been practised in isolation. It’s almost like being really good at launching an arrow with a bow, but not looking at whether you’ve shot the target. This isolated effort still does not meet business needs as it is still very much dependent on the last mile.\n
  • [Breeze through] Agile teams have been practised in isolation. It’s almost like being really good at launching an arrow with a bow, but not looking at whether you’ve shot the target. This isolated effort still does not meet business needs as it is still very much dependent on the last mile.\n
  • [Breeze through] Agile teams have been practised in isolation. It’s almost like being really good at launching an arrow with a bow, but not looking at whether you’ve shot the target. This isolated effort still does not meet business needs as it is still very much dependent on the last mile.\n
  • [Breeze through] Enables business stakeholders to get feedback quickly.\nRequires the engineering team to build quality from day 1.\n
  • [Breeze through] Enables business stakeholders to get feedback quickly.\nRequires the engineering team to build quality from day 1.\n
  • [Breeze through] Enables business stakeholders to get feedback quickly.\nRequires the engineering team to build quality from day 1.\n
  • [Breeze through] Enables business stakeholders to get feedback quickly.\nRequires the engineering team to build quality from day 1.\n
  • [Breeze through] Must find out quickly (shortening path of fail fast, ”fail fast-forward”), before you get a successful product.\n
  • [Breeze through] Must find out quickly (shortening path of fail fast, ”fail fast-forward”), before you get a successful product.\n
  • [Breeze through] Must find out quickly (shortening path of fail fast, ”fail fast-forward”), before you get a successful product.\n
  • [Breeze through] Must find out quickly (shortening path of fail fast, ”fail fast-forward”), before you get a successful product.\n
  • [Breeze through] Must find out quickly (shortening path of fail fast, ”fail fast-forward”), before you get a successful product.\n
  • \n
  • First introduce principles, followed by practices\n
  • Ask yourselves this question, for every feature in each release.\n
  • CD makes us think beyond just delivery working software; not losing sight of the need for said software to be useful / successful / valuable / a meaningful tool.\n
  • Monitoring 2.0. Get useful information that gets fed back to R&D. Not just monitoring for sake of monitoring.\nNot the same as management monitoring.\n
  • Example: iPad app, build metrics to test features just launched.\nShow ‘how’ in the next section.\n
  • \n
  • Within successful products.\nFlickr: picnik, World Clock\nGithub: Fork Queue, Private Message\nFacebook: Add courses to profile\n
  • Conventional way of thinking teaches us to think of complete functionality as WHOLE.\nThat incomplete is to mean not good, not finished products, missing holes.\nBorrows from manufacturing analogy; software is not a manufacturing industry.\n
  • Looking at things differently\n
  • Looking at things differently\n
  • Looking at things differently\n
  • Looking at things differently\n
  • Looking at things differently\n
  • Looking at things differently\n
  • Looking at things differently\n
  • Looking at things differently\n
  • \n
  • \n
  • \n
  • Existing ‘usage’ of MVP. Define real concept. Ask real usage of MVP again.\nDropbox example. Validate before code is written.\nLean Startup Machine story - demonstrate validation technique.\n
  • 1000s stories = wrong\nBlackhole rant\n
  • Not just forever adding features, but thinking about what you can take out as well.\n
  • \n
  • \n
  • \n
  • \n
  • The different things that analysis may include. Think of creative ways to get feedback quickly. Co-locate with team; collaborate with devs, designers, QAs, customers. Everybody.\n
  • Incorporate definition of done to the validation of features, not just released software.\n
  • \n
  • (Business cat has a message for us)\n
  • Need to be closer to business and customers to answer these questions.\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • Role of Agile analysis in continuous delivery

    1. 1. THE ROLE OF AGILE ANALYSISIN CONTINUOUS DELIVERYJenny Wong, Danilo Sato teresafranco
    2. 2. Jenny Wong @jenny_wong rockstar business analyst Danilo Sato @dtsatoDeveloper, Architect, Coach, DevOps, Trainer
    3. 3. We are hiring!join.thoughtworks.com
    4. 4. what is CD? principles of analysis & engineering practices & the role
    5. 5. WHAT IS CONTINUOUS DELIVERY?
    6. 6. development deploymentWHAT IS CONTINUOUS DELIVERY?
    7. 7. development deploymentWHAT IS CONTINUOUS DELIVERY?business &product
    8. 8. Agile breaks this tradition Smithers, we are going to build a giant domain platform to take over the world, I need you to find men to design, develop and test before we roll it out to users. Excellent...
    9. 9. Agile breaks this tradition design analysis develop test deploy
    10. 10. Agile breaks this tradition design analysis develop test deploy
    11. 11. Agile breaks this tradition design analysis develop test 24 months later deploy
    12. 12. Agile breaks this tradition design analysis develop test 24 months later deploy AAaarrrrrrrrgggghhhhhhh this isn’t what I want!! Anybody recognises this?
    13. 13. AGILE 101 “Agile” team analysis + design developmentcustomer testing + showcase iteration 0 1 2 3 4
    14. 14. AGILE 101 “Agile” team analysis + design IT operations centralised QA development QA + integration release + operationcustomer testing + showcase iteration 0 1 2 3 4
    15. 15. AGILE 101 “Agile” team analysis + design IT operations centralised QA development QA + integration release + operationcustomer testing + showcase The “Last Mile” iteration 0 1 2 3 4
    16. 16. AGILE 101 “Agile” team analysis + design IT operations centralised QA development QA + integration release + operationcustomer testing + showcase The “Last Mile” iteration 0 1 2 3 4 AAaarrrrrrrrgggghhhhhhh this is still too slow!!
    17. 17. CONTINUOUS DELIVERY customer delivery team constant flow of new features into production
    18. 18. CONTINUOUS DELIVERY customer delivery team constant flow of new features into productionSoftware always production readyBuild quality inReleases tied to business needs, not operational constraints
    19. 19. CONTINUOUS DELIVERY customer delivery team constant flow of new features into productionSoftware always production readyBuild quality inReleases tied to business needs, not operational constraints
    20. 20. The path to ... BUILD THE RIGHT THING
    21. 21. The path to ... BUILD THE RIGHT THING nobuild ? no build yes ? no build yes ? build yes ?
    22. 22. The path to ... BUILD THE RIGHT THING nobuild ? no build yes ? no build yes ? build 2 years yes ? 10 months 1 quarter MUCH shorter feedback cycle Less guesswork, cost to adapt
    23. 23. WHY CD? Build the right thing Risk reductionThe only real measure of progress
    24. 24. PRINCIPLES OFANALYSIS AND ENGINEERING
    25. 25. HOW WILL YOUR FEATURE BE TESTED? Not just QA tested How will you know whether this feature is successful?
    26. 26. THINK BEYOND WORKING SOFTWARE Used by customers, real people Generates profit Helps your employees Want customers to like you
    27. 27. SMALL, INCREMENT STEPSXP principle “What is the simplest thing that could possible work?” Blur monitoring and testing
    28. 28. CONTINUOUS PRODUCT MANAGEMENT You are not DONE when the feature is released Engineering R&D intersects product development Continuous feedback from existing features in production
    29. 29. PLAN TO RETIRE Removing features that are no longer valuable Morphing existing into newYou don’t want to maintain bloated product with stale features
    30. 30. VALUE ≠ COMPLETE-NESS
    31. 31. VALUE VS. COMPLETE-NESS
    32. 32. VALUE VS. COMPLETE-NESSDo the least to get feedback Do all that I could think of
    33. 33. VALUE VS. COMPLETE-NESSDo the least to get feedback Do all that I could think of R&D, not first release! Binary approach
    34. 34. VALUE VS. COMPLETE-NESSDo the least to get feedback Do all that I could think of R&D, not first release! Binary approachFuture is guided by feedback Do & test everything at once
    35. 35. VALUE VS. COMPLETE-NESSDo the least to get feedback Do all that I could think of R&D, not first release! Binary approachFuture is guided by feedback Do & test everything at once Innovation No research, blind development
    36. 36. VALUE VS. COMPLETE-NESSDo the least to get feedback Do all that I could think of R&D, not first release! Binary approachFuture is guided by feedback Do & test everything at once Innovation No research, blind development Step-by-step validation Assumes feature complete-ness as success criteria
    37. 37. VALUE VS. COMPLETE-NESSDo the least to get feedback Do all that I could think of R&D, not first release! Binary approachFuture is guided by feedback Do & test everything at once Innovation No research, blind development Step-by-step validation Assumes feature complete-ness as success criteria Lower costs Risks opportunity costs
    38. 38. VALUE VS. COMPLETE-NESS Do the least to get feedback Do all that I could think of R&D, not first release! Binary approach Future is guided by feedback Do & test everything at once Innovation No research, blind development Step-by-step validation Assumes feature complete-ness as success criteria Lower costs Risks opportunity costs ?W hat if I get it wrong
    39. 39. VALUE VS. COMPLETE-NESSDo the least to get feedback Do all that I could think of R&D, not first release! Binary approachFuture is guided by feedback Do & test everything at once Innovation No research, blind development Step-by-step validation Assumes feature complete-ness as success criteria Lower costs Risks opportunity costs ? W hat if I get it wrong
    40. 40. PRACTICES & THE ROLE
    41. 41. LESS IS MORERelease thin segments to testUse vertical slicing technique
    42. 42. http://bit.ly/slicing-stories
    43. 43. USE MVP WELLMVP = Minimum Viable Product
    44. 44. BACKLOG RANTStart thinking your backlog is essentially a set of assumptions You must validate assumptions
    45. 45. PRUNE, DON’T GROOM your backlog
    46. 46. FEATURE, REDEFINED functionality
    47. 47. FEATURE, REDEFINED capture functionality feedback
    48. 48. FEATURE, REDEFINED X users have clicked on Peak time usage this in the past week vs. off-peak usage capture feedback X seconds less to X% of entire online complete taskcustomer base have used this
    49. 49. BUILD TOOLS TO GATHER FEEDBACK Product level metrics Feature level metrics Dashboards
    50. 50. A DIFFERENT APPROACH User research Guerrilla testing Data analytics Collaborate, collaborate, collaborate
    51. 51. ANALYSIS, XD, ENGINEERING They all go hand-in-hand Engineering = code + test Ops too!
    52. 52. GET AWAY FROM BIG BANGBIG BANG planning• Big analysis to build big backlogs• BDUF (Big Design Up-Front)BIG BANG release• Big ta-da approach to business stakeholders
    53. 53. GET AWAY FROM BIG BANGBIG BANG planning• Big analysis to build big backlogs• BDUF (Big Design Up-Front) What is ta-da?BIG BANG release• Big ta-da approach to business stakeholders
    54. 54. PRUNE EXISTING FEATURES What features are not used? Which features do not contribute to the business value? Remove technical debt to make you go faster
    55. 55. http://bit.ly/manage-tech-debt
    56. 56. LEVERAGE FEATURE TOGGLES
    57. 57. LEVERAGE FEATURE TOGGLES Dev WIP toggle
    58. 58. LEVERAGE FEATURE TOGGLES Dev WIP toggle Ops toggle
    59. 59. LEVERAGE FEATURE TOGGLES Dev WIP toggle Ops toggle Business toggle
    60. 60. SUMMARYwhat is CD? principles of analysis & engineering practices & the role
    61. 61. Q&A Danilo Sato @dtsatoJenny Wong @jenny_wong
    62. 62. Danilo Sato @dtsatoJenny Wong @jenny_wong
    63. 63. Danilo Sato @dtsatoJenny Wong @jenny_wong

    ×