SlideShare a Scribd company logo

Agile Requirements Management

Liana Underwood, profile picture
Liana Underwood

The document provides an overview of agile principles and processes for managing software development projects. It defines key agile concepts like scrum, the agile manifesto, and roles on a scrum team. It also discusses establishing a scrum process, including defining artifacts, meetings, team structure, and core concepts. The document aims to educate about agile and managing the risks to successful adoption.

Business
1 of 77
Downloaded 29 times
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
For discussion Purposes only Confidential Page 1 Revolutionary Performance Management
For discussion Purposes only Confidential Page 2 About the speaker: Don Wilson gained his Bachelors in Computer Science from North Carolina A&T State University and jumped immediately into solving business problems with technology. He spent the first part of his career in with Ernst & Young and Deloitte planning and implementing multimillion dollar software packages for fortune 500 companies. He translated the strategic, process and technical knowledge into a success as an architect and then project manager for software development and implementation projects. While making progress possible with software is a passion for Don his spare time is spent on the sidelines of his sons soccer games and the isle of his daughters ballet and violin recitals or a blogging event for his wife. If those aren't going on he's golfing fishing or watching football(any kind).
For discussion Purposes only Confidential Page 3 Definition: Agile ag·ile [aj-uhl, -ahyl] Adjective 1. quick and well-coordinated in movement; lithe: an agile leap. 2. active; lively: an agile person. 3. marked by an ability to think quickly; mentally acute or aware: She's 95 and still very agile. Origin: 1570–80; earlier agil < Latin agilis, equivalent to ag- (base of agere to do) + -ilis -ile Related forms ag·ile·ly, adverb ag·ile·ness, noun un·ag·ile, adjective un·ag·ile·ly, adverb Synonyms 1. nimble, sprightly. 2. brisk, spry. Antonyms 1. awkward. 2. sluggish, lethargic. Dictionary.com Unabridged Based on the Random House Dictionary, © Random House, Inc. 2014.
For discussion Purposes only Confidential Page 4 Definition: Requirements re·quire·ment riˈkwīrmənt/ Noun Synonyms: need, wish, demand, want, necessity, essential, prereq uisite, stipulation “good spelling is a requirement of the job" noun 1.a thing that is needed or wanted. "choose the type of window that suits your requirements best" •a thing that is compulsory; a necessary condition. "applicants must satisfy the normal entry requirements"
For discussion Purposes only Confidential Page 5 Agility in life Agile Animals Agility in Sports Agility In Traffic Agility in Business
For discussion Purposes only Confidential Page 6 BACKGROUND
For discussion Purposes only Confidential Page 7 Manifesto 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 tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more. Kent Beck Mike Beedle Arie van Bennekum Alistair Cockburn Ward Cunningham Martin Fowler James Grenning Jim Highsmith Andrew Hunt Ron Jeffries Jon Kern Brian Marick Robert C. Martin Steve Mellor Ken Schwaber Jeff Sutherland Dave Thomas
For discussion Purposes only Confidential Page 8 Agile Manifesto Principles We follow these principles: 1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. 2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. 3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. 4. Business people and developers must work together daily throughout the project. 5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. 6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
For discussion Purposes only Confidential Page 9 Agile Manifesto Principles We follow these principles: 7. Working software IS the primary measure of progress. 8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. 9. Continuous attention to technical excellence and good design enhances agility. 10.Simplicity--the art of maximizing the amount of work not done--is essential. 11.The best architectures, requirements, and designs emerge from self- organizing teams. 12.At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
For discussion Purposes only Confidential Page 10 ADOPTION
For discussion Purposes only Confidential Page 11 Adoption Rates
For discussion Purposes only Confidential Page 12 Agile Success According to the 2012 CHAOS report, Agile succeeds three times more often than waterfall.
For discussion Purposes only Confidential Page 13 Why Scrum Source: 7th State of Agile Development Survey by VersionOne
For discussion Purposes only Confidential Page 14 AGILE IN REQUIREMENTS
For discussion Purposes only Confidential Page 15 What are the benefits of Agile More software that is relevant Higher Customer satisfaction Higher Trust Level Shorter Wait times Shorter Development cycles ) More frequent delivery More inspection opportunities Ability to change direction
For discussion Purposes only Confidential Page 16 What are the Risks to Success 1. Wrong Time or Place 1. Good ideas coming only after code complete 2. Good feedback from management or others not directly related to the project 2. Wrong Ideas 1. Not understanding what needs to be built 2. Assuming what needs to be built 3. Wrong Context 1. Not understanding the context of requirements 2. Incomplete requirements (whole context not known/understood by development team) 3. Shame Changes: shaming into scope changes. is it really a viable piece of software if it cant do this. This is useless unless it can do XYZ 4. Wrong Level of understanding 1. Not OWNING the requirement. Understanding how to validate the requirement has been achieved. The team should be able to to not only articulate what the requirement is but also know when it has been successfully delivered. 2. Unspoken requirements 5. Wrong People 1. Not getting requirements from the right people (getting requirements from owners vs users) 2. Roles in and outside of system not clearly defined 6. Wrong Perspective 1. Epic Splitting (part of the problem being solved but part not addressed now. Integration of stories within an epic can cause additional issues) 2. Legitimate Changes in requirements 7. Wrong Priorities 1. Conflicting Priorities among Business communities. Conflicts between users an management and between different groups 2. Gold Plating/Requirement stuffing (What i really meant was... or it wont really be complete if it does not do X) 8. Wrong Techniques/Tools/Tactics 1. Poor design, architecture, technique or coding practices leads to poor results 2. Code not getting adopted or poor reuse
For discussion Purposes only Confidential Page 17 Keys to addressing Risks 1. Understand your process and its stakeholders 2. Educate 3. Proactively Listen 4. Understand the big picture 5. Work Progressive elaboration into your process 6. Work on what matters 7. Inspect and Adapt
For discussion Purposes only Confidential Page 18 KNOW YOUR PROCESS
For discussion Purposes only Confidential Page 19 Know your process & role first Explain your process to the customer Help them understand the process their idea will go through to help deliver value Know how your audience changes throughout the process
For discussion Purposes only Confidential Page 20 Scrum Team Roles Aspect Scrum Master Product Owner Team Key Activities Educate Facilitate Key Ceremonies Remove Impediments Protect Team Helping the team b Create backlog Assign Value and Prioritize Stories Break Epics into stories Clarify Requirement inquiries Facilitate Adoption Estimates Prototypes Spikes Develops Tests Major Contribution Education & Impediment Removal Process improvements Vision & Roadmap & Secure funding/Adoption Creating Working Code Measured by Transparency, Efficiency and Effectiveness of the scrum process Roadmap Ability to represent stakeholder intrests Velocity Value Quality Code Core Skills • Excellent leadership and facilitation skills • Able to explain key agile concepts to a variety of audiences • Excellent communication skills • Expert in the process able to communicate the value of the process nuances and coach participants in the proper way to execute • Focused on continuous improvements for the team, management and the product owner and customers alike • Forward thinking visionary • Able to decompose concepts into phases or components • Technical enough to understand implications of technology decisions • Business savvy enough to understand implications of business matters. • Able to translate business issues into technical terms and technical issues into business terms. • Able to define/refine an architecture to address current and future needs • Able to identify and establish key programing practices that lead to code reuse, easy integration, scalability and maintainability • Ability to increase the technical acumen of the development team. • Ability to view and assess potential enhancements with accurate effort estimations and potential impact analysis on the current infrastructure. • Ability to identify talented
For discussion Purposes only Confidential Page 21 Initiate Core Scrum Concepts Value Team Size Scrum Meeting Cadence Self Organizing Team Colocation Sushi not Sashimi Chickens & Pigs Spikes Prototypes Burn down Empirical Information Radiator Scrum Board Backlog Stories Epics Story Points Conditions of Satisfaction Done Done Shippable unit
For discussion Purposes only Confidential Page 22 Establish the elements Artifacts Working Code Prototypes Backlog Retrospective Notes Scrum Board (or app) Burn down Charts (sprint, Epic, Product) Roadmap Release Schedule Budgets and Forecasts Portfolio and Project status reports Meetings Requirements Review sessions Road Mapping sessions Bi-weekly Client Prioritization sessions (weekly) Estimation Grooming Sprint Planning Daily Standup Sprint Demo Sprint Retrospective
For discussion Purposes only Confidential Page 23
For discussion Purposes only Confidential Page 24 Life of a requirement Ideas Elaborate QuantifyDeliver Inspect & Adapt
For discussion Purposes only Confidential Page 25 Planning at Multiple Levels Source: Agile Estimating and Planning
For discussion Purposes only Confidential Page 26 EDUCATE YOUR STAKEHOLDERS
For discussion Purposes only Confidential Page 27 Communicate Profusely Management Trust comes with results (doing what you said you'd do when you said you'd do it) Over communicate Steering committees/PMO Governance Financial reporting Status Reporting Budgeting Arcuate Estimations critical Use backlog grooming and SP estimating in projecting future budget requirements Calculate EVM if necessary Everyone else Educate, Explain value, laud victories, readily admit mistakes and plans to address them Time dependent interactions with cadence where possible
For discussion Purposes only Confidential Page 28 Agile Customer Alignment Educate Understand what’s valuable to the customer. Create an environment for success Educate them on the process, what’s different, what to expect and what’s needed from them What's different, Time Boxed Delivery More Frequent releases, Less documentation More responsiveness and involvement from them (decisions in 5 minutes) Keep them informed with a consistent stream of information, Each timebox has a frequency (cadence/rhythm) Help them to understand the cadence Frequent inspection Communicate help them to know you truly intend to represent their priorities as an advocate Planning Long term planning Mid Term planning Short term planning Delivery Frequent inspection Adapting to the gaps Scope is still important Changes are encouraged if they improve value but the triangle still needs to be maintained Changes still have an impact: financial impact Other users Working with multiple clients & balancing priorities Transparency, Fairness, Consistency
For discussion Purposes only Confidential Page 29
For discussion Purposes only Confidential Page 30 Addressing the Risks Risk 1. Wrong Time or Place 1. Good ideas coming only after code complete 2. Good feedback from management or others not directly related to the project Fix Communicate early and often about the opportunities to provide input. Communicate to: Team Customers Stakeholders/managem ent Others
For discussion Purposes only Confidential Page 31 PROACTIVELY LISTEN
For discussion Purposes only Confidential Page 32 Understanding has No Shortcuts • Requirements are about communicating what is desired even if its not explicit. • The life of a requirement needs to be understood from thought to adoption including its appearance in many forms to many parties. • Traceability should extend beyond deployment to understand the usage rates patterns and errors. Its also good to know who asked for it and their history
For discussion Purposes only Confidential Page 33 How do we Understand
For discussion Purposes only Confidential Page 34 Proactive Listening Hearing out the requirements in the right context with the right people involved is the first step in refining requirements for success Subjects, Verbs, Objects Confirm Understanding Avoid Extremes Writing everything Not writing anything The point is understanding not just understanding for temporary recall but understanding so that you can represent the matter to someone else.
For discussion Purposes only Confidential Page 35 Progressive Elaboration Understanding Takes time. Agile is more interested in communication over documentation. Elaboration Occurs in Stages Understand Macro Requirement Understand Context Outline Solution & Get feedback Provide more detailed solution & Get feedback Provide mockup & Get feedback Prototype and get feedback Develop and get feedback Deploy and get feedback
For discussion Purposes only Confidential Page 36 Progressive Elaboration
For discussion Purposes only Confidential Page 37 Addressing the Risks Risk 2. Wrong Ideas 1. Not understanding what needs to be built 2. Assuming what needs to be built Fix Understanding the big picture Proactive Listening Progressive elaboration
For discussion Purposes only Confidential Page 38 UNDERSTAND THE BIG PICTURE
For discussion Purposes only Confidential Page 39 Roadmap Volunteer Portal RoadmapDec Jan Feb Mar April May Jun July Aug Sept Oct Nov Dec R6 11/10 R7 12/15 R8 2/2 R10 6/21 R12 12/06 RX Dev UAT/BF UI R Requirements User Interface Design Development User Acceptance Testing and Bug Fixes Production Release Sprint 20 Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5 Sprint 6 Sprint 7 Sprint 8 Sprint 9 Sprint 10 Sprint 11 Sprint 12 Sprint 1 Supervisor flow Group 2 Epic 1 Group 3 Epic 2 Volunteer flow Group 2 Epic 2 Group 2 Epic 3 Add Host Edit Host: Marketing Contact Edit Host: Contact Selection Report Updates Course Loading Tool Edit Host Capabilities Modify Email Address Submitter Flow Edit Course Reports Utilities and Transition Host Flow Receipt Management ERP/Legacy Integration Exports and Messaging Volunteer Flow Staff Flow Locator Updates R11 9/20 R9 4/18 R8.1 4/3 Group 1 Epic 1 UAT – DSP Host Group 3 Epic 1 G1 – Epic 2 Mutually Beneficial Epic 1 Approver Flow R11 UAT Group 3 Epic 4 R12 UAT R10 UAT
For discussion Purposes only Confidential Page 40 Story Board: Big Picture
For discussion Purposes only Confidential Page 41 Addressing the Risks Risk 3. Wrong Context 1. Not understanding the context of requirements 2. Incomplete requirements (whole context not known/understood by development team) 3. Shame Changes: shaming into scope changes. is it really a viable piece of software if it cant do this. This is useless unless it can do XYZ Fix Progressive elaboration Process Context System Context Mockups Prototypes Conditions of Satisfaction
For discussion Purposes only Confidential Page 42 Story Board: Process Context
For discussion Purposes only Confidential Page 43 Addressing the Risks Risk 4. Wrong Level of understanding 1. Not OWNING the requirement. Understanding how to validate the requirement has been achieved. The team should be able to to not only articulate what the requirement is but also know when it has been successfully delivered. 2. Unspoken requirements (Context: technical & business ) Fix Proactive listening Understanding Why Progressive elaboration Process Context System Context Mockups Prototypes Conditions of Satisfaction
For discussion Purposes only Confidential Page 44 Edit Mileage Reimbursement Entry Description: This page provides allows a volunteer or designated proxy to Add or Edit a single Mileage reimbursement expense entry # Action Logic Data 1 Date Slection NO limitation on dates to be selected (NEED CONFIRMATION Required 2 Select Expense activity List Populated from table Required 3 Enter Explaination Required LIMIT 255 Characters 4 Enter Miles Required (3 digits after decimal point) 5 Update Saves and returns to the expense details screeen 6 Cancel Returns to the expense details screen 7 8 9 Accessing User Access Conditions Display logic Volunteers Visible Access only to personal list Staff/Proxy entry Visible Access to all volunteers via lookup Approvers Not visible Finance Liason Not visible # Action/ Triggers To Subject Message Body Exceed Character limit for Explainatio n Add Success Successfully Added a mileage Expense Add Error Error in adding milage expense # Business Rule Mileage rate per program needs to be defined and configured in the admin tool (or at least in a configuration file) Requirement from TA to allow a lower mileage entry rate per submission (Not per entry) (ADD TO SCOPE ISSUES) (Not an issue for States –DSP will confirm) Need Expense Activity Lists from DSP/States and Expense Types Are there any limitations on Miles or expenses per day or per type per day Add Delete buton Story Board Page Example
For discussion Purposes only Confidential Page 45 Conditions of Satisfaction The system is considered complete if it meets these conditions. Conditions can be Functional Conditions Technical Conditions Pre-Conditions The COS serve as a baseline for both feature validation and traceability
For discussion Purposes only Confidential Page 46 Addressing the Risks Risk 5. Wrong People 1. Not getting requirements from the right people (getting requirements from owners vs users) (Understand Who uses the system) 2. Roles in and outside of system not clearly defined Fix Educating the users Proactive listening Progressive elaboration Process Context System Context Mockups Prototypes Conditions of Satisfaction
For discussion Purposes only Confidential Page 47
For discussion Purposes only Confidential Page 48 Decomposing Epics
For discussion Purposes only Confidential Page 49 Addressing the Risks Risk 6. Wrong Perspective 1. Epic Splitting (part of the problem being solved but part not addressed now. Integration of stories within an epic can cause additional issues) (Planning for integration with Epic Breakdown) 2. Legitimate Changes in requirements (scope swap) Fix Epic Breakdown Scope Swapping Backlog Overview Backlog Assessments Conditions of Satisfaction
For discussion Purposes only Confidential Page 50 THINK LEAN ELIMINATE WASTE
For discussion Purposes only Confidential Page 51 Think Value Source: Jim Johnson. The Standish Group International Inc. 2002.
For discussion Purposes only Confidential Page 52 Seven Wastes Toyota Production System [1] Inventory Overproduction Extra Processing Transportation Waiting Motion Defects Software Development [2] Partially Done Work Extra Features Relearning Handoffs Delays Task Switching Defects 1. Shingo, Shigeo. A Study of the Toyota Production System. Productivity Press, 1981. 2. Poppendieck, Mary and Tom. Implementing Lean Software Development: From Concept to Cash. Addison-Wesley, 2006.
For discussion Purposes only Confidential Page 53 Assessing Value Understand why its being requested, who benefits from the request and how. Also identify the ideal scenario. Set a formula Weighting what’s important to your organization Auto calculate base on entries in each area Be consistent in ratings (keep them relative) Examlpes: Attract Customer or enhances customer experience Legal Corporate Dashboard/Score card Goal Impact Impacts Business Continuity Time Savings Increase Capacity Impact Community Impact Multiple Groups Cost Savings Increase Revenue
For discussion Purposes only Confidential Page 54 Assessing Value
For discussion Purposes only Confidential Page 55 Right Sizing Stories Relative size Relative complexity Independence Factor assumptions & Constraints Challenges to be faced Unknowns Assumed Effort
For discussion Purposes only Confidential Page 56 Story Point Estimating
For discussion Purposes only Confidential Page 57 Addressing the Risks Risk 7. Wrong Priorities 1. Conflicting Priorities among Business communities. Conflicts between users an management and between different groups 2. Gold Plating/Requirement stuffing (What i really meant was... or it wont really be complete if it does not do X) (Prioritization & Value assessment) Fix Value Evaluation Story Point Estimation Educating the users Proactive Prioritization Roadmap
For discussion Purposes only Confidential Page 58 The Backlog
For discussion Purposes only Confidential Page 59 Traceability Coverage Requesting party, Adoption and Usage Relationship to others Parent items Children
For discussion Purposes only Confidential Page 60 Value Evaluation Scope swaps Remaining work Delivered items
For discussion Purposes only Confidential Page 61 Backlog Assessment
For discussion Purposes only Confidential Page 62 Backlog Overview
For discussion Purposes only Confidential Page 63 Inspect and Adapt Opportunities Customer opportunities for inspection & adjustment Requirements: Idea Discussed and translated to story Grooming/Planning: Effort Estimation & Value assignment & Priority Assignment Design Client Prioritization sessions (weekly) Road Mapping sessions Bi-weekly Sprint Review Demonstration UAT Production Team Opportunities for inspection & adjustment Grooming Sprint Planning Daily Standup Sprint Review Retrospective Management Opportunities for inspection & adjustment Project Initiation Project Estimating Project Budget authorization Status reports (Sprint specific, Project Specific) (indicate overall progress in terms of scope, resources and time) Steering committee/PMO Meetings (Sprint specific, Project Specific) Lessons Learned Others: Grooming Invited to planning Scrum of Scrum Sessions
For discussion Purposes only Confidential Page 64 Addressing the Risks Risk 8. Wrong Techniques/Tools/Tactics 1. Poor design, architecture, technique or coding practices leads to poor results 2. Code not getting adopted or poor reuse (Inspect & Adapt) Fix Backlog Assessment Proactive Prioritization Roadmap Inspect and Adapt Team Tactics Technologies Process
For discussion Purposes only Confidential Page 65 RECAP
For discussion Purposes only Confidential Page 66 Performance Measures Project Success Budget Scope Time Client Satisfaction Development Team Success Vision Deliverables Scope delivered Speed of Delivery Quality of Delivery Residual Value of delivery Reuse Planned and unplanned value Reduced maintenance Teamwork: Listening Trust Innovation Agile Team Success High Value Delivery Reduced Code Waste High Visibility Development Implementation Self Managed Teams Accountable Transparent Innovative
For discussion Purposes only Confidential Page 67 What are the Solutions 1. Wrong Time or Place (Process) 1. Good ideas coming only after code complete 2. Good feedback from management or others not directly related to the project 2. Wrong Ideas 1. Not understanding what needs to be built (Big picture) 2. Assuming what needs to be built (Confirm with Pro Elab) 3. Wrong Context 1. Not understanding the context of requirements 2. Incomplete requirements (whole context not known/understood by development team) 3. Shame Changes: shaming into scope changes. is it really a viable piece of software if it cant do this. This is useless unless it can do XYZ (COS & Mockups) 4. Wrong Level of understanding 1. Not OWNING the requirement. Understanding how to validate the requirement has been achieved. The team should be able to to not only articulate what the requirement is but also know when it has been successfully delivered. (COS) 2. Unspoken requirements (Context: technical & business ) 5. Wrong People 1. Not getting requirements from the right people (getting requirements from owners vs users) (Understand Who uses the system) 2. Roles in and outside of system not clearly defined 6. Wrong Perspective 1. Epic Splitting (part of the problem being solved but part not addressed now. Integration of stories within an epic can cause additional issues) (Planning for integration with Epic Breakdown) 2. Legitimate Changes in requirements (scope swap) 7. Wrong Priorities 1. Conflicting Priorities among Business communities. Conflicts between users an management and between different groups 2. Gold Plating/Requirement stuffing (What i really meant was... or it wont really be complete if it does not do X) (Prioritization & Value assessment) 8. Wrong Techniques/Tools/Tactics 1. Poor design, architecture, technique or coding practices leads to poor results 2. Code not getting adopted or poor reuse (Inspect & Adapt)
For discussion Purposes only Confidential Page 68 QUESTIONS
For discussion Purposes only Confidential Page 69 Strategic IT services Does your organization have a clear vision for its use of Information technology? Is your organization using the right technologies to enable your business to execute its vision? Does your organization have the right team to execute its vision? Is your organization using the right tactics to execute the vision? Target: Vision Direction Progress • Business/Technology Portfolio Assessments • Business Data Profiling Mapping • Product road mapping, • Support process definition • Product Business Analytics • Change Management Tools: Defining the right Technology Stack • Technology Assessment • Technology Roadmap • Technology Selection Tactics: Optimizing Execution • Process Improvement • Process Assessment, • Process Definition • Process Metric Definition, • Process Analytics • Project Execution • PMO Assessment, • Agile Adoption Planning • Agile coaching and training (Scrum, LEAN), • Project Management Team augmentation • Project Tools Implementation, • Project Execution Analytics Team: Talent Acquisition and Development • Evaluation/Assessment • Strategic Staff Augmentation • Coaching • Training • Leadership development • Succession planning Contact us Revolutionary Performance Management Inc. www.thinkrpm.com 202-360-4932
For discussion Purposes only Confidential Page 70 STUFF I NEED TO ORGANIZE
For discussion Purposes only Confidential Page 71 Agile Team Roles Role: User Experience Designer (UX) Key Activities: Defining the User experience across interfaces including browsers and devices Defining the prototypes Core Skill sets: Key skill sets and strengths required Able to define/refine the UX elements of the architecture to address current and future needs Able to identify and establish key UX practices that lead to code reuse, easy integration, scalability and maintainability Ability to hear the unspoken requirements by understanding what people are experiencing and have become accustomed to using or want to use Transforming requirements into powerful positive experiences for the customers by adjusting to the requirements and feedback. Keeping ahead of the curve on technical trends that make user experiences better including upgrades in current technologies and transitions to new ones. Standard project role comparison: Designer UX and Architect Key differences: Most UI designers are only focused on style sheets, java script or frameworks. By empowering the UX designer to define the architecture and overall experience the UX is able to build an experience from the prototype through deployment that makes cross platform integration and platform upgrade not only possible but expected improvements.
For discussion Purposes only Confidential Page 72 What are we selling Unified Project leadership core teams. Units that supply value throughout the development cycle in key areas: Product Ownership Technical Expertise Talent Development Consistent Structured requirements and testing process Consistent UI development approach (optional) Instant functional teams Consistency in planning Known commodities in process expectations and roles Known delivery styles Consistency in execution Cohesive units easily digest intended scope, and quickly move to execution Continuity in team dynamics Largest variable in software is team turnover. With a consistent approach to onboarding development team members and a focused approach towards indoctrinating with process and tool usage the focus shifts to allowing developers to do what they are being paid to do. Maximize development resource time Reduce onboarding time Increase developer productivity with structured talent development Just add developers and testers
For discussion Purposes only Confidential Page 73 Agile Team Roles Role: Product owner Key Activities: Set product vision and direction Manage customer expectations Manage the project and associated artifacts Core Skill sets: Key skill sets and strengths required Forward thinking visionary Able to decompose concepts into phases or components Technical enough to understand implications of technology decisions Business savvy enough to understand implications of business matters. Able to translate business issues into technical terms and technical issues into business terms. Standard project role comparison: Project Manager Key differences: Product owner is more closely tied to the overall business benefit of the project and its impact over the life span of a product. The PO is keenly interested in the timely delivery of scope as much or more than most stake holders. They also have a vested interest in assembling the best team to consistently deliver efficient value for their product through a series of projects.
For discussion Purposes only Confidential Page 74 Agile Team Roles Role: Scrum Master Key Activities: Manage the project execution process Educate the key stakeholders, executives and team members Remove project/process and task impediments Facilitate scrum process and key activities Core Skill sets: Key skill sets and strengths required Excellent leadership and facilitation skills Able to explain key agile concepts to a variety of audiences Excellent communication skills Expert in the process able to communicate the value of the process nuances and coach participants in the proper way to execute Focused on continuous improvements for the team, management and the product owner and customers alike Standard project role comparison: Project Manager Key differences: The project manager is tasked with planning and navigating issues, risks and facilitating the monitoring controlling and execution of a project in its entirety. While these are scrum master duties the typical pm is also focused on scope management and resources. The product owner is tasked with managing the definition of scope while the scrum master monitors changes.
For discussion Purposes only Confidential Page 75 Agile Team Roles Role: Technical Lead/Architect Key Activities: Set Technical Direction Guide Development resources Provide tactical and strategic Core Skill sets: Key skill sets and strengths required Able to define/refine an architecture to address current and future needs Able to identify and establish key programing practices that lead to code reuse, easy integration, scalability and maintainability Ability to increase the technical acumen of the development team. Ability to view and assess potential enhancements with accurate effort estimations and potential impact analysis on the current infrastructure. Ability to identify talented development team members Standard project role comparison: Senior Developer or Architect Key differences: A technical team lead is given the luxury of focusing on a specific product and architecture while most senior developers are forced to switch context throughout the day. Their focus enables a greater trade off in both better architecture and better practices resulting in higher code quality, efficiency and accuracy of projections and lower total cost of ownership for the code.
For discussion Purposes only Confidential Page 76 Agile Team Roles Role: System Analyst Key Activities: Defining success criteria and conditions of satisfaction Identifying and removing barriers for adoption including Training business users Facilitating transition to maintenance Core Skill sets: Key skill sets and strengths required Highly technical and able to identify and communicate barriers for adoption by business users including personal, technical, process specific issues Deeply analytical and able to determine trends in usage or lack of usage. Able to identify trends in data and application improvement requests as potential enhancements. Able to establish execute and validate test scenarios/conditions of satisfaction Great at identifying and eliminating non-technical barriers in adoption Standard project role comparison: Business Analyst Key differences: A business analyst typically is focused only on the definition of requirements and the validation of the delivery of requirements. The system analyst is both technical and process but more focused on what the application does and does not currently do. They look for reasons people wouldn’t use the application in order to eliminate potential barriers for adoption especially those that don’t require development.
For discussion Purposes only Confidential Page 77 Performance Measures Project Success Budget Scope Time Client Satisfaction Development Team Success Vision Deliverables Scope delivered Speed of Delivery Quality of Delivery Residual Value of delivery Reuse Planned and unplanned value Reduced maintenance Teamwork: Listening Trust Innovation Agile Team Success High Value Delivery Reduced Code Waste High Visibility Development Implementation Self Managed Teams Accountable Transparent Innovative

More Related Content

PDF
Viable Dimensions Company Profile
aghasameer
 
PDF
Senabi_brochure
Som Shuvro Nandi
 
PDF
Oceans group & digital talent transformation sg
Sean Garvey
 
PDF
Digital profile
Ilyas Shareef
 
PDF
The Value Plus Magazine - October GITEX Issue
Redington Value Distribution
 
PDF
Litslink
Pavel Laktionov
 
PDF
Portfolio-Eventus-Faction
Ali Mahboob
 
PPTX
2010aug Capgemini Group Presentation
pimdevogel
 
Viable Dimensions Company Profile
aghasameer
 
Senabi_brochure
Som Shuvro Nandi
 
Oceans group & digital talent transformation sg
Sean Garvey
 
Digital profile
Ilyas Shareef
 
The Value Plus Magazine - October GITEX Issue
Redington Value Distribution
 
Litslink
Pavel Laktionov
 
Portfolio-Eventus-Faction
Ali Mahboob
 
2010aug Capgemini Group Presentation
pimdevogel
 

What's hot (10)

PDF
FDI support services PM&P with Silverlode Consulting
Markus Wellmann
 
PDF
201004 lg cns_brochure
Lahee Kim
 
PDF
Kmp Brochure
InBlackandWhite
 
PDF
T-Byte Agile & AI Operations July 2021
EGBG Services
 
PDF
High Impact Prospecting V15
chuckhip
 
PDF
Building the New Connected Enterprise – Capgemini case study
Capgemini
 
PDF
Gec workshop corporate entrepreneurship march 2015 stefano mizio
Stefano Mizio
 
PDF
The Power of Infographics for AEC Marketers
David Lecours
 
PDF
MindSEO Presentation [EN - 2017]
MindSEO.com
 
PDF
Sodium brochure 2015
SaltJobs
 
FDI support services PM&P with Silverlode Consulting
Markus Wellmann
 
201004 lg cns_brochure
Lahee Kim
 
Kmp Brochure
InBlackandWhite
 
T-Byte Agile & AI Operations July 2021
EGBG Services
 
High Impact Prospecting V15
chuckhip
 
Building the New Connected Enterprise – Capgemini case study
Capgemini
 
Gec workshop corporate entrepreneurship march 2015 stefano mizio
Stefano Mizio
 
The Power of Infographics for AEC Marketers
David Lecours
 
MindSEO Presentation [EN - 2017]
MindSEO.com
 
Sodium brochure 2015
SaltJobs
 
Ad

Similar to Agile Requirements Management (20)

PDF
Doniel Wilson Presents: Surviving the Shift. Agile and its Impact to your Fut...
Liana Underwood
 
PPTX
Modern Agile – What's It Good For? - Jacob Creech - AgileNZ 2017
AgileNZ Conference
 
PPTX
The Secret, Yet Obvious, Ingredient to Sustainable Agility
Ahmed Sidky
 
PPTX
Agility reboot i
Andrew Chum
 
PDF
Agile Project Failures: Root Causes and Corrective Actions
TechWell
 
PDF
Tales of {Good Teams'} Failures - Case Studies, Root Causes & Recommendations
Mirketa Inc
 
PPTX
Agile Software Design and Development Process.pptx
ibrahim0623
 
PPTX
Professional Project Manager Should Be Proficient in Agile
Nitor
 
PDF
A Practical Approach to Agile Adoption - Case Studies from Egypt by Amr Noama...
Agile ME
 
DOCX
Agile Development MethodologiesThree CommunitiesProjec.docx
ADDY50
 
PPT
Ben Mkt 347 Week 4
Robert Harris, Ph.D
 
PDF
Boost your revenue with agile software development
Muhammad Singgih Z.A
 
PPT
Business Analyst As Product Owner
Craig Brown
 
PDF
The Business Analyst’s Critical Role in Agile Projects
TechWell
 
PDF
Becoming an Enterprise SaaS Company | DecisionDesk @ TechPint
John Knific
 
PPTX
Agile for Business
DigitalCatapultDevelopmentPractices
 
PPT
Essential Elements Of Distributed Agile
Vernon Stinebaker
 
PDF
Distributed Agile
Thoughtworks
 
PPT
Are You Really Agile?
mhambalek
 
PDF
Agile Fundamentals for Project Managers.pdf
Borja ARRIZABALAGA URIARTE
 
Doniel Wilson Presents: Surviving the Shift. Agile and its Impact to your Fut...
Liana Underwood
 
Modern Agile – What's It Good For? - Jacob Creech - AgileNZ 2017
AgileNZ Conference
 
The Secret, Yet Obvious, Ingredient to Sustainable Agility
Ahmed Sidky
 
Agility reboot i
Andrew Chum
 
Agile Project Failures: Root Causes and Corrective Actions
TechWell
 
Tales of {Good Teams'} Failures - Case Studies, Root Causes & Recommendations
Mirketa Inc
 
Agile Software Design and Development Process.pptx
ibrahim0623
 
Professional Project Manager Should Be Proficient in Agile
Nitor
 
A Practical Approach to Agile Adoption - Case Studies from Egypt by Amr Noama...
Agile ME
 
Agile Development MethodologiesThree CommunitiesProjec.docx
ADDY50
 
Ben Mkt 347 Week 4
Robert Harris, Ph.D
 
Boost your revenue with agile software development
Muhammad Singgih Z.A
 
Business Analyst As Product Owner
Craig Brown
 
The Business Analyst’s Critical Role in Agile Projects
TechWell
 
Becoming an Enterprise SaaS Company | DecisionDesk @ TechPint
John Knific
 
Agile for Business
DigitalCatapultDevelopmentPractices
 
Essential Elements Of Distributed Agile
Vernon Stinebaker
 
Distributed Agile
Thoughtworks
 
Are You Really Agile?
mhambalek
 
Agile Fundamentals for Project Managers.pdf
Borja ARRIZABALAGA URIARTE
 
Ad

More from Liana Underwood (14)

PDF
7 Steps to Digitizing Your Business
Liana Underwood
 
PDF
The Metrics of Project Management Performance and PMBOK
Liana Underwood
 
PDF
Where to start when you dont know where to start
Liana Underwood
 
PDF
Good, Fast, or Cheap.
Liana Underwood
 
PDF
PM Reston Managing Stakeholders by Robert Godbey
Liana Underwood
 
PDF
Yvette Rivers presents: Real world quality management
Liana Underwood
 
PDF
Melissa Highley presents: Portfolio Management for Everyone 21 Jan v15
Liana Underwood
 
PDF
David Offenkrantz presents Employing PM as a Critical Decision Making Tool 15...
Liana Underwood
 
PDF
Susan Parente Presents: Busting Barriers to Risk Management: PM Reston Lunche...
Liana Underwood
 
PDF
Michael R. Van Dyke: Applying Emotional Intelligence
Liana Underwood
 
PDF
Michael R Van Dyke Applying Emotional Intelligence for PMs
Liana Underwood
 
PDF
Liana Underwood GIS Project Management 16 April 14
Liana Underwood
 
PDF
David Rico Business Value Agile Methods19 Feb 14
Liana Underwood
 
PDF
Clay Springer Soft Skills RestonLuncheon Presentation 15 Jan 14
Liana Underwood
 
7 Steps to Digitizing Your Business
Liana Underwood
 
The Metrics of Project Management Performance and PMBOK
Liana Underwood
 
Where to start when you dont know where to start
Liana Underwood
 
Good, Fast, or Cheap.
Liana Underwood
 
PM Reston Managing Stakeholders by Robert Godbey
Liana Underwood
 
Yvette Rivers presents: Real world quality management
Liana Underwood
 
Melissa Highley presents: Portfolio Management for Everyone 21 Jan v15
Liana Underwood
 
David Offenkrantz presents Employing PM as a Critical Decision Making Tool 15...
Liana Underwood
 
Susan Parente Presents: Busting Barriers to Risk Management: PM Reston Lunche...
Liana Underwood
 
Michael R. Van Dyke: Applying Emotional Intelligence
Liana Underwood
 
Michael R Van Dyke Applying Emotional Intelligence for PMs
Liana Underwood
 
Liana Underwood GIS Project Management 16 April 14
Liana Underwood
 
David Rico Business Value Agile Methods19 Feb 14
Liana Underwood
 
Clay Springer Soft Skills RestonLuncheon Presentation 15 Jan 14
Liana Underwood
 

Recently uploaded (20)

PPTX
Business Ethics - An introduction and its overview.pptx
Keerthana Chinnathambi
 
PDF
IFRS Notes in your pocket for study all the time
jjj81507
 
PDF
Dr. Enrique Segura Ense Group - A Self-Made Entrepreneur And Executive
Dr. Enrique Segura Ense Group
 
PPTX
ICG2025_ICG 6th steering committee 30-8-24.pptx
AtiarRahaman5
 
PPTX
Dragon_Fruit_Cultivation_in Nepal ppt.pptx
UmeshTimilsina1
 
PDF
kom-180-proposal-for-a-directive-amending-directive-2014-45-eu-and-directive-...
nlusch08
 
PDF
Traveri Digital Marketing Seminar 2025 by Corey and Jessica Perlman
Corey Perlman, Social Media Speaker and Consultant
 
PDF
Unit 1 Cost Accounting - Cost sheet
MANJU N
 
PPTX
Probability Distribution, binomial distribution, poisson distribution
gayusakktivel
 
PDF
Reconciliation AND MEMORANDUM RECONCILATION
MANJU N
 
PDF
Nidhal Samdaie CV - International Business Consultant
Nidhal Samdaie
 
PDF
Elevate Cleaning Efficiency Using Tallfly Hair Remover Roller Factory Expertise
farsookmon97766765
 
PDF
SIMNET Inc – 2023’s Most Trusted IT Services & Solution Provider
sidnik500
 
PPTX
HR Introduction Slide (1).pptx on hr intro
suhanidwivedi227
 
PDF
Business model innovation report 2022.pdf
pradvapal
 
PPTX
The Marketing Journey - Tracey Phillips - Marketing Matters 7-2025.pptx
shannonzipoy2
 
PDF
Katrina Stoneking: Shaking Up the Alcohol Beverage Industry
CIO WOMEN MAGAIZNE CIO WOMEN MAGAIZNE
 
DOCX
Business Management - unit 1 and 2
anithak410
 
PDF
MSPs in 10 Words - Created by US MSP Network
Mayur Gudka
 
PDF
Types of control:Qualitative vs Quantitative
reshmaaslm06
 
Business Ethics - An introduction and its overview.pptx
Keerthana Chinnathambi
 
IFRS Notes in your pocket for study all the time
jjj81507
 
Dr. Enrique Segura Ense Group - A Self-Made Entrepreneur And Executive
Dr. Enrique Segura Ense Group
 
ICG2025_ICG 6th steering committee 30-8-24.pptx
AtiarRahaman5
 
Dragon_Fruit_Cultivation_in Nepal ppt.pptx
UmeshTimilsina1
 
kom-180-proposal-for-a-directive-amending-directive-2014-45-eu-and-directive-...
nlusch08
 
Traveri Digital Marketing Seminar 2025 by Corey and Jessica Perlman
Corey Perlman, Social Media Speaker and Consultant
 
Unit 1 Cost Accounting - Cost sheet
MANJU N
 
Probability Distribution, binomial distribution, poisson distribution
gayusakktivel
 
Reconciliation AND MEMORANDUM RECONCILATION
MANJU N
 
Nidhal Samdaie CV - International Business Consultant
Nidhal Samdaie
 
Elevate Cleaning Efficiency Using Tallfly Hair Remover Roller Factory Expertise
farsookmon97766765
 
SIMNET Inc – 2023’s Most Trusted IT Services & Solution Provider
sidnik500
 
HR Introduction Slide (1).pptx on hr intro
suhanidwivedi227
 
Business model innovation report 2022.pdf
pradvapal
 
The Marketing Journey - Tracey Phillips - Marketing Matters 7-2025.pptx
shannonzipoy2
 
Katrina Stoneking: Shaking Up the Alcohol Beverage Industry
CIO WOMEN MAGAIZNE CIO WOMEN MAGAIZNE
 
Business Management - unit 1 and 2
anithak410
 
MSPs in 10 Words - Created by US MSP Network
Mayur Gudka
 
Types of control:Qualitative vs Quantitative
reshmaaslm06
 

Agile Requirements Management

  • 1. For discussion Purposes only Confidential Page 1 Revolutionary Performance Management
  • 2. For discussion Purposes only Confidential Page 2 About the speaker: Don Wilson gained his Bachelors in Computer Science from North Carolina A&T State University and jumped immediately into solving business problems with technology. He spent the first part of his career in with Ernst & Young and Deloitte planning and implementing multimillion dollar software packages for fortune 500 companies. He translated the strategic, process and technical knowledge into a success as an architect and then project manager for software development and implementation projects. While making progress possible with software is a passion for Don his spare time is spent on the sidelines of his sons soccer games and the isle of his daughters ballet and violin recitals or a blogging event for his wife. If those aren't going on he's golfing fishing or watching football(any kind).
  • 3. For discussion Purposes only Confidential Page 3 Definition: Agile ag·ile [aj-uhl, -ahyl] Adjective 1. quick and well-coordinated in movement; lithe: an agile leap. 2. active; lively: an agile person. 3. marked by an ability to think quickly; mentally acute or aware: She's 95 and still very agile. Origin: 1570–80; earlier agil < Latin agilis, equivalent to ag- (base of agere to do) + -ilis -ile Related forms ag·ile·ly, adverb ag·ile·ness, noun un·ag·ile, adjective un·ag·ile·ly, adverb Synonyms 1. nimble, sprightly. 2. brisk, spry. Antonyms 1. awkward. 2. sluggish, lethargic. Dictionary.com Unabridged Based on the Random House Dictionary, © Random House, Inc. 2014.
  • 4. For discussion Purposes only Confidential Page 4 Definition: Requirements re·quire·ment riˈkwīrmənt/ Noun Synonyms: need, wish, demand, want, necessity, essential, prereq uisite, stipulation “good spelling is a requirement of the job" noun 1.a thing that is needed or wanted. "choose the type of window that suits your requirements best" •a thing that is compulsory; a necessary condition. "applicants must satisfy the normal entry requirements"
  • 5. For discussion Purposes only Confidential Page 5 Agility in life Agile Animals Agility in Sports Agility In Traffic Agility in Business
  • 6. For discussion Purposes only Confidential Page 6 BACKGROUND
  • 7. For discussion Purposes only Confidential Page 7 Manifesto 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 tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more. Kent Beck Mike Beedle Arie van Bennekum Alistair Cockburn Ward Cunningham Martin Fowler James Grenning Jim Highsmith Andrew Hunt Ron Jeffries Jon Kern Brian Marick Robert C. Martin Steve Mellor Ken Schwaber Jeff Sutherland Dave Thomas
  • 8. For discussion Purposes only Confidential Page 8 Agile Manifesto Principles We follow these principles: 1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. 2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. 3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. 4. Business people and developers must work together daily throughout the project. 5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. 6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
  • 9. For discussion Purposes only Confidential Page 9 Agile Manifesto Principles We follow these principles: 7. Working software IS the primary measure of progress. 8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. 9. Continuous attention to technical excellence and good design enhances agility. 10.Simplicity--the art of maximizing the amount of work not done--is essential. 11.The best architectures, requirements, and designs emerge from self- organizing teams. 12.At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
  • 10. For discussion Purposes only Confidential Page 10 ADOPTION
  • 11. For discussion Purposes only Confidential Page 11 Adoption Rates
  • 12. For discussion Purposes only Confidential Page 12 Agile Success According to the 2012 CHAOS report, Agile succeeds three times more often than waterfall.
  • 13. For discussion Purposes only Confidential Page 13 Why Scrum Source: 7th State of Agile Development Survey by VersionOne
  • 14. For discussion Purposes only Confidential Page 14 AGILE IN REQUIREMENTS
  • 15. For discussion Purposes only Confidential Page 15 What are the benefits of Agile More software that is relevant Higher Customer satisfaction Higher Trust Level Shorter Wait times Shorter Development cycles ) More frequent delivery More inspection opportunities Ability to change direction
  • 16. For discussion Purposes only Confidential Page 16 What are the Risks to Success 1. Wrong Time or Place 1. Good ideas coming only after code complete 2. Good feedback from management or others not directly related to the project 2. Wrong Ideas 1. Not understanding what needs to be built 2. Assuming what needs to be built 3. Wrong Context 1. Not understanding the context of requirements 2. Incomplete requirements (whole context not known/understood by development team) 3. Shame Changes: shaming into scope changes. is it really a viable piece of software if it cant do this. This is useless unless it can do XYZ 4. Wrong Level of understanding 1. Not OWNING the requirement. Understanding how to validate the requirement has been achieved. The team should be able to to not only articulate what the requirement is but also know when it has been successfully delivered. 2. Unspoken requirements 5. Wrong People 1. Not getting requirements from the right people (getting requirements from owners vs users) 2. Roles in and outside of system not clearly defined 6. Wrong Perspective 1. Epic Splitting (part of the problem being solved but part not addressed now. Integration of stories within an epic can cause additional issues) 2. Legitimate Changes in requirements 7. Wrong Priorities 1. Conflicting Priorities among Business communities. Conflicts between users an management and between different groups 2. Gold Plating/Requirement stuffing (What i really meant was... or it wont really be complete if it does not do X) 8. Wrong Techniques/Tools/Tactics 1. Poor design, architecture, technique or coding practices leads to poor results 2. Code not getting adopted or poor reuse
  • 17. For discussion Purposes only Confidential Page 17 Keys to addressing Risks 1. Understand your process and its stakeholders 2. Educate 3. Proactively Listen 4. Understand the big picture 5. Work Progressive elaboration into your process 6. Work on what matters 7. Inspect and Adapt
  • 18. For discussion Purposes only Confidential Page 18 KNOW YOUR PROCESS
  • 19. For discussion Purposes only Confidential Page 19 Know your process & role first Explain your process to the customer Help them understand the process their idea will go through to help deliver value Know how your audience changes throughout the process
  • 20. For discussion Purposes only Confidential Page 20 Scrum Team Roles Aspect Scrum Master Product Owner Team Key Activities Educate Facilitate Key Ceremonies Remove Impediments Protect Team Helping the team b Create backlog Assign Value and Prioritize Stories Break Epics into stories Clarify Requirement inquiries Facilitate Adoption Estimates Prototypes Spikes Develops Tests Major Contribution Education & Impediment Removal Process improvements Vision & Roadmap & Secure funding/Adoption Creating Working Code Measured by Transparency, Efficiency and Effectiveness of the scrum process Roadmap Ability to represent stakeholder intrests Velocity Value Quality Code Core Skills • Excellent leadership and facilitation skills • Able to explain key agile concepts to a variety of audiences • Excellent communication skills • Expert in the process able to communicate the value of the process nuances and coach participants in the proper way to execute • Focused on continuous improvements for the team, management and the product owner and customers alike • Forward thinking visionary • Able to decompose concepts into phases or components • Technical enough to understand implications of technology decisions • Business savvy enough to understand implications of business matters. • Able to translate business issues into technical terms and technical issues into business terms. • Able to define/refine an architecture to address current and future needs • Able to identify and establish key programing practices that lead to code reuse, easy integration, scalability and maintainability • Ability to increase the technical acumen of the development team. • Ability to view and assess potential enhancements with accurate effort estimations and potential impact analysis on the current infrastructure. • Ability to identify talented
  • 21. For discussion Purposes only Confidential Page 21 Initiate Core Scrum Concepts Value Team Size Scrum Meeting Cadence Self Organizing Team Colocation Sushi not Sashimi Chickens & Pigs Spikes Prototypes Burn down Empirical Information Radiator Scrum Board Backlog Stories Epics Story Points Conditions of Satisfaction Done Done Shippable unit
  • 22. For discussion Purposes only Confidential Page 22 Establish the elements Artifacts Working Code Prototypes Backlog Retrospective Notes Scrum Board (or app) Burn down Charts (sprint, Epic, Product) Roadmap Release Schedule Budgets and Forecasts Portfolio and Project status reports Meetings Requirements Review sessions Road Mapping sessions Bi-weekly Client Prioritization sessions (weekly) Estimation Grooming Sprint Planning Daily Standup Sprint Demo Sprint Retrospective
  • 23. For discussion Purposes only Confidential Page 23
  • 24. For discussion Purposes only Confidential Page 24 Life of a requirement Ideas Elaborate QuantifyDeliver Inspect & Adapt
  • 25. For discussion Purposes only Confidential Page 25 Planning at Multiple Levels Source: Agile Estimating and Planning
  • 26. For discussion Purposes only Confidential Page 26 EDUCATE YOUR STAKEHOLDERS
  • 27. For discussion Purposes only Confidential Page 27 Communicate Profusely Management Trust comes with results (doing what you said you'd do when you said you'd do it) Over communicate Steering committees/PMO Governance Financial reporting Status Reporting Budgeting Arcuate Estimations critical Use backlog grooming and SP estimating in projecting future budget requirements Calculate EVM if necessary Everyone else Educate, Explain value, laud victories, readily admit mistakes and plans to address them Time dependent interactions with cadence where possible
  • 28. For discussion Purposes only Confidential Page 28 Agile Customer Alignment Educate Understand what’s valuable to the customer. Create an environment for success Educate them on the process, what’s different, what to expect and what’s needed from them What's different, Time Boxed Delivery More Frequent releases, Less documentation More responsiveness and involvement from them (decisions in 5 minutes) Keep them informed with a consistent stream of information, Each timebox has a frequency (cadence/rhythm) Help them to understand the cadence Frequent inspection Communicate help them to know you truly intend to represent their priorities as an advocate Planning Long term planning Mid Term planning Short term planning Delivery Frequent inspection Adapting to the gaps Scope is still important Changes are encouraged if they improve value but the triangle still needs to be maintained Changes still have an impact: financial impact Other users Working with multiple clients & balancing priorities Transparency, Fairness, Consistency
  • 29. For discussion Purposes only Confidential Page 29
  • 30. For discussion Purposes only Confidential Page 30 Addressing the Risks Risk 1. Wrong Time or Place 1. Good ideas coming only after code complete 2. Good feedback from management or others not directly related to the project Fix Communicate early and often about the opportunities to provide input. Communicate to: Team Customers Stakeholders/managem ent Others
  • 31. For discussion Purposes only Confidential Page 31 PROACTIVELY LISTEN
  • 32. For discussion Purposes only Confidential Page 32 Understanding has No Shortcuts • Requirements are about communicating what is desired even if its not explicit. • The life of a requirement needs to be understood from thought to adoption including its appearance in many forms to many parties. • Traceability should extend beyond deployment to understand the usage rates patterns and errors. Its also good to know who asked for it and their history
  • 33. For discussion Purposes only Confidential Page 33 How do we Understand
  • 34. For discussion Purposes only Confidential Page 34 Proactive Listening Hearing out the requirements in the right context with the right people involved is the first step in refining requirements for success Subjects, Verbs, Objects Confirm Understanding Avoid Extremes Writing everything Not writing anything The point is understanding not just understanding for temporary recall but understanding so that you can represent the matter to someone else.
  • 35. For discussion Purposes only Confidential Page 35 Progressive Elaboration Understanding Takes time. Agile is more interested in communication over documentation. Elaboration Occurs in Stages Understand Macro Requirement Understand Context Outline Solution & Get feedback Provide more detailed solution & Get feedback Provide mockup & Get feedback Prototype and get feedback Develop and get feedback Deploy and get feedback
  • 36. For discussion Purposes only Confidential Page 36 Progressive Elaboration
  • 37. For discussion Purposes only Confidential Page 37 Addressing the Risks Risk 2. Wrong Ideas 1. Not understanding what needs to be built 2. Assuming what needs to be built Fix Understanding the big picture Proactive Listening Progressive elaboration
  • 38. For discussion Purposes only Confidential Page 38 UNDERSTAND THE BIG PICTURE
  • 39. For discussion Purposes only Confidential Page 39 Roadmap Volunteer Portal RoadmapDec Jan Feb Mar April May Jun July Aug Sept Oct Nov Dec R6 11/10 R7 12/15 R8 2/2 R10 6/21 R12 12/06 RX Dev UAT/BF UI R Requirements User Interface Design Development User Acceptance Testing and Bug Fixes Production Release Sprint 20 Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5 Sprint 6 Sprint 7 Sprint 8 Sprint 9 Sprint 10 Sprint 11 Sprint 12 Sprint 1 Supervisor flow Group 2 Epic 1 Group 3 Epic 2 Volunteer flow Group 2 Epic 2 Group 2 Epic 3 Add Host Edit Host: Marketing Contact Edit Host: Contact Selection Report Updates Course Loading Tool Edit Host Capabilities Modify Email Address Submitter Flow Edit Course Reports Utilities and Transition Host Flow Receipt Management ERP/Legacy Integration Exports and Messaging Volunteer Flow Staff Flow Locator Updates R11 9/20 R9 4/18 R8.1 4/3 Group 1 Epic 1 UAT – DSP Host Group 3 Epic 1 G1 – Epic 2 Mutually Beneficial Epic 1 Approver Flow R11 UAT Group 3 Epic 4 R12 UAT R10 UAT
  • 40. For discussion Purposes only Confidential Page 40 Story Board: Big Picture
  • 41. For discussion Purposes only Confidential Page 41 Addressing the Risks Risk 3. Wrong Context 1. Not understanding the context of requirements 2. Incomplete requirements (whole context not known/understood by development team) 3. Shame Changes: shaming into scope changes. is it really a viable piece of software if it cant do this. This is useless unless it can do XYZ Fix Progressive elaboration Process Context System Context Mockups Prototypes Conditions of Satisfaction
  • 42. For discussion Purposes only Confidential Page 42 Story Board: Process Context
  • 43. For discussion Purposes only Confidential Page 43 Addressing the Risks Risk 4. Wrong Level of understanding 1. Not OWNING the requirement. Understanding how to validate the requirement has been achieved. The team should be able to to not only articulate what the requirement is but also know when it has been successfully delivered. 2. Unspoken requirements (Context: technical & business ) Fix Proactive listening Understanding Why Progressive elaboration Process Context System Context Mockups Prototypes Conditions of Satisfaction
  • 44. For discussion Purposes only Confidential Page 44 Edit Mileage Reimbursement Entry Description: This page provides allows a volunteer or designated proxy to Add or Edit a single Mileage reimbursement expense entry # Action Logic Data 1 Date Slection NO limitation on dates to be selected (NEED CONFIRMATION Required 2 Select Expense activity List Populated from table Required 3 Enter Explaination Required LIMIT 255 Characters 4 Enter Miles Required (3 digits after decimal point) 5 Update Saves and returns to the expense details screeen 6 Cancel Returns to the expense details screen 7 8 9 Accessing User Access Conditions Display logic Volunteers Visible Access only to personal list Staff/Proxy entry Visible Access to all volunteers via lookup Approvers Not visible Finance Liason Not visible # Action/ Triggers To Subject Message Body Exceed Character limit for Explainatio n Add Success Successfully Added a mileage Expense Add Error Error in adding milage expense # Business Rule Mileage rate per program needs to be defined and configured in the admin tool (or at least in a configuration file) Requirement from TA to allow a lower mileage entry rate per submission (Not per entry) (ADD TO SCOPE ISSUES) (Not an issue for States –DSP will confirm) Need Expense Activity Lists from DSP/States and Expense Types Are there any limitations on Miles or expenses per day or per type per day Add Delete buton Story Board Page Example
  • 45. For discussion Purposes only Confidential Page 45 Conditions of Satisfaction The system is considered complete if it meets these conditions. Conditions can be Functional Conditions Technical Conditions Pre-Conditions The COS serve as a baseline for both feature validation and traceability
  • 46. For discussion Purposes only Confidential Page 46 Addressing the Risks Risk 5. Wrong People 1. Not getting requirements from the right people (getting requirements from owners vs users) (Understand Who uses the system) 2. Roles in and outside of system not clearly defined Fix Educating the users Proactive listening Progressive elaboration Process Context System Context Mockups Prototypes Conditions of Satisfaction
  • 47. For discussion Purposes only Confidential Page 47
  • 48. For discussion Purposes only Confidential Page 48 Decomposing Epics
  • 49. For discussion Purposes only Confidential Page 49 Addressing the Risks Risk 6. Wrong Perspective 1. Epic Splitting (part of the problem being solved but part not addressed now. Integration of stories within an epic can cause additional issues) (Planning for integration with Epic Breakdown) 2. Legitimate Changes in requirements (scope swap) Fix Epic Breakdown Scope Swapping Backlog Overview Backlog Assessments Conditions of Satisfaction
  • 50. For discussion Purposes only Confidential Page 50 THINK LEAN ELIMINATE WASTE
  • 51. For discussion Purposes only Confidential Page 51 Think Value Source: Jim Johnson. The Standish Group International Inc. 2002.
  • 52. For discussion Purposes only Confidential Page 52 Seven Wastes Toyota Production System [1] Inventory Overproduction Extra Processing Transportation Waiting Motion Defects Software Development [2] Partially Done Work Extra Features Relearning Handoffs Delays Task Switching Defects 1. Shingo, Shigeo. A Study of the Toyota Production System. Productivity Press, 1981. 2. Poppendieck, Mary and Tom. Implementing Lean Software Development: From Concept to Cash. Addison-Wesley, 2006.
  • 53. For discussion Purposes only Confidential Page 53 Assessing Value Understand why its being requested, who benefits from the request and how. Also identify the ideal scenario. Set a formula Weighting what’s important to your organization Auto calculate base on entries in each area Be consistent in ratings (keep them relative) Examlpes: Attract Customer or enhances customer experience Legal Corporate Dashboard/Score card Goal Impact Impacts Business Continuity Time Savings Increase Capacity Impact Community Impact Multiple Groups Cost Savings Increase Revenue
  • 54. For discussion Purposes only Confidential Page 54 Assessing Value
  • 55. For discussion Purposes only Confidential Page 55 Right Sizing Stories Relative size Relative complexity Independence Factor assumptions & Constraints Challenges to be faced Unknowns Assumed Effort
  • 56. For discussion Purposes only Confidential Page 56 Story Point Estimating
  • 57. For discussion Purposes only Confidential Page 57 Addressing the Risks Risk 7. Wrong Priorities 1. Conflicting Priorities among Business communities. Conflicts between users an management and between different groups 2. Gold Plating/Requirement stuffing (What i really meant was... or it wont really be complete if it does not do X) (Prioritization & Value assessment) Fix Value Evaluation Story Point Estimation Educating the users Proactive Prioritization Roadmap
  • 58. For discussion Purposes only Confidential Page 58 The Backlog
  • 59. For discussion Purposes only Confidential Page 59 Traceability Coverage Requesting party, Adoption and Usage Relationship to others Parent items Children
  • 60. For discussion Purposes only Confidential Page 60 Value Evaluation Scope swaps Remaining work Delivered items
  • 61. For discussion Purposes only Confidential Page 61 Backlog Assessment
  • 62. For discussion Purposes only Confidential Page 62 Backlog Overview
  • 63. For discussion Purposes only Confidential Page 63 Inspect and Adapt Opportunities Customer opportunities for inspection & adjustment Requirements: Idea Discussed and translated to story Grooming/Planning: Effort Estimation & Value assignment & Priority Assignment Design Client Prioritization sessions (weekly) Road Mapping sessions Bi-weekly Sprint Review Demonstration UAT Production Team Opportunities for inspection & adjustment Grooming Sprint Planning Daily Standup Sprint Review Retrospective Management Opportunities for inspection & adjustment Project Initiation Project Estimating Project Budget authorization Status reports (Sprint specific, Project Specific) (indicate overall progress in terms of scope, resources and time) Steering committee/PMO Meetings (Sprint specific, Project Specific) Lessons Learned Others: Grooming Invited to planning Scrum of Scrum Sessions
  • 64. For discussion Purposes only Confidential Page 64 Addressing the Risks Risk 8. Wrong Techniques/Tools/Tactics 1. Poor design, architecture, technique or coding practices leads to poor results 2. Code not getting adopted or poor reuse (Inspect & Adapt) Fix Backlog Assessment Proactive Prioritization Roadmap Inspect and Adapt Team Tactics Technologies Process
  • 65. For discussion Purposes only Confidential Page 65 RECAP
  • 66. For discussion Purposes only Confidential Page 66 Performance Measures Project Success Budget Scope Time Client Satisfaction Development Team Success Vision Deliverables Scope delivered Speed of Delivery Quality of Delivery Residual Value of delivery Reuse Planned and unplanned value Reduced maintenance Teamwork: Listening Trust Innovation Agile Team Success High Value Delivery Reduced Code Waste High Visibility Development Implementation Self Managed Teams Accountable Transparent Innovative
  • 67. For discussion Purposes only Confidential Page 67 What are the Solutions 1. Wrong Time or Place (Process) 1. Good ideas coming only after code complete 2. Good feedback from management or others not directly related to the project 2. Wrong Ideas 1. Not understanding what needs to be built (Big picture) 2. Assuming what needs to be built (Confirm with Pro Elab) 3. Wrong Context 1. Not understanding the context of requirements 2. Incomplete requirements (whole context not known/understood by development team) 3. Shame Changes: shaming into scope changes. is it really a viable piece of software if it cant do this. This is useless unless it can do XYZ (COS & Mockups) 4. Wrong Level of understanding 1. Not OWNING the requirement. Understanding how to validate the requirement has been achieved. The team should be able to to not only articulate what the requirement is but also know when it has been successfully delivered. (COS) 2. Unspoken requirements (Context: technical & business ) 5. Wrong People 1. Not getting requirements from the right people (getting requirements from owners vs users) (Understand Who uses the system) 2. Roles in and outside of system not clearly defined 6. Wrong Perspective 1. Epic Splitting (part of the problem being solved but part not addressed now. Integration of stories within an epic can cause additional issues) (Planning for integration with Epic Breakdown) 2. Legitimate Changes in requirements (scope swap) 7. Wrong Priorities 1. Conflicting Priorities among Business communities. Conflicts between users an management and between different groups 2. Gold Plating/Requirement stuffing (What i really meant was... or it wont really be complete if it does not do X) (Prioritization & Value assessment) 8. Wrong Techniques/Tools/Tactics 1. Poor design, architecture, technique or coding practices leads to poor results 2. Code not getting adopted or poor reuse (Inspect & Adapt)
  • 68. For discussion Purposes only Confidential Page 68 QUESTIONS
  • 69. For discussion Purposes only Confidential Page 69 Strategic IT services Does your organization have a clear vision for its use of Information technology? Is your organization using the right technologies to enable your business to execute its vision? Does your organization have the right team to execute its vision? Is your organization using the right tactics to execute the vision? Target: Vision Direction Progress • Business/Technology Portfolio Assessments • Business Data Profiling Mapping • Product road mapping, • Support process definition • Product Business Analytics • Change Management Tools: Defining the right Technology Stack • Technology Assessment • Technology Roadmap • Technology Selection Tactics: Optimizing Execution • Process Improvement • Process Assessment, • Process Definition • Process Metric Definition, • Process Analytics • Project Execution • PMO Assessment, • Agile Adoption Planning • Agile coaching and training (Scrum, LEAN), • Project Management Team augmentation • Project Tools Implementation, • Project Execution Analytics Team: Talent Acquisition and Development • Evaluation/Assessment • Strategic Staff Augmentation • Coaching • Training • Leadership development • Succession planning Contact us Revolutionary Performance Management Inc. www.thinkrpm.com 202-360-4932
  • 70. For discussion Purposes only Confidential Page 70 STUFF I NEED TO ORGANIZE
  • 71. For discussion Purposes only Confidential Page 71 Agile Team Roles Role: User Experience Designer (UX) Key Activities: Defining the User experience across interfaces including browsers and devices Defining the prototypes Core Skill sets: Key skill sets and strengths required Able to define/refine the UX elements of the architecture to address current and future needs Able to identify and establish key UX practices that lead to code reuse, easy integration, scalability and maintainability Ability to hear the unspoken requirements by understanding what people are experiencing and have become accustomed to using or want to use Transforming requirements into powerful positive experiences for the customers by adjusting to the requirements and feedback. Keeping ahead of the curve on technical trends that make user experiences better including upgrades in current technologies and transitions to new ones. Standard project role comparison: Designer UX and Architect Key differences: Most UI designers are only focused on style sheets, java script or frameworks. By empowering the UX designer to define the architecture and overall experience the UX is able to build an experience from the prototype through deployment that makes cross platform integration and platform upgrade not only possible but expected improvements.
  • 72. For discussion Purposes only Confidential Page 72 What are we selling Unified Project leadership core teams. Units that supply value throughout the development cycle in key areas: Product Ownership Technical Expertise Talent Development Consistent Structured requirements and testing process Consistent UI development approach (optional) Instant functional teams Consistency in planning Known commodities in process expectations and roles Known delivery styles Consistency in execution Cohesive units easily digest intended scope, and quickly move to execution Continuity in team dynamics Largest variable in software is team turnover. With a consistent approach to onboarding development team members and a focused approach towards indoctrinating with process and tool usage the focus shifts to allowing developers to do what they are being paid to do. Maximize development resource time Reduce onboarding time Increase developer productivity with structured talent development Just add developers and testers
  • 73. For discussion Purposes only Confidential Page 73 Agile Team Roles Role: Product owner Key Activities: Set product vision and direction Manage customer expectations Manage the project and associated artifacts Core Skill sets: Key skill sets and strengths required Forward thinking visionary Able to decompose concepts into phases or components Technical enough to understand implications of technology decisions Business savvy enough to understand implications of business matters. Able to translate business issues into technical terms and technical issues into business terms. Standard project role comparison: Project Manager Key differences: Product owner is more closely tied to the overall business benefit of the project and its impact over the life span of a product. The PO is keenly interested in the timely delivery of scope as much or more than most stake holders. They also have a vested interest in assembling the best team to consistently deliver efficient value for their product through a series of projects.
  • 74. For discussion Purposes only Confidential Page 74 Agile Team Roles Role: Scrum Master Key Activities: Manage the project execution process Educate the key stakeholders, executives and team members Remove project/process and task impediments Facilitate scrum process and key activities Core Skill sets: Key skill sets and strengths required Excellent leadership and facilitation skills Able to explain key agile concepts to a variety of audiences Excellent communication skills Expert in the process able to communicate the value of the process nuances and coach participants in the proper way to execute Focused on continuous improvements for the team, management and the product owner and customers alike Standard project role comparison: Project Manager Key differences: The project manager is tasked with planning and navigating issues, risks and facilitating the monitoring controlling and execution of a project in its entirety. While these are scrum master duties the typical pm is also focused on scope management and resources. The product owner is tasked with managing the definition of scope while the scrum master monitors changes.
  • 75. For discussion Purposes only Confidential Page 75 Agile Team Roles Role: Technical Lead/Architect Key Activities: Set Technical Direction Guide Development resources Provide tactical and strategic Core Skill sets: Key skill sets and strengths required Able to define/refine an architecture to address current and future needs Able to identify and establish key programing practices that lead to code reuse, easy integration, scalability and maintainability Ability to increase the technical acumen of the development team. Ability to view and assess potential enhancements with accurate effort estimations and potential impact analysis on the current infrastructure. Ability to identify talented development team members Standard project role comparison: Senior Developer or Architect Key differences: A technical team lead is given the luxury of focusing on a specific product and architecture while most senior developers are forced to switch context throughout the day. Their focus enables a greater trade off in both better architecture and better practices resulting in higher code quality, efficiency and accuracy of projections and lower total cost of ownership for the code.
  • 76. For discussion Purposes only Confidential Page 76 Agile Team Roles Role: System Analyst Key Activities: Defining success criteria and conditions of satisfaction Identifying and removing barriers for adoption including Training business users Facilitating transition to maintenance Core Skill sets: Key skill sets and strengths required Highly technical and able to identify and communicate barriers for adoption by business users including personal, technical, process specific issues Deeply analytical and able to determine trends in usage or lack of usage. Able to identify trends in data and application improvement requests as potential enhancements. Able to establish execute and validate test scenarios/conditions of satisfaction Great at identifying and eliminating non-technical barriers in adoption Standard project role comparison: Business Analyst Key differences: A business analyst typically is focused only on the definition of requirements and the validation of the delivery of requirements. The system analyst is both technical and process but more focused on what the application does and does not currently do. They look for reasons people wouldn’t use the application in order to eliminate potential barriers for adoption especially those that don’t require development.
  • 77. For discussion Purposes only Confidential Page 77 Performance Measures Project Success Budget Scope Time Client Satisfaction Development Team Success Vision Deliverables Scope delivered Speed of Delivery Quality of Delivery Residual Value of delivery Reuse Planned and unplanned value Reduced maintenance Teamwork: Listening Trust Innovation Agile Team Success High Value Delivery Reduced Code Waste High Visibility Development Implementation Self Managed Teams Accountable Transparent Innovative