Your SlideShare is downloading. ×
0
When Waterfall and Agile Collide- Managing the Balance
When Waterfall and Agile Collide- Managing the Balance
When Waterfall and Agile Collide- Managing the Balance
When Waterfall and Agile Collide- Managing the Balance
When Waterfall and Agile Collide- Managing the Balance
When Waterfall and Agile Collide- Managing the Balance
When Waterfall and Agile Collide- Managing the Balance
When Waterfall and Agile Collide- Managing the Balance
When Waterfall and Agile Collide- Managing the Balance
When Waterfall and Agile Collide- Managing the Balance
When Waterfall and Agile Collide- Managing the Balance
When Waterfall and Agile Collide- Managing the Balance
When Waterfall and Agile Collide- Managing the Balance
When Waterfall and Agile Collide- Managing the Balance
When Waterfall and Agile Collide- Managing the Balance
When Waterfall and Agile Collide- Managing the Balance
When Waterfall and Agile Collide- Managing the Balance
When Waterfall and Agile Collide- Managing the Balance
When Waterfall and Agile Collide- Managing the Balance
When Waterfall and Agile Collide- Managing the Balance
When Waterfall and Agile Collide- Managing the Balance
When Waterfall and Agile Collide- Managing the Balance
When Waterfall and Agile Collide- Managing the Balance
When Waterfall and Agile Collide- Managing the Balance
When Waterfall and Agile Collide- Managing the Balance
When Waterfall and Agile Collide- Managing the Balance
When Waterfall and Agile Collide- Managing the Balance
When Waterfall and Agile Collide- Managing the Balance
When Waterfall and Agile Collide- Managing the Balance
When Waterfall and Agile Collide- Managing the Balance
When Waterfall and Agile Collide- Managing the Balance
When Waterfall and Agile Collide- Managing the Balance
When Waterfall and Agile Collide- Managing the Balance
When Waterfall and Agile Collide- Managing the Balance
When Waterfall and Agile Collide- Managing the Balance
When Waterfall and Agile Collide- Managing the Balance
When Waterfall and Agile Collide- Managing the Balance
When Waterfall and Agile Collide- Managing the Balance
When Waterfall and Agile Collide- Managing the Balance
When Waterfall and Agile Collide- Managing the Balance
When Waterfall and Agile Collide- Managing the Balance
When Waterfall and Agile Collide- Managing the Balance
When Waterfall and Agile Collide- Managing the Balance
When Waterfall and Agile Collide- Managing the Balance
When Waterfall and Agile Collide- Managing the Balance
When Waterfall and Agile Collide- Managing the Balance
When Waterfall and Agile Collide- Managing the Balance
When Waterfall and Agile Collide- Managing the Balance
When Waterfall and Agile Collide- Managing the Balance
When Waterfall and Agile Collide- Managing the Balance
When Waterfall and Agile Collide- Managing the Balance
When Waterfall and Agile Collide- Managing the Balance
When Waterfall and Agile Collide- Managing the Balance
When Waterfall and Agile Collide- Managing the Balance
When Waterfall and Agile Collide- Managing the Balance
When Waterfall and Agile Collide- Managing the Balance
When Waterfall and Agile Collide- Managing the Balance
When Waterfall and Agile Collide- Managing the Balance
When Waterfall and Agile Collide- Managing the Balance
When Waterfall and Agile Collide- Managing the Balance
When Waterfall and Agile Collide- Managing the Balance
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

When Waterfall and Agile Collide- Managing the Balance

480

Published on

Presentation to IIBA South Florida Chapter Members, Courtesy of Borland's Mark Kulak and Bryan Fangman.

Presentation to IIBA South Florida Chapter Members, Courtesy of Borland's Mark Kulak and Bryan Fangman.

Published in: Technology, Business
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
480
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
20
Comments
0
Likes
1
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

Transcript

  • 1. When Agile & Waterfall Collide – Managing the Balance! Mark Kulak Bryan Fangman
  • 2. MARK KULAK Borland Caliber – Requirements Definition & Management Director of Product Development
  • 3. • The current state of software project success and industry trends • What’s wrong with traditional requirements management methods • Latest innovation and concepts in Requirements Definition & Management with Agile delivery 3 Overview © 2013 Borland
  • 4. The Standish Group International, Inc. CHAOS Manifesto 4 Trends - Software project success © 2013 Borland
  • 5. 5© 2013 Borland
  • 6. 6 What does Agile really mean for requirements? © 2013 Borland
  • 7. 7 Waterfall lifecycle 7 Requirements Definition & Management © 2013 Borland
  • 8. 8 Requirements Definition & Management DefinitionElicitation Management Approval Requirement s Requirements © 2013 Borland
  • 9. Waterfall Project Management Strengths 1. Clear understanding of expected scope 2. Produces complete design and documentation 3. Clearly visible project history and evolution 4. Progress through stages is clearly visible 5. Definition up front allows understanding of what is fully expected 6. Enforces discipline by requiring completion of one stage before moving to the next 7. Staged approach is relatively easy to implement and understand Weaknesses 1. Mistakes in requirements lead to significant wasted effort 2. Business needs change as defined requirements wait for implementation 3. Great difficulty in adapting to change across phases 4. Defining full features up front is difficult 5. Estimating up front is often inaccurate 6. Visibility of detail across stages is limited (isolated by project roles) 7. Work occurs in cycles creating peaks and valleys of activity 8. Monumental review process 9© 2013 Borland
  • 10. 10 Agile Software Development © 2013 Borland
  • 11. 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. Agile Manifesto • Individuals and interactions… over process and tools • Working software… over comprehensive documentation • Customer collaboration… over contract negotiation • Respond to change… over following a plan 11© 2013 Borland
  • 12. 12 Agile / Iterative / Scrum… © 2013 Borland Developed Tested Documented
  • 13. Weaknesses 1. "Agile" often implemented as un- governed methodology 2. Limited requirements change management / visibility 3. Non-functional requirements are difficult to capture as user stories 4. Project scope not clearly understood 5. "Fail fast" approach knowingly introduces regular rework 6. Lack of structure and necessary documentation 7. Delivery focused Agile Project Management – Requirements Strengths 1. Adapts to changing business needs in short cycles 2. Allows progress with limited information 3. Mistakes in requirements lead to limited wasted effort 4. Inclusive of all stakeholders across project 5. Provides clear status in the form of working software 6. Work occurs in a sustainable manner 13© 2013 Borland
  • 14. • Agile was a pullback from very tightly managed and highly governed waterfall lifecycle • Manifesto was required – A radical change required a radical action – Agilista • Agile needs to fit for the enterprise… – Visibility – History – Traceability – Governance • Time to adapt… “be agile”, don’t “do agile” 14 Agile is now widely recognized as a software lifecycle © 2013 Borland
  • 15. Agile / Iterative / Scrum… Requirements Definition Requirements… Elicitation? Definition? Collaboration? Review? Versioning? Change Management? 15© 2013 Borland
  • 16. Requirements Definition & Management Elicitation Management Approval Requirement s Requirements Definition 16© 2013 Borland
  • 17. Iterative Development Two Life Cycles… Working as One Iterative Definition Add structure and management to the backlog User Feedback 17© 2013 Borland
  • 18. • Requirements backlog – Managed / groomed to enable consensus, visibility and governance • Incremental definition – Detail defined according to relative priority – Definition work spent on low priority requirements is waste – Definition work beyond that required for communication is waste • Iteratively turn over "well formed" requirements / user stories – Defined, reviewed and approved… Manage the backlog • Success measured against “business need” not against “development unit” – When is a product releasable?... Minimally marketable features 18 Agile requirements definition © 2013 Borland
  • 19. 19 Aren’t requirements and user stories the same thing? © 2013 Borland
  • 20. 20 Defining Business Need - Requirement Idea Increasing Detail Fully formed Requirement High level goals Basic visualization Use cases Functional requirements Non-functional requirements Business Need Driven © 2013 Borland
  • 21. 21 Defining Development Unit – User story Task User story Feature Breakdown for work User story Development Need Driven © 2013 Borland
  • 22. 22 Agile Requirements Bell Curve Defining Development Detail Defining . Business Features What is the status of what was asked for? Idea Task Does what was created, satisfy what was asked for?
  • 23. 23 Do I still need to define it all up front? © 2013 Borland
  • 24. Practical Fidelity (Incremental Definition) Definition beyond what is required for communication is waste 24© 2013 Borland
  • 25. 25 Pragmatic definition Defining Development Detail Detail required for business clarity WASTE © 2013 Borland Defining . Business Features
  • 26. 26 Different for every organization, project, requirement Light weight requirementsDetailed requirements Regardless of level of rigor in the organizational process, requirements must be managed © 2013 Borland
  • 27. Upfront Requirements Definition… a Contrast Traditional Requirements Requirement 1 Feature 1.1 Feature 1.2 Feature 1.3 Requirement 2 Feature 2.1 Feature 2.2 Feature 2.3 Requirement 3 Feature 3.1 Feature 3.2 Feature 2.4 Feature 2.5 Agile Requirements Requirement 1 Feature 1.3 Requirement 3 • Full upfront definition including low priority features • Rigid expectations • Commitment to detailed scope • “Must Have” payload and critical features defined upfront • High level definition only, detailed where details are needed • Incremental detail added JIT to match delivery team need (iterations) • Commitment to high level scope © 2013 Borland
  • 28. © 2013 Borland Approved Requirement 1 Feature 1.1 Feature 1.2 Feature 1.3 Requirement 2 Feature 2.1 Feature 2.2 Feature 2.3 Requirement 3 Feature 3.1 Feature 3.2 Feature 2.4 Feature 2.5 Delivery Using Traditional Requirements Requirement 1 Feature 1.1 Feature 1.2 Feature 1.3 Requirement 2 Feature 2.1 Feature 2.2 Feature 2.3 Requirement 3 Feature 3.1 Feature 3.2 Feature 2.4 Feature 2.5 Delivered • What is delivered seldom matches what is initially requested • Implementation uncovers limitations and opportunities • Usage and market needs shift over time Approved Requirement 1 Feature 1.1 Feature 1.2 Feature 1.3 Requirement 2 Feature 2.1 Feature 2.2 Feature 2.3 Requirement 3 Feature 3.1 Feature 3.2 Feature 2.4 Feature 2.5 Approved Requirement 1 Feature 1.1 Feature 1.2 Feature 1.3 Requirement 2 Feature 2.1 Feature 2.2 Feature 2.3 Requirement 3 Feature 3.1 Feature 3.2 Feature 2.4 Feature 2.5 Overly managed change control process impedes responsiveness Feature 3.3
  • 29. Requirement 1 Feature 1.1 Requirement 3 Requirement 1 Feature 1.1 Feature 1.2 Feature 1.3 Requirement 2 Feature 2.1 Feature 2.2 Feature 2.3 Requirement 3 Feature 3.1 Feature 3.2 Feature 2.4 Feature 2.5 Delivery Using Agile Requirements Initial Approval Delivered Requirement 1 Feature 1.1 Requirement 3 Feature 3.1 Requirement 1 Feature 1.1 Requirement 3 Feature 3.1 Requirement 2 Feature 2.1 Feature 2.2 Feature 1.2 Iteration 2 Iteration 4 Requirement 1 Feature 1.1 Requirement 3 Feature 3.1 Feature 1.2 Iteration 6 Requirement 2 Feature 2.1 Feature 2.2 Feature 2.3 Feature 2.4 Feature 2.5 • Usage and market needs shift over time • Flexible requirements definition process encourages responsiveness • Priority requirements are delivered early, removing risk • Implementation / demos uncover limitations and opportunities Requirement 1 Feature 1.1 Requirement 3 Iterative delivery… what about the iterative REQUIREMENTS delivery? © 2013 Borland
  • 30. DeliveryRequirements Requirement 1 Feature 1.1 Requirement 3 Requirement 1 Feature 1.1 Feature 1.2 Feature 1.3 Requirement 2 Feature 2.1 Feature 2.2 Feature 2.3 Requirement 3 Feature 3.1 Feature 3.2 Feature 2.4 Feature 2.5 Iterative Requirements Definition Iteration 8 Requirement 1 Feature 1.1 Requirement 3 Feature 3.1 Requirement 1 Feature 1.1 Requirement 3 Feature 3.1 Requirement 2 Feature 2.1 Feature 2.2 Feature 1.2 Requirement 1 Feature 1.1 Requirement 3 Feature 3.1 Feature 1.2 Requirement 2 Feature 2.1 Feature 2.2 Feature 2.3 Feature 2.4 Feature 2.5 Requirement 1 Feature 1.1 Requirement 3 Feature 3.1 Requirement 2 Feature 1.2 Feature 2.1 Feature 2.2 Feature 2.3 Feature 2.4 Feature 2.5 Feature 1.3 Feature 3.2 Feature #.# © 2013 Borland Iteration 0&1 Iteration 2 Iteration 4 Iteration 6 • Incremental requirements detail and adjustment • Focus on defining & approving the next most important / risky features • Incorporates changes driven by demo feedback and implementation
  • 31. 31 Agile Requirements Definition and Delivery © 2013 Borland Make agile two lifecycles working as one Iterative requirements definition Iterative requirements delivery Less waste by assuring business and delivery are in alignment. Fail fast… and less frequently Pragmatic definition - only define enough detail to satisfy organizational needs and delivery clarity… Anything beyond is waste
  • 32. BRYAN FANGMAN Borland Caliber – Requirements Definition & Management Senior Product Manager
  • 33. • Testing will cover requirements at the time of definition as well as the incremental deliverables in each supporting story • As Agile practices become more managed, Agile requirements/stories will trace to an increasing number of related elements • More stakeholders will become actively involved in the elicitation and approval process as tools improve efficiency • Visualizations will become increasingly important for requirements elicitation and validation • The majority of individuals participating in the requirements management process will use web-based and mobile solutions • Organizations will become more efficient in centralizing, standardizing and reusing requirements • The accuracy of the initial and ongoing time/cost estimations will improve and occur earlier in the lifecycle 33 The Future of RDM and Agile Tools © 2013 Borland
  • 34. • Testing occurs at multiple levels – Requirements – validates the business capability is delivered – User stories – validates the completeness of the individual incremental capabilities • User stories should be tested every sprint • Requirements are tested after a appreciable amount of business capability has been delivered • Visual scenarios become the foundation for test cases 34 Testing © 2013 Borland
  • 35. • Requirements must be linked to user stories to provide visibility into what has been delivered against the business needs • By understanding how much activity has transpired in delivering the requirement, impact analysis is more complete • Better decisions can be made in real-time to avoid costly rework • Decisions can be made to postpone changes to allow critical functionality to be delivered sooner 35 Impact Analysis with Agile Stories © 2013 Borland
  • 36. 36 Impact Analysis with Traceability © 2013 Borland - Trace to Visualizations - Scenarios - Simulations - Trace design elements - Trace regulatory requirements - Trace dependencies
  • 37. • Tradition non-Agile roles will become more involved • Increased visibility allows for real-time feedback • Reaching greater number of stakeholders ensures the right functionality is delivered the first time • Tools and technology advancements such as web-based and mobile technologies promote real-time participation 37 Increased Stakeholder Participation © 2013 Borland
  • 38. 38 Increased Stakeholder Participation © 2013 Borland - Web and mobile access - View related artifacts and attributes - Centralized feedback - Approvals
  • 39. Scenarios Validate the process flow and identify requirements/business rules: – What is the sequence? – Who is involved at each step? – What are the alternate paths and decisions being made? Simulations Validate the flow, behavior and usability of the user interface by role: – Wireframes and layout – Interactive demonstration of key capabilities – Ensure agreement on UI before development starts 39 Visualizations Promote Agile © 2013 Borland
  • 40. 40 Visualizations: Storyboards (Scenarios) © 2013 Borland Validate the process flow and identify requirements /business rules: • What is the sequence? • Who is involved at each step? • What are the alternate paths and decisions being made?
  • 41. 41 Requirements Validation © 2013 Borland - Scenarios can be validated and are foundation for UAT - Requirements acceptance criteria defined up front
  • 42. 42 Visualizations: Simulations © 2013 Borland Validate the flow, behavior and usability of the user interface by role: • Wireframes and layout • Interactive demonstration of key capabilities • Ensure agreement on UI before development starts
  • 43. • Reusable repository of key requirements – Non functional requirements • Security requirements • Performance requirements • Usability requirements • Requirements are aligned with supporting user stories • Requirements are traced to shared compliance requirements (dependency) • Updates to compliance requirements triggers suspect trace with requirements and subsequent user stories 43 Regulatory Compliance © 2013 Borland
  • 44. • Requirements define the business capability • User stories in aggregate should satisfy the business need • Real-time integration of requirements with user stories is critical for sufficient impact analysis • Integration ensures that what gets delivered aligns with the business needs • Can be done whether moving from structured to Agile or vice-versa 44 Aligning Business Needs and Delivery © 2013 Borland
  • 45. 45 Requirements and Agile Stories © 2013 Borland Create a new story or trace to existing stories
  • 46. 46 Creating a New Story © 2013 Borland Create a new story
  • 47. 47 Alignment of Stories with Business Needs © 2013 Borland Visibility of delivery status
  • 48. • Adopt a process that conforms to your preferred methodology – Ensure the framework does not constrict productivity – Respect roles that are not traditionally Agile • Find a tool that fits within your methodology – Allow each role to work with the tools they want – Avoid restrictive workflows and rules • Centralize best practices from successful projects • Expand visibility between Agile assets and related artifacts for real-time impact analysis • Start with Agile delivery; the rest will follow an Agile tempo in time • Ensure what is delivered aligns to business needs 48 Enabling a Managed Approach to Agile © 2013 Borland
  • 49. QUESTIONS? 49© 2013 Borland
  • 50. For additional information regarding: • Presentation content • Scheduling a demonstration • Integrating requirements and agile delivery • Products and services • Speaking engagements Please contact: 50 Contact Information © 2013 Borland http://www.borland.com Bryan Fangman Senior Product Manager bryan.fangman@microfocus.com (301) 838-5170 Mark Kulak Director of Development mark.kulak@microfocus.com (248) 824-1743
  • 51. BORLAND SOLUTIONS Waterfall, Agile, others… we can help!
  • 52. Borland’s Approach We are Open... to the way you want to work and to the investments you have already made in your ALM tooling We are Agile... in how we work with you, responding quickly to your changing requirements, bringing the benefits of Agile to existing processes We are Enterprise... in our scale and understanding, satisfying even the largest of organizations 52
  • 53. The award recognizes Borland’s Agile Transformation as an IT project that exemplifies intelligent, creative use of technology to meet business and technical objectives. Like most organizations considering a large-scale Agile shift, Borland faced a major process renovation while still needing to execute on an aggressive product roadmap. As Borland began to scale its Agile efforts across an organization with more than 350 developers in five geographic locations, teams needed a better way to collaborate, share information and manage their work. At the same time, management needed visibility in order to establish a baseline for performance and be able to measure the progress and benefits of the transition to Agile. Our Own Award-winning Agile Transformation Borland received an Info World Top 100 Innovation Award for transitioning its own development organization to agile 53
  • 54. Validated by Partners - Microsoft The ideas we have shared are being echoed throughout the industry. http://blog.hinshelwood.com/requirement-management-in-the-modern-application-lifecycle/ 54 * See full article in upcoming inaugural issue of ALM magazine
  • 55. Caliber Requirements Elicitation Storyboards Prototyping Performance Metrics Automated Functional Testing Regression Testing StarTeam SilkCentral Test Management Test Execution Defect Tracking Test Reporting Borland Solutions Execute Tests and Collect Results Create Test Case Scenarios Synchronize Requirements and Create Test Cases Synchronize and Trace Requirements Synchronize Issues Continuous Build and Test Development Metrics Source Control Issue and Task Management Agile Project Management Glossaries Baselines Approvals Traceability Test Case Generation Automated Load Testing SilkPerformer SilkTest SilkMobile On Device test automation iOS, Android, BlackBerry Cloud Execution 55© 2013 Borland
  • 56. 56 Requirements Management and Traceability Caliber Author • Reuse requirements across projects • Integrate with code development and testing tools for verification and validation • Understand the impacts of change and alignment to business objectives through traced relationships © 2013 Borland
  • 57. • Visual clarity reduces process ambiguity • Identifies missing or wrong underlying assumptions • Stakeholder feedback improves quality of requirements • Establishes a common vision and shared responsibility Scenarios and Simulations Caliber Visualize Visualization brings activities, actors and requirements together within their context 57© 2013 Borland
  • 58. • License free model assures maximum participation of stakeholders - Online discussions tied to requirements - Same discussions available from Author, Visualize and Review 58 Collaborate, Review and Discuss Caliber Review © 2013 Borland • Additional functionality - Baselines - Filters - Search • View requirements, attributes, traces via web
  • 59. • Silk Central provides a unified framework for the integration of requirements, test automation tools – Unit – Functional – Performance 59 Test Integration and Management Silk Central Test Management • Dashboard Reporting • Manual execution planning • Highlight risk mitigation and quality goals • Configuration testing • Video and image capture • SAP Testing © 2013 Borland
  • 60. Powerful, easy, cost-effective • Open - offering leading Web 2.0 and broad enterprise application support • Agile - easiest to use load testing solution with a short learning curve for rapid releases • Enterprise - gain confidence in the performance and stability of your mission-critical applications 60 Application Performance Testing Silk Performer • Leading Web 2.0 support • Mobile testing • Cloud integration • Rich reporting and analysis • Server monitoring • Enterprise application support • Workflows & wizards • Accurate real-life user simulations © 2013 Borland
  • 61. Mobile app testing – simple, visual, powerful • Easiest mobile testing tool ensures your mobile apps get to market in half the time • Robust combination of native, image and text based recognition technology increases the usability of your apps • Complete solution handling functional and performance testing makes your mobile apps perform better 61 Mobile Application Testing Silk Mobile © 2013 Borland • The way your users use it – gestures support • Broad mobile OS platform support • No hacking required • Native object recognition • Optical character recognition • Easy to use because it’s visual • Easy to read execution reports

×