Your SlideShare is downloading. ×
Role of Agile analysis in continuous delivery
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Role of Agile analysis in continuous delivery

1,394
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, …

"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
10 Likes
Statistics
Notes
No Downloads
Views
Total Views
1,394
On Slideshare
0
From Embeds
0
Number of Embeds
7
Actions
Shares
0
Downloads
0
Comments
6
Likes
10
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
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
  • Transcript

    • 1. THE ROLE OF AGILE ANALYSISIN CONTINUOUS DELIVERYJenny Wong, Danilo Sato teresafranco
    • 2. Jenny Wong @jenny_wong rockstar business analyst Danilo Sato @dtsatoDeveloper, Architect, Coach, DevOps, Trainer
    • 3. We are hiring!join.thoughtworks.com
    • 4. what is CD? principles of analysis & engineering practices & the role
    • 5. WHAT IS CONTINUOUS DELIVERY?
    • 6. development deploymentWHAT IS CONTINUOUS DELIVERY?
    • 7. development deploymentWHAT IS CONTINUOUS DELIVERY?business &product
    • 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. Agile breaks this tradition design analysis develop test deploy
    • 10. Agile breaks this tradition design analysis develop test deploy
    • 11. Agile breaks this tradition design analysis develop test 24 months later deploy
    • 12. Agile breaks this tradition design analysis develop test 24 months later deploy AAaarrrrrrrrgggghhhhhhh this isn’t what I want!! Anybody recognises this?
    • 13. AGILE 101 “Agile” team analysis + design developmentcustomer testing + showcase iteration 0 1 2 3 4
    • 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. 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. 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. CONTINUOUS DELIVERY customer delivery team constant flow of new features into production
    • 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. 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. The path to ... BUILD THE RIGHT THING
    • 21. The path to ... BUILD THE RIGHT THING nobuild ? no build yes ? no build yes ? build yes ?
    • 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. WHY CD? Build the right thing Risk reductionThe only real measure of progress
    • 24. PRINCIPLES OFANALYSIS AND ENGINEERING
    • 25. HOW WILL YOUR FEATURE BE TESTED? Not just QA tested How will you know whether this feature is successful?
    • 26. THINK BEYOND WORKING SOFTWARE Used by customers, real people Generates profit Helps your employees Want customers to like you
    • 27. SMALL, INCREMENT STEPSXP principle “What is the simplest thing that could possible work?” Blur monitoring and testing
    • 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. 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. VALUE ≠ COMPLETE-NESS
    • 31. VALUE VS. COMPLETE-NESS
    • 32. VALUE VS. COMPLETE-NESSDo the least to get feedback Do all that I could think of
    • 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. 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. 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. 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. 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. 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. 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. PRACTICES & THE ROLE
    • 41. LESS IS MORERelease thin segments to testUse vertical slicing technique
    • 42. http://bit.ly/slicing-stories
    • 43. USE MVP WELLMVP = Minimum Viable Product
    • 44. BACKLOG RANTStart thinking your backlog is essentially a set of assumptions You must validate assumptions
    • 45. PRUNE, DON’T GROOM your backlog
    • 46. FEATURE, REDEFINED functionality
    • 47. FEATURE, REDEFINED capture functionality feedback
    • 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. BUILD TOOLS TO GATHER FEEDBACK Product level metrics Feature level metrics Dashboards
    • 50. A DIFFERENT APPROACH User research Guerrilla testing Data analytics Collaborate, collaborate, collaborate
    • 51. ANALYSIS, XD, ENGINEERING They all go hand-in-hand Engineering = code + test Ops too!
    • 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. 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. 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. http://bit.ly/manage-tech-debt
    • 56. LEVERAGE FEATURE TOGGLES
    • 57. LEVERAGE FEATURE TOGGLES Dev WIP toggle
    • 58. LEVERAGE FEATURE TOGGLES Dev WIP toggle Ops toggle
    • 59. LEVERAGE FEATURE TOGGLES Dev WIP toggle Ops toggle Business toggle
    • 60. SUMMARYwhat is CD? principles of analysis & engineering practices & the role
    • 61. Q&A Danilo Sato @dtsatoJenny Wong @jenny_wong
    • 62. Danilo Sato @dtsatoJenny Wong @jenny_wong
    • 63. Danilo Sato @dtsatoJenny Wong @jenny_wong