Agile Development – Why requirements matter by Fariz Saracevic
2 likes213 views
This document discusses the importance of requirements management in agile development, emphasizing that requirements can change at any time and from various sources. It outlines the consequences of poor requirements management, including project delays and financial losses, while advocating for a structured approach to capturing and managing requirements. The document also highlights that integrating traditional requirements practices can enhance agile processes and ensure clarity in delivering value to end users.
Agile Development – Why requirements matter by Fariz Saracevic
- 1. Agile Development Why Requirements Matter Fariz Saracevic (fariz@us.ibm.com) Senior Offering Manager IBM @FarizSaracevic
- 3. AGENDA • Why requirements are needed? • Right-Sized Agile Requirements Management • Understanding your requirements management needs • Choices, choices… • What’s Next?
- 4. What Agile Development is NOT? Agile is NOT • prescribed software development process (like RUP) • strict set of rules you must exactly follow • excuse to avoid design, documentation or difficult tasks you can benefit from • guidance against requirements management, documentation, and doing what is right for you It is OK to incorporate traditional Requirements Definition and Management (RDM) practices into agile development • Requirements can (and will) change • Change can come from any source: retrospectives, customers or architectural re-iterations • Change can come any time: before, during and after you elaborated/implemented your story
- 5. Stating the facts… You know that: •Requirements can (and will) change •Change can come from any source: retrospectives, customers or architectural re-iterations •Change can come any time: before, during and after you elaborated/implemented your story To embrace to change you need structure and organization
- 6. Agile manifesto requires structure and organization * Individuals and interactions over process and tools * Work product over comprehensive documentation * Customer collaborating over contract negotiation * Responding to change over following a plan Communicate but use tools to support you Document as needed and at the right time But don’t forget about all your stakeholders and complex relationships Still plan, but focus on getting started vs. long-term plan
- 7. Why are requirements perceived a burden? No perceived value •Requirements should not be just a checkbox in a checklist No real use for the requirements •Requirements used to take a lot of time to develop •After development, they sat on the shelf for too long •Design, tests and code should follow requirements. If not, they are useless. They change •All the time, any time •Unmanaged change is very frustrating
- 8. Why are requirements needed? Increased Compliance and Regulatory Requirements 10 million lines of code in GM Volt Mars Rover Curiosity had 16000+ requirements Multiple vendors and supply chain contractors Smarter Products & Systems Complex Requirements Increased number of stakeholders Collaboration Across the Value Chain Effective Requirements Management
- 9. Why are requirements needed? Marine One Helicopters Fiasco Costs mushroomed to $11.2B from $6.1B Gaudi’s Unfinished Cathedral 100+ year old project still not complete The Defense Science Board issued a new study blaming “poor communication” about aircraft requirements between the government and contractors. The only existing copy of Gaudí’s last recorded blue prints were destroyed by the anarchists in 1938 during the Spanish Civil War. La Sagrada Família is now being completed, but differences between his work and the new additions can be seen.
- 10. Where human safety is a factor, even simple devices and systems require careful engineering to reduce risk
- 11. Why requirements matter? If you ask for the wrong thing, you’ll get it… If you don’t know what was asked for, you’ll deliver the wrong thing… You need to understand what problem you’re trying to solve, get feedback early and often and then adjust… This is all about Agile way of working…
- 12. Poor Requirements Management has a Significant Impact on your Business Requirements Rework Errors, late detected in the Maintenance phase can cost up to 200 times more than detected early in Requirement Analysis phase More than 40% of development budget can be consumed by poor requirements Project Impacts 41% of projects fail to deliver the expected business value and ROI 49% of projects overrun original estimates 28% of projects on time and on budget Project Delays Being late to market by 6 months or more will cost organizations 33% of the 5-year ROI “Our research indicates 80-plus percent of development failures result directly from poor requirements gathering, management, and analysis.” IDC, November 2007
- 13. How do we know what we have built? The development team won’t be there for ever. Someone has to maintain and extend the system. A list of user stories does not give a sufficient picture. Team’s memory Team members can find information about work done in previous Sprints without having to dig through stacks of “done” user stories Product owner/business analysts memory To inform the creation of new user stories User documentation and training material development Why Requirements Management is (still) important in an agile way of working? Requirements can be viewed as:
- 14. Do as much as you need, but not more! • Requirements are only written when needed and detailed enough to know how to implement the system • Requirements are written just in time, to help understand and decompose items on the backlog • Capture decisions as they are made Documenting your system as it is being built enables you to better reuse work when developing the next feature/component/system, saving both time and money If you are fundamentally opposed to calling such decisions “requirements” then don’t. But still capture them!
- 15. Make requirements elaboration a core feature team activity Product Owner • Product Vision • Product backlog prioritization • Represents the client often high level Architect • Technical consistency and quality • Often interfaces with Product Owner Development Team • Get further information on what to implement • Recall details of how finished parts of the system work Feature Team 1 Architect Dev Team Scrum Master Product Owner Feature Team 2 Architect Dev Team Scrum Master Product Owner
- 16. Use and link traditional requirements and agile artifacts Defect Story Task Project Collection Module Backlog Ranked Backlog Release Plan Project Plan Item Affects Implements Friend CCM RM Artifact UX Design Requirement Diagram Implements
- 17. Documentation over memorization 17 Complexity Sprint 1 Sprint 2 Sprint 3 Next Sprint
- 18. Informal terminology notes • The term “Requirement” is loosely used to including all requirements-related information • Textual requirement • Use Case • Usage Scenario • Feature Descriptions • Diagrams and Sketches • User Story • Story Elaborations • Etc • These are not all strictly requirements, the same points apply to all • Many of these are not found on the backlog
- 19. Document relevant information Capture the work you are doing Document your decisions Connect the related information All these things count as requirements • Diagrams and Sketches • User Story • Story Elaborations • Textual requirement • Use Case • Usage Scenario • Feature Descriptions • Retrospective
- 20. But traceability is too much work • Common perception when you create traceability separately •That is making life hard for yourself •When you enter information you have the source available •So create trace information at the same time • Do the right thing at the right time is the essence of agile • It is insane to do it any other time!
- 21. Provide structure and examples • Providing good examples (and counter examples) of requirements • enhance the quality, consistency and completeness of their requirements • teach through “culture and practices” instead of documentation • Structure • Artifact data model (requirement types) • Link Types • Workflow • Templates • Folder structure & tags • Pre-defined views • Document templates • Project templates
- 22. Three Key Challenges Products are becoming much more complex Products are becoming part of larger solutions / ecosystems Disrupt or be disrupted: innovating faster than competitors More software Hardware – Electronics – Software More suppliers More teams More specialists More subsystems Learning fast Deciding fast Acting fast Delivering fast From “predictable world” to “unpredictable world” Safety and security … and new failure modes Teams on-prem and on cloud Teams on different cadences
- 23. Requirements in IBM DevOps Customer / Stakeholder Product Manager / Product Owner Dev Lead Requirement Feature Dev Work Item Continuous Customer Feedback & Optimization Collaborative Development Continuous Release and Deployment Continuous Monitoring Continuous Business Planning Continuous Testing Operate Develop/ Test Deploy Steer DevOps Continuous Feedback Requirements are the key artifact representing feedback… Requirements drive articulation of application features… Development delivers function for features…
- 24. Rational Team Concert (RTC) Development Change Control Board (CCB) Design and develop software (SCM) Triage Enhancements / defects Backlog (Work items) Customer / Stakeholder Product owner / manager Dev Lead Software Engineer Analyse Specific work items can be put into the product backlog and delivered against directly Requirements
- 25. Rational DOORS Next Generation (RDNG) Change Control Board (CCB) Triage Enhancements / defects Backlog (Work items) Customer / Stakeholder Product owner / manager Dev Lead Analyse Requirements Requirements Analysis Requirements Analysis System Requirements User RequirementsSpecify Requirements Analysis transforms many disparate inputs from different stakeholders into specific Requirements for the development team to work against.
- 26. Rational Team Concert (RTC) Rational DOORS Next Generation (RDNG) Change Control Board (CCB) Triage Enhancements / defects Backlog (Work items) Customer / Stakeholder Product owner / manager Dev Lead Analyse Requirements Requirements Analysis System Requirements User RequirementsSpecify Deployment Design and develop software (SCM) Software Engineer These two activities can be executed in the same organisation with Requirements elaborating what business need the development team is aiming to solve.
- 27. Requirements in Scaled Agile Framework (SAFe) Scaled Agile Framework (SAFe) with the Power of DevOps Requirements articulated in Portfolio Planning and refined through analysis into Features and Stories…
- 28. Rational DOORS Next Generation Choices, choices… Rational Team Concert How do you choose?
- 29. Understanding your requirements management needs Regulated/System Enterprises Need for regulatory compliance and auditing Separation of roles (Business Analysts, Development) Requirement governance Robust requirements articulation needs Rational DOORS Next Generation Small Agile Teams Unregulated, little or no compliance or audit requirements Desire for single tool lightweight requirements and change management Simple requirements articulation needs Rational Team Concert
- 30. IBM Rational Team Concert Requirements simplicity for Small Agile Teams RTC Quick Planner • Easy to learn • Fast work item creation • Manage a backlog and sprints in a single window using drag and drop • Manage Parent/Child tasks and their rank relationships • IBM Design driven task based UI Reporting • Jazz Reporting Service • Fast data collection • Query builder • Lean reports Collaboration • Activity streams to track events • Automated work item reply • Social flow for comments • Manage & preview attachments Kanban/Taskboard • States and State-groups • Customize card display • Customize display of states • Display small, medium, large cards Build & Deploy • Post Build Deploy using UC Deploy • Gated control of builds for deployment Compliance for SCM • Improved large team usage with pessimistic locking • Improved auditing for work item link changes • Ability to see who and when code changes were delivered Integration • Git • Jenkins
- 31. Better requirements… Less rework… Better results! IBM Rational DOORS Next Generation Enhance your value and capability beyond RTC for requirements Search, filter on attributes Business Objectives Business Processes Use Cases Storyboards & Sketches Reporting Industry & Domain Models Impact & Coverage analysis Rich text Requirements Traceability between related artifacts Rational DOORS Next Generation Definition and Management Lifecycle Traceability Project Efficiency and Reuse Improves the developer’s ability to design UI and software flow in the initial design phase Better define and manage rich text use cases, visual diagrams or processes Strengthens stakeholder’s traceability across all lifecycle artifacts to find missing requirements or use cases Easily discover the impact from requirement or use case changes Reuse requirements for multiple projects to lower development costs and capitalize on best practice Enables the development experience through a specification structures
- 33. “Agile is quickly becoming the most popular way of developing software because it ... more quickly deliver value to the end users. That value will be driven to a large extent by the quality and clarity of requirements that feed the software development process. An agile, lean, and timely approach to requirements as the starting point will help to ensure that the process is optimized.” Scrum Alliance Agile Requirements Definition and Management Feb 2012
- 34. We’re Agile now. Do we really need Requirements Management? • Yes, if done correctly, at the right time, and to the right level! • Yes, everything isn’t captured on the backlog! • Yes, we need to know what you have built! • Managing requirements does not need to be a burden • Requirements management is possible and quite necessary in agile development • You need to understand the relationships between sets of information and that is most of what RM is about