Uploaded byGary Pedretti
Holistic Product Development
The document discusses the integration of cross-functional teams and emergent design to enhance product development within agile practices. It emphasizes the importance of delivering working software quickly while promoting collaboration among diverse skill sets and adapting through iterative processes. Key principles include prioritizing working software over documentation, fostering cross-functional interaction, and facilitating the emergence of requirements through continual learning and feedback.
More Related Content
![Agile Methods Overview ]](https://cdn.slidesharecdn.com/ss_thumbnails/agilemethodsoverviewcompatibilitymode-12519950047203-phpapp01-thumbnail.jpg?width=640&height=640&fit=bounds)
Similar to Holistic Product Development
Holistic Product Development
- 1. Cross-Functional Teams +Emergent Design = Holistic Product Development Gary Pedretti, Erik Weber, Pradeepa Narayanaswamy, Dan Piessens
- 2. Who are we?Gary Pedretti • Solutions Manager in Centare’s Agile Practice • 15 years in the software industry with highly cross-functional experience – DBA, Developer, BA, Application Architect • Scrum: Development Team member, Scrum Master, Coach, Certified Scrum Trainer for Scrum.org • http://blog.GaryPedretti.com/ • Twitter: @GaryPedretti • http://www.linkedin.com/in/garypedretti • MCPD 4.0 Web, MCTS 4.0 WCF/Web/Data Access, MCDBA MSSQL 2000, PSM, PSD .NET, PSD Java, CSM, MCPD 3.5 ASP.NET, MCTS 3.5 WCF/ASP.NET/ADO.NET, MCTS SharePoint 2003 Infrastructure, MCPD 2.0 Enterprise, MCTS 2.0 Distributed/Web/Windows, MCSD 1.1, MCAD 1.1, MOUS
- 3. Who are we?Erik Weber • Solutions Manager in Centare’s Agile Practice • Healthcare, Finance, Green Energy • Huge Conglomerates, Small Employee Owned, Fortune 500 • Scrum Coach & Trainer for Scrum.org • Passionate about Agile • Twitter: @ErikJWeber
- 4. Who are we?Pradeepa Narayanaswamy • Senior Consultant in Centare’s Agile Practice • 12 years in the software industry: Programmer, Analyst, Web Designer, Tester, QAT Lead, Agile Consultant, etc. • Extremely passionate about Agile • Specialized in Agile Testing • LinkedIn: www.linkedin.com/in/pradeepanarayanaswamy/ • Twitter: @nPradeepa
- 5. Who are we?Dan Piessens • Staff Consultant for Centare • Over 12 years of development experience developing and designing software in agile teams • Microsoft Patterns & Practices Champion 2008 through 2013 • Twitter: @dpiessens
- 6. Working Software ASAP,Cross-Functional Teams, Emergence THE VISION OF AGILE SOFTWARE DEVELOPMENT
- 7. What is Agility? ag·ile ˈajəl, -ˈ - jī(-ə)l adjective • 1: marked by ready ability to move with quick easy grace <an agile dancer> • 2: having a quick resourceful and adaptable character <an agile mind> Synonyms: graceful, featly, feline, gracile, light, light-footed (also light- foot), lightsome, lissome (also lissom), lithe, lithesome, nimble, spry http://www.merriam-webster.com/dictionary/agile
- 8. What is Agilityin Software Development? A group of software development methods based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change. http://en.wikipedia.org/wiki/Agile_software_development
- 9.
- 10. The Gold Standard– Working Software ASAP • Allows for faster feedback from real end users, and the ability to respond to that feedback • Aligns with businesses’ concerns – They never cared about “done but not tested” – Must be able to deliver value, earn revenue, etc. • Eliminates the “80% done” phenomenon – You’re never sure you’re done until you are done
- 11. The Gold Standard– Working Software ASAP Agile Manifesto • “Working software over comprehensive documentation”
- 12. The Gold Standard– Working Software ASAP The 12 Principles Behind the Manifesto • “Working software is the primary measure of progress” • “Early and continuous delivery of valuable software” • “Deliver working software frequently”
- 13. The Gold Standard– How? Slices, Not Layers Layers = delayed value Slices = value every Sprint © 1993 - 2013 Scrum.org, All Rights Reserved
- 14. What Follows? Cross-FunctionalTeams • Whatever skills necessary to complete a slice • Coders and testers working together • But also: BAs, UI Designers, UX, Technical Writers, Ops/Infrastructure, DevOps, etc. – all working together
- 15. Cross-Functional Teams Agile Manifesto •Individuals and interactions over processes and tools
- 16. Cross-Functional Teams The 12Principles Behind the Manifesto • “Business people and developers must work together daily throughout the project.”
- 17. Cross-Functional Teams –How? • An attitude of optimizing for throughput (working software), not capacity (keeping everyone busy in their specialty) • Culture of learning and sharing – moving towards “generalizing specialists” • Attitude: “Whatever it takes to get this done” • Group ownership of product, work, and “done”
- 18. What Else Follows?Emergence • Admitting that you cannot or will not have all of the requirements up front means that you will learn things along the way • Requirements, Architecture, UI Design, Tests, Documentation – all can emerge
- 19. Emergence Agile Manifesto • “Respondingto change over following a plan”
- 20. Emergence The 12 PrinciplesBehind the Manifesto • “Welcome changing requirements, even late in development” • “The best architectures, requirements, and designs emerge from self-organizing teams.”
- 21. Emergence – How? •An Iteration != Mini-Waterfall • Asynchronous execution of all development tasks – no more sequential, phase-gated steps • Each activity is encouraged to inform the others – Testing informs coding, coding informs architecture, analysis informs testing, etc.
- 22. Peter DeGrace/Jim Rising– Sashimi Process http://www.managedmayhem.com/2009/05/06/agile-software-development-process/
- 23. Scrum.org PSF Course Requirements • Non Sequential execution is key Design • Everyone pitches in regardless of Code individual skill specialty Test • The Development Team is held to account as a unit © 1993 - 2013 Scrum.org, All Rights Reserved
- 24. To Do: ValidateCredit Card Numbers I want customers’ credit card numbers to be validated so that they don't have any surprises when ordering products. • We accept MasterCard, Visa, and American Express • Should validate length of number as 15 digits • Should validate prefix of number • This validation should be reusable from other applications
- 25.
- 26.
- 27. Observations? • The teamdelivered something “done” and shippable!!! • Requirements changed – sometimes they are wrong! Gasp! • New requirements were discovered – but thin-slicing and time pressure resulted in many of them (including the Luhn algorithm) going to the “To Do” list • Time pressure forces people to navigate the grey areas to some reasonable middle ground – Negotiating requirements – “reusable from other applications” requirement was negotiated away from a service, and to something that could be harvested later – Amount of testing that is reasonable – thinking of testing as risk management
- 28. Observations? Practices: • Emergent Design/Architecture •TDD • BDD Tools (sorry Liz), ATDD (SpecFlow, Gherkin) • Swarming/Pairing – pairing across specialties • Structuring for Testing Pyramid
- 29. This Happens Without“Role Playing” • Two-minute video…
- 30. Enough with theWhat and the How HOW ABOUT SOME “WHY?”
- 31. The Gold Standard– Working Software ASAP – Why? • Fast Feedback – Opportunity to respond – Validate assumptions, requirements, value – validate learning • Aligns with business and fosters trust – Delivers value – Earns revenue • Sets an expectation for a single understanding of “done”
- 32. Cross-Functional Teams –Why? • It’s how we get to working software, ASAP • Systems Thinking and optimizing for throughput, not capacity
- 33. Emergence – Why? •Requirements will never be – known completely – expressed well – up-to-date • “Requirements = Assumptions” – Jeff Gothelf • We know that we will always learn things along the way
- 34. Emergence – Why? •If you like predictive project plans, I have a guy for you…
- 35. Winston Royce ToldUs This Was Crazy in 1970!! Managing the Development of Large Software Systems – Dr. Winston W. Royce
- 36. And He ToldUs This Is Still “Risky and Invites Failure”!!! Managing the Development of Large Software Systems – Dr. Winston W. Royce
- 37. And He SaidReality Looked More Like This Managing the Development of Large Software Systems – Dr. Winston W. Royce
- 38. Why Not JustAcknowledge This? http://www.managedmayhem.com/2009/05/06/agile-software-development-process/
- 39. Do this today! CALLTO ACTION
- 40. Let’s Walk ItBackwards This Time • Expect, allow, and foster Emergence • Build Cross-Functional Teams • Get Working Software ASAP
- 41. Expect, Allow, andFoster Emergence • Communication with the business, requirements, testing, domain knowledge – learn about Behavior Driven Development (BDD) – Liz Keogh http://lizkeogh.com/ • Architecture and modeling - http://www.agilemodeling.com/ • User Experience (UX) – Lean UX by Jeff Gothelf • Automated deployment, CD, DevOps, “Production Hygiene” – The Phoenix Project by Gene Kim
- 42. Build Cross-Functional Teams •You’re not pulling people away from their boss or department to put them in “your area” • You’re suggesting the company build teams horizontally across departments, not vertically within departments • Focus on “Competencies, not Roles” – Jeff Gothelf • Just encourage things we already did anyway (Tester <-> BA and Architect <-> Coder connections, etc.)
- 43. Build Cross-Functional Teams CompleteCross-Functionality Condescending Jerks All Generalists Pure Teamwork …at least don’t be a Jerk
- 44. Get Working SoftwareASAP • Challenge yourselves – it can be done…in 30 Days or Less • Get cross-functional training for patterns and practices
- 45. Get Working SoftwareASAP • What will the challenges be in your organization? • Questions?
- 46. Thank You!!! • http://blog.GaryPedretti.com/ • @GaryPedretti • http://www.linkedin.com/in/garypedretti • Gary.Pedretti@Centare.com
Editor's Notes
- #2 Working Software ASAP, Cross-Functional Teams, Emergence
- #8 Note this is NOT the same as SPEED
- #9 Note that the definition here aligns with the dictionary definition of Agile, and is NOT about SPEED
- #12 We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:Individuals and interactions over processes and toolsWorking software over comprehensive documentationCustomer collaboration over contract negotiationResponding to change over following a planThat is, while there is value in the items on the right, we value the items on the left more.
- #13 We follow these principles:Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.Business people and developers must work together daily throughout the project.Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.Working software is the primary measure of progress.Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.Continuous attention to technical excellence and good design enhances agility.Simplicity--the art of maximizing the amount of work not done--is essential.The best architectures, requirements, and designs emerge from self-organizing teams.At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
- #14 Point out that the vertical lines on the right-hand (slices) diagram are never straightFor example, Sprint 2 may require the team to go back and refactor code/decisions made in Sprint 1Also, it takes a cross-functional team to do this effectivelyDoes it take smart people to do emergent architecture? No, it takes smart people to develop software
- #16 We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:Individuals and interactions over processes and toolsWorking software over comprehensive documentationCustomer collaboration over contract negotiationResponding to change over following a planThat is, while there is value in the items on the right, we value the items on the left more.
- #17 We follow these principles:Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.Business people and developers must work together daily throughout the project.Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.Working software is the primary measure of progress.Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.Continuous attention to technical excellence and good design enhances agility.Simplicity--the art of maximizing the amount of work not done--is essential.The best architectures, requirements, and designs emerge from self-organizing teams.At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
- #18 You know, like what ‘Team’ is supposed to mean.
- #20 We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:Individuals and interactions over processes and toolsWorking software over comprehensive documentationCustomer collaboration over contract negotiationResponding to change over following a planThat is, while there is value in the items on the right, we value the items on the left more.
- #21 We follow these principles:Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.Business people and developers must work together daily throughout the project.Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.Working software is the primary measure of progress.Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.Continuous attention to technical excellence and good design enhances agility.Simplicity--the art of maximizing the amount of work not done--is essential.The best architectures, requirements, and designs emerge from self-organizing teams.At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
- #22 Where ACTIVITY formerly meant SEQUENTIAL STEP
- #29 Emergent Design/Architecture: Following conventions of the original application, which does have some basic layering and use of good, known patterns (MVC, Repositories), negotiating for a “harvest, don’t grow” approach with CC ServiceTesting Pyramid – what’s interesting about the testing pyramid is that it’s not just about testing – yes, it shows that automation has a lot more ROI as you move towards the base, but it also talks about the amount or focus of tests, in a way that CANNOT be achieved without good application design