Envisioning improving productivity and qaulity through better backlogs agile portugal


Published on

Published in: Business, Technology
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Envisioning improving productivity and qaulity through better backlogs agile portugal

  1. 1. Envisioning - Improving Productivity and Quality through Better Backlogs Keynote Agile Portugal 2010 Dave Thomas dave@bedarra.com Bedarra Research Labs, Object Mentor Carleton University Canada, Queensland University of Technology Australia ©2010 Bedarra Research Labs. All rights reserved. Outline We love Agile but .... It’s ALL in your Backlogs! Why Envision? Lean and Agile In The Large Envisioning in Practice Flow Team and Roles Practices Q&A ©2009 Bedarra Research Labs. All rights reserved.
  2. 2. We love Agile Development BUT ... There are really just a couple of problems Productivity Quality Predictability/Estimates Re Te Management of Expectations qu st Product Owners Availability ire in g? m Reduce Owner Burnout en ! Requirements Churn ts ?! Portfolio Management Reduce Rework Reduce Integration Costs Not Collocated .... ©2009 Bedarra Research Labs. All rights reserved. Predictability, Quality, Productivity, Agility and Value Agility Value Productivity Needs 5 – 15% Predictability Agile Surveys show Scrum Scrum increases morale and productivity, but only TDD TDD impacts quality Quality ©2004 Bedarra Research Labs. All rights reserved.
  3. 3. It’s All in Backlogs! Evidence for Action Lumpy Stories – sizes, estimates, clarity Story Rework Due To Changing Requirements Uncompleted Stories Story Rework Due to Integration Problems Missing Important Functionality Done but not usable, poor performance Done doesn’t mean acceptance tested? More stories keep getting added to the backlog Lack of business Value/Tangibility Blocked on Another Team Blocked waiting on Product Owner All resources 100% + allocated ©2009 Bedarra Research Labs. All rights reserved. The Fundamental Problem - Requirements 67% of all projects failed, late, over budget, or under featured. 35% of those projects identified lack of user input, incomplete requirements, and changing requirements as the problem. ? What the user What the developer thinks he’s getting… thinks he’s delivering… Source: Standish Group. Chaos Reports. Challenged Projects
  4. 4. Too Many Requirements versus Too Few The Waterfall Pitfall Plan ‘everything’ before you do ‘anything’ until… It’s 2 years late, 173% over budget, kinda buggy, & costs $32,345.99… But “it does everything you’d ever want to do!” The ‘Potential’ Agile Pitfall “Planning, shmanning, I need to add 1+1, so let’s just build it!” On time, on budget, and we’re giving it away as a beta. “It’s bug-free, it works, and it adds 1+1!” Darn… now how do we add all the features we never had time to think about? Envisioning gives Agile some breathing room… Allows us to understand enough of the vision of ‘tomorrow’… Top 10 Things To Succeed in a Large Transition 1. Lean and Agile Assessment 2. Establish Realistic Expectations for Predictability, Quality and Productivity 3. Plan for Systemic Change 4. Establish a Change Management Plan – Role/Job Changes, Governance, Transition Team, Communications … 5. Implement the CI Infrastructure 6. Implement the Automated Measurement Infrastructure 7. Decouple Legacy Code 8. Implement a Lean Organization Structure with a Strong Technical Ladder 9. Implement the Feature and Component /Platform Team Structure 10. Use Experienced Trainers and Coaches – Technical, People, Management Need Systemic Organizational Change 18 – 36 months
  5. 5. Large Scale - Social Engineering Common Culture Values and Vision Common Vocabulary, Practices, Tools Common Tools and Global Transparency Empower Distributed Teams – Skype, Live Boards, Developers Travel Directing transitions to Coaching and Mentoring Use Playing Coaches to share vision and experiences DONE Means Test – Our Code Doesn’t Smell Align Individual/Team Compensation with Desired Behavior • Predictable Delivery • Quality Delivery • Teamwork • Early Problem Identification and Resolution Playing Coaches, Technical Ladders and Communities Executive Technical Leadership Council Distinguished Engineer Technical Director Senior Member Technical Staff Individual Team Leader Contributor… Outstanding Contributor Individual Management Contributors… Customer Product Architects Mgr Leads Communities of Release Products Tools Process Practice Deployment Infrastructure Support Platforms Test Coaches Driven Development
  6. 6. Lean and Agile In The Large (AIL) Participation of whole team in entire life cycle A simple common language from portfolio management to release engineering Ensures well formed development backlogs by iterating on items to ensure requirements are tangible hence testable. Concurrent and artifact driven allowing teams to increase through put and reduce blocking Teams own their own quality, predictability and transparency Provides coordination across multiple feature and component teams Enables the business to make long term commitments with known risk Comprehensive automated measurements provide complete transparency Large-Scale AIL Development Activities At-A-Glance Lean and Agile Values and Principles Product Owner Team Common Work Practices Envisioning Definition Development Release Engineering Team… Team… Team… Team… CI&T Prototypes/Models Architecture Requirements Product Backlog Team Sprint Shippable Backlog Release Release Code CI&T Backlog Backlogs Increments Risk Backlog Team… Potentially Shippable Product Release Backlogs Team… GUI Guidelines ©2006-2007 Bedarra Research Labs and Object Mentor
  7. 7. Common Work Practices and Rhythms Regardless of the activity, each team is self managed through the use of four key practices Backlogs Sprints Continuous Metrics Used to Organize Used to Execute Integration (CI) Used to Track The Work By The Work In Used to Ensure and Maintain Value Small Increments Quality Visibility Sprint (Iteration) Rhythm (2 wk) numbered by start week of year e.g. 01-09, 03-09 …. § Sprint Planning , Daily Stand-ups .., Sprint Retrospective Development Rhythm § Design Acceptance Test, Design Unit Test, Design Code, Build and Test Feature Release Rhythm numbered by start week of year 06-09 or 08-09 …. § 3 - 6 sprints per feature release Metrics – You Can Only Improve What You Can Measure Artifact Status Reporting Status of artifacts such as personas, problems, use scenarios, stories Burndownc harts CI Environment Reporting Status of stories written, Query & stories completed, tests Reporting written, tests passed and tests failed Engine Unit and Story Tests Subjective Reporting Qualitative data entered by Scrum Masters after every sprint regarding sprint progress and issues Retrospective Reports
  8. 8. Artefact Flow Enable Large Customer Commitments Leverage Architecture and Ensure Good Backlogs Components Sprint When Ready Ensure Transparency Envisioning Customer Needs, Definition Wants, Desires Development End Game AIL Portfolio (Backlogs) Portfolio Program Feature Team Company Backlog P1 F1 Blue F2 Blue Program Backlogs F3 Red Team Backlogs F4 Red F5 Red F6 Red P2 F7 Yellow F8 Green F9 Green F10 Purple F11 Purple P3 F12 White F13 White F14 White F15 White Component F16 Orange F17 Orange F18 Orange
  9. 9. AIL Feature Story Decomposition Program Medical Imaging Feature MRI Mechanical Control System Epic Table Movement Story Horizontal Table Movement Task Position Table w/ Joy Sticks and Dials Tangible Requirements • easily expressed by Business • easily understood by developers/testers • acceptance easily understood by Business • acceptance easily understood by IT • acceptance criteria (AC) => acceptance test (AT) Acceptance Story Criteria ©2004 Bedarra Research Labs. All rights reserved.
  10. 10. Acceptance Criteria Acceptance criteria must be tangible and measurable Developer needs to be able to write an acceptance test based on the acceptance criteria. Tests against feature, epic and user story Basic categories of acceptance criteria § Format (e.g. UI must be section 508 compliant) § Functionality (e.g. Flight cancellations must be performed manually) § Reliability (e.g. 99.999% uptime) § Performance (e.g. screen loads within 5 seconds, list loads 500 records in 10 secs, visual feedback on item selection occurs in less than 200 ms) § Capacity (e.g. 100 concurrent transactions, 1000 transactions per second) § Security (e.g. web audit trail of all transactions) Development ramifications of acceptance criteria § Tracking of detailed web interactions means need to store 10TB per month § Manual flight cancellation impacts system performance § 99.999% uptime means redundant system architectures and hot swapping § Slow visual feedback means examination of frameworks for performance issues AIL Artifact Break Down Program is a collection of Features (annual plan updated quarterly) Feature Release (Quarterly) described by Feature Stories Large Features( >3 months) broken up into visible feature releases Every Feature has a set of Acceptance Criteria and Acceptance Tests Features are composed of Epic Stories § An Epic must be completed in a single release § An Epic cannot span a team § Work that needs to be completed by another team (component/feature team) is placed in a separate Epic § Every Epic has a set of Acceptance Criteria and Acceptance Tests § Epics are composed of Stories § A Story must be completed in a single Sprint § A Story which is larger is broken into multiple Stories § Every Story has a set of Acceptance Criteria and Acceptance Tests § A Story is often broken down into Tasks – Tasks have a duration of 1 – 2 days and are normally – completed by a single person
  11. 11. DONE = Acceptance Tested! A Story is DONE when its Story ATs pass An Epic is DONE when all its Story ATs pass A Component is DONE when all its Epic (API/Service Level) ATs pass A Feature is DONE when all its Epic ATs pass A Program is DONE when all its Feature ATs pass AIL Feature Planning Flow Envisioning Definition Development 20 stories ? ids 35 stories 80-100 ids 35 stories Feature 4 stories ? ids + 23 later on Containing 15 stories ? ids 25 stories 60-80 days 25 stories Red, Green & Gold 5 stories ? ids + 25 later on Epics 15 stories ? ids 20 stories 55-60 ids 20 stories 5 stories ? ids +15 later on 15 Key Stories 80 Clear User Stories 80 User Stories Initially Architecture Diagram 14 Unclear User Stories GUI Prototype Feature Breakdown 63 Additional stories Artefacts Customer Feedback Component Breakdown after second round of Dependency Chart envisioning Release Backlogs 1st Iteration 6 Weeks 2 Weeks 45 Weeks 2nd Iteration 2 Weeks 4 4 5 2 Weeks
  12. 12. Envisioning Envisioning develops a clear product vision /roadmap to deliver the right product to the right market using the right technology through consultation with users and choosers. 10% of overall effort Prototypes & Models Market & Product Requirements Technology AnalysisBrainstorming Backlog Evaluations & Visioning Deliverables Prototyping Competitive Delta Risk Analysis Acceptance Criteria Backlog Customer Field QFD Studies & Interviews House of Quality GUI Guidelines Practices Deliverables n Brainstorming & visioning n Competitive n Requirements backlog n Risk analysis (SWOT) n Delta analysis n QFD backlog n Analysis & Verification n Customer studies n Hardware, platform & Reports n Prototypes/Models component evals n Prototyping/modeling n Look-and-Feel Guidelines Whole Team Envisioning All Stakeholders and All Roles Team Attributes § Critical Thinking (know, understand, apply, analyse, synthesise, evaluate) § Collaboration (patience, empathy, kindness, humility, listeners, communicators) § Thinking (visual, system, lateral, pattern, methodical) § Expertise (domain or industry, skills, sound grasp of technologies) How much time you spend envisioning depends on how well you know the requirements and solution ©2009 Bedarra Research Labs. All rights reserved.
  13. 13. Typical Requirements Gathering Tasks Data gathering § Secondary research using existing market and competitive analysis ($) § Heuristic evaluations ($$) § Surveys and questionaires ($$) § Field studies and job shadowing ($$$) – Our preferred choice § One-on-one interviews ($$$) § Focus group interviews ($$$$$) Problems Problems Personas Personas Stories Stories Acceptance Acceptance Criteria Criteria Problems Understand the problem before designing the solution Understand your “great idea” in the context of solving a “real problem” Problem Name Name of the problem Description Detailed description of the problem Evidence Any supporting evidence (e.g. reports, interviews, transcripts, call reports, help reports) Persona Persona affected by the problem For more on problems: http://www.pragmaticmarketing.com/publications/topics/01/requirements.pdf0
  14. 14. Problem Example Problem Name Cable management problem Description Jane has spent hours redecorating her home office, choosing just the right paint & furniture. Her new office looks sleek and modern except for.. the mess of computer & monitor wires and cables snaking around and under her desk. She thinks it looks ugly and distracts from the overall cool new look of the office Evidence Persona Affected Residential consumer © community.featureplan.com/community/2007/09/more_on_problems.php and reformatted Personas Popularized by Alan Cooper (www.cooper.com) Tangible way of representing and relating to the user Persona Name The persona name (e.g. George Smith) and a type (e.g. Business Consumer) Gender Demographic information Age Demographic information Education Education level Handicaps Special issues (e.g. glasses, hearing, physical or mental disabilities, etc) Technology literacy Experience with technology, experience with this kind of application or other applications Cultural bias Localization issues Goal/Motivations Describe the behavioral goal of why the user would want to use this product (e.g. likes to help people, scared of being laid off) Job Description Describe the personas role in terms of responsibities and typical day (i.e. provide the context for using the application)
  15. 15. Persona Example (Side 1) ©2005 http://personas.quarry.com/docs/QuarrySamplePersonas.pdf Concurrent Exploration Form and Function Exploration Technology Exploration 1.Do form and function analysis 1.Do technology analysis 2.Sort and prioritize tasks 2.Develop essential architectural 3.Identify primary persona and /design concepts primary tasks. 3.Identify training, tools, skills 4.Develop one or more primary 4.Identify items that merit proof-of- layouts and navigational models concept prototyping (e.g. usually (e.g. task flow, wireframe, sketches) risk related items such as structure, 5.Develop secondary layouts api, security, performance, as necessary scalability, platform issues) 6.Develop paper prototypes of the 5.Develop hardware/ software most promising candidates prototypes 7.Identify things you need to learn 6.Evaluate suppliers from users and choosers as you may need to do a little more prototyping
  16. 16. Typical Tasks Brainstorming and analysis Sorting and prioritizing (personas, scenarios, tasks, use cases) GUI Architecture and Design Concepts (e.g. organization and navigation based on task flow; layouts …) GUI Prototyping (e.g. task workflow) Software Architecture (e.g. structure of new, changes to existing) Buy vs. Build Evaluation Software Prototyping (e.g. derisking development through exploration of design alternatives – form, function, security, reliability, performance ) Typical Outputs Product Vision and roadmap § Many forms ranging from slide to prototypes to videos Paper prototypes § Card-flipping slide presentation GUI architecture, wireframes, interface concepts § Visio or slide presentation Core business logic § Example rules and actions, calculations, flows in tables, spreadsheets System architectures, diagrams, models § Slides § Architecture Views in Clouds, UML or Box and Connector Diagrams, Patterns Proof-of-concept software prototypes § Scripted or developed code with measurements showing key aspects of the system
  17. 17. Functional Design Questions What is the essential value of the feature (usefulness)? How can we make the essential value obvious or visible (usefulness)? What is the balance between complexity and visibility (usefulness)? How would we classify this functionality? § Table stakes is deciding on whether to simply catch-up (speed) or leap-frog (differentiate) § Competitive differentiator is balancing speed (first) with innovation (best) § Nice-to-have issue is how to balance richness and complexity Form Design Questions Is this a “legacy” form? – How much innovating can we really do? Is this primarily a “form” opportunity? – MP3 player was the functionality, but iPod was a form play Does the persona or context imply a new form? – Salesman suggests “portable” – Doctor suggests “portable” and “pen” What are our visionary competitors doing? What are our niche competitors doing? What are our customer’s saying about our legacy form?
  18. 18. Primary Layout Exploration Technique Tables help you explore the user’s organizational or mental model Organizational model Task Task Location or map views Used to show visual relationships between various display objects. X (e.g. physical maps, network topologies, drawing, process, desktop) Alphanumeric views Used when tabular comparisons, search, filter are important X (e.g. spreadsheets, alarm managers, email lists) Time views Used when time is an important relationship X (e.g. project management, calendars, planners, animation) Category views Used when the category is the important relationship (e.g. models, departments, organizations, classifications) Hierarchy views Used when seeing and understanding parent-child relationship is important X X (e.g. tree structure-based applications like Explorer or Outlook) Based on Richard Saul Wurman’s LATCH model. Read his book “Information Anxiety” for more information. GUI Envisioning Explores What does your primary persona think is cool/important? Any useful emerging UI technologies ready for prime time? – tablet, gestures, speech, haptic, table top, 2D bar codes What delivery platforms are we going to use? – C++, Java, C#, web 2.0, JSP/ASP/Flash/JS/CSS mobile, wireless… What does your primary persona use today? – iPod, Blackberry, PC… Is this a multi-technology delivery play? Do we understand the UI technologies? International and Universal Accessibility? -
  19. 19. Software Envisioning Explores Do we understand how this would be implemented? Have we done anything like this before? Has anyone else done it before? Can we reuse their solution? NIH? What are the major “technical problems” that we can foresee? Have we carefully considered all the “ilities”? – security, performance, scalability, conformance, data access, data manipulation, mobility Are there areas where I just don’t know enough to have an opinion? Is this solution too complicated for the value it will be delivering? ROI? Are we using the right technology, components, suppliers? Some Envisioning Practices A few form, function and technical design techniques: Design Technique Function Form Software Task Sorting (Functionality Sorting) X X QFD – House of Quality (Functionality X Sorting) Spreadsheets (Computation Rules) X X Decision Tables and Trees (Logic Rules) X X Domain Models, Class and Entity X X Relationship (Object Relationship) Diagrams Architecture Views – Conceptual, X X X Flow…Physical Interaction Diagrams and State Diagrams X X Prototypes X X X
  20. 20. Task Sorting Similar Similar Similar Similar Primary Primary Secondary Support Tasks Tasks Tasks Tasks Primary Secondary Supporting Tasks Tasks Tasks Tablestakes 1 1 Tasks 11 31 Differentiator 1 Tasks 21 Nice-To-Have Tasks Quality Function Deployment - House of Quality § Focus on customer § Couples customer requirements and technical characteristics § Quantify choices § Focus development § Manage complexity Source: http://www.gsm.mq.edu.au/wps/wcm/connect/internet/Root/research/researchclusters/cmit/tutorials/
  21. 21. Decision Tables § Simple way of getting customer head around complexity by structuring logic § Captures conditions, situations and actions § Easily updated § Can generate code and test easily No charges are reimbursed to the patient until the deductible has been met. After the deductible has been met, reimburse 50% for Doctor's Office visits or 80% for Hospital visits. There will be 4 rules. The first condition (Is the deductible met?) has two possible outcomes, yes or no. The second condition (type of visit) has two possible outcomes, Doctor's office visit (D) or Hospital visit (H). Two times two is four. Source: http://web.sxu.edu/rogers/sys/decision_tables.html Essential Architecture The essence of the application and the solution • Architect is a role not a job ! • Effectively communicate architecture • Understand the technology/team and business • Playing coaches • Articulate the important architectural style and patterns • Allow the architecture to emerge • APIs versioned in the code base • Should ALWAYS be able to create the architecture pictures from the code ©2004 Bedarra Research Labs. All rights reserved.
  22. 22. Communicating the Architecture – Put It On The Wall ER Data Model Interaction Diagram Domain Class Model Architecture Wall - Mapping Stories To Architecture Identify work load based on architecture Identify bottlenecks Identify efficiencies (e.g. functionality required by N stories) Identify feature and component teams affected Dashboard Feature Platform Layer Service Layer Application Layer Reporting Epic User Stories User Stories Database Component … … Client Add report Add report Edit report Edit report Delete report Delete report List reports List reports Search reports Search reports Copy and paste reports Copy and paste reports Print reports Print reports Configure report attributes Configure report attributes Format reports Format reports Database Component Server Configure reporting database Configure reporting database … …
  23. 23. Mapping Stories Against The Architecture Wall Create a working ‘thin slice’ through the architecture Also called tracer bullets, essential use cases Allows you to test functionality and show progress to stakeholders Example: ‘S1, S45, S22 and S18, we can show a simple search…’ Platform Layer Service Layer Application Layer S18 Database Component Client S1 S45 Database Component Server S22 Extreme Design - Design and Cost in 2 – 4hrs • Systems Engineering practice to respond to bids • Small team 3 – 5 spend 2 – 4 hrs • Essential System Design • What we know? • What we don’t know? • What will it cost to build? ©2009 Bedarra Research Labs. All rights reserved.
  24. 24. Prototyping Types of prototypes (working models) § Business, capability, usability, performance prototypes* § Fidelity should be as high as it needs to be; pay now or pay double later Use low-fidelity prototyping to explore: § Business (e.g. new functions, integrations) § Functionality or Capability (e.g. new functions, features, workflow) § User Experience (e.g. organization, navigation, appearance, accessibility, usability) Use software prototyping to explore: § Key Architecture/Design alternatives § New Technologies § Component suppliers § Performance (e.g. transaction rates, data storage access and retrieval, response times, throughput, concurrency) * See http://en.wikipedia.org/wiki/Software_prototyping Value of Prototyping GUI prototyping helps you design the system “A GUI picture is worth a thousand stories” Use Cases In This Picture Makes functionality concrete and tangible 1. 2. Open business area Print business area 3. Email business area Creates shared vision of the product 4. Export business area 5. Filter business area 6. Page list 7. Open help 8. Add report 9. Add dashboard 10. Add report configuration 11. Add dashboard configuration 12. List reports 13. List dashboards 14. List report configurations 15. List dashboard configurations 16. Open or view report 17. Copy report = 18. Move report 19. Delete report 20. Open or view dashboard 21. Copy dashboard 22. Move dashboard 23. Delete dashboard 24. Open or view report config 25. Copy report config 26. Move report config 27. Delete report config 28. Open or view dash config 29. Copy dash config 30. Move dash config 31. Delete dash config
  25. 25. Low-Fidelity Prototype Example Low-fidelity prototype § Initially rough and then later refined drawings § Interactive branching allowed walkthrough § User model, task model, task flows § 3 structure and navigation alternatives § 2 visual form alternatives Concept iterations § 6 iterations (expanding from 8 to 48 screens) § 3 sprints § 3 internal / 2 external customer sessions Detail iterations § 3 iterations (148 screens) § 8 sprints § 3 internal / 1 external customer sessions Investment § Less than 2% of overall effort Envisioning Improves Backlogs and Flow Are we building the right product, using the right technology for the right ROI? Explores Feasibility Exposes Risks Explores Solutions Alternatives Evaluates Technology Alternatives Enables early customer/business feedback Ensures that backlogs have sufficient detail to be tangible Ensures that backlogs have acceptance criteria DONE when the items are tangible and prioritized, such that there is enough clarity to commence development.
  26. 26. Successful Software Development is about a Winning Culture Software is a team sport, and like all team sports practice, constructive peer feedback, and coaching are essential. Winning teams need to implicitly know the moves of each player, as well as the movements of the team as whole. The ultimate expression of process is a culture where building software is more like playing jazz. People Just Do It! Obrigado!