envisioning improving productivity and qaulity through better backlogs agile portugal
TRANSCRIPT
©2010 Bedarra Research Labs. All rights reserved.
Envisioning - Improving Productivity and Quality through Better Backlogs
KeynoteAgile Portugal 2010
Dave [email protected]
Bedarra Research Labs, Object MentorCarleton University Canada, Queensland University of
Technology Australia
OutlineWe 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.
We love Agile Development BUT ... There are really just a couple of problems
Productivity
Quality
Predictability/Estimates
Management of Expectations
Product Owners Availability
Reduce Owner Burnout
Requirements Churn
Portfolio Management
Reduce Rework
Reduce Integration Costs
Not Collocated
....
©2009 Bedarra Research Labs. All rights reserved.
Requirements?!
Testing?!
Predictability, Quality, Productivity, Agility and Value
©2004 Bedarra Research Labs. All rights reserved.
Value
Quality
Predictability
Productivity
Agility
Agile
Scrum
TDD
Surveys show Scrum increases morale and productivity, but only TDD impacts quality
5 – 15% Needs
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, incompleterequirements, and changing requirements as the problem.
What the user thinks he’s getting…
What the developerthinks he’s delivering…
Source: Standish Group. Chaos Reports. Challenged Projects
?
Too Many Requirements versus Too FewThe 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 andProductivity
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
Large Scale - Social Engineering
Values and VisionCommon Vocabulary, Practices, Tools Common Tools and Global TransparencyEmpower Distributed Teams – Skype, Live Boards, Developers TravelDirecting transitions to Coaching and MentoringUse Playing Coaches to share vision and experiencesDONE Means Test – Our Code Doesn’t Smell
• Predictable Delivery • Quality Delivery• Teamwork • Early Problem Identification and Resolution
Align Individual/Team Compensation with Desired Behavior
Common Culture
Executive
Technical Director
Team Leader
Individual Contributors…
Individual Contributor…
DistinguishedEngineer
Senior MemberTechnical Staff
OutstandingContributor
Technical Leadership Council
Playing Coaches, Technical Ladders and Communities
Management
ArchitectsLeads
CustomerProduct
Mgr
ToolsProcess
InfrastructurePlatforms
Coaches
ReleaseDeployment
Support
TestDriven
Development
ProductsCommunities of Practice
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
Lean and Agile Values and Principles
Large-Scale AIL Development Activities At-A-Glance
Envisioning
Product Owner Team Common Work Practices
Definition Development ReleaseEngineering
Prototypes/Models
Requirements Backlog
Risk Backlog
Team… Team…
GUI Guidelines
Architecture
Product Backlog
Release Backlogs
Team…
Team…
Team…
Team…
PotentiallyShippableProduct
TeamReleaseBacklog
ShippableCodeIncrements
SprintReleaseBacklogs
CI&T
CI&T
©2006-2007 Bedarra Research Labs and Object Mentor
Common Work Practices and Rhythms
Regardless of the activity, each team is self managed through the use of four key practices
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
SprintsUsed to ExecuteThe Work In Small Increments
MetricsUsed to Trackand MaintainVisibility
BacklogsUsed to Organize The Work ByValue
Continuous Integration (CI)Used to EnsureQuality
Metrics – You Can Only Improve What You Can Measure
ArtifactStatus ReportingStatus of artifacts such as personas, problems, use scenarios, stories
Subjective ReportingQualitative data entered by Scrum Masters after every sprint regarding sprint progress and issues
CI EnvironmentReportingStatus of stories written, stories completed, tests written, tests passed and tests failed
Query & ReportingEngine
Burndownc harts
Retrospective Reports
Unit and Story Tests
Artefact Flow
Sprint When ReadyEnsure Good Backlogs
Leverage Architecture and Components
Ensure Transparency
Enable Large Customer Commitments
Envisioning
Definition
Development End Game
CustomerNeeds,Wants,Desires
AIL Portfolio (Backlogs)
Portfolio Program Feature TeamP1 F1 Blue
F2 Blue
F3 Red
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
Company Backlog
Program Backlogs
Team Backlogs
AIL Feature Story Decomposition
Program
Feature
Epic
Story
Task
MRI Mechanical Control System
Table Movement
Horizontal Table Movement
Medical Imaging
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)
©2004 Bedarra Research Labs. All rights reserved.
StoryAcceptance Criteria
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 StoriesLarge Features( >3 months) broken up into visible feature releasesEvery Feature has a set of Acceptance Criteria and Acceptance TestsFeatures 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
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
DevelopmentEnvisioning Definition
35 stories
25 stories
20 stories
80-100 ids
60-80 days
55-60 ids
5 stories ? ids
4 stories ? ids
5 stories ? ids
20 stories
15 stories
15 stories
? ids
? ids
? ids
15 Key StoriesArchitecture DiagramGUI PrototypeCustomer Feedback
80 Clear User Stories14 Unclear User StoriesFeature BreakdownComponent BreakdownDependency ChartRelease Backlogs
6 Weeks 2 Weeks
80 User Stories Initially
63 Additional stories after second round of envisioning
45 Weeks
35 stories
25 stories
20 stories
+ 23 later on
+15 later on
+ 25 later on
2 Weeks 2 Weeks
1st Iteration
2nd Iteration
Artefacts
FeatureContainingRed, Green& Gold Epics
4 4 5
10% of overall effort
Envisioning
Competitive DeltaAnalysis
Practicesn Brainstorming & visioning n Competitive analysis (SWOT) n Delta analysis n QFD n Customer studies n Hardware, platform & component evals n Prototyping/modeling
Deliverablesn Requirements backlog n Risk backlog n Analysis & Verification Reports n Prototypes/Models n Look-and-Feel Guidelines
RequirementsBacklog
RiskBacklog
Customer FieldStudies & Interviews
TechnologyEvaluations
Prototypes& Models
GUIGuidelines
Market & ProductAnalysisBrainstorming
& Visioning
QFDHouse of Quality
Prototyping DeliverablesAcceptanceCriteria
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.
Whole Team Envisioning
All Stakeholders and All Roles
©2009 Bedarra Research Labs. All rights reserved.
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
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 ($$$$$)
StoriesStoriesProblemsProblems PersonasPersonas AcceptanceCriteria
AcceptanceCriteria
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
Problem Example
© community.featureplan.com/community/2007/09/more_on_problems.php and reformatted
ProblemName Cable management problemDescription 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
Personas
Popularized by Alan Cooper (www.cooper.com)
Tangible way of representing and relating to the user
PersonaName 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 applicationsCultural 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)
Persona Example (Side 1)
©2005 http://personas.quarry.com/docs/QuarrySamplePersonas.pdf
Concurrent Exploration
1.Do form and function analysis
2.Sort and prioritize tasks
3.Identify primary persona and primary tasks.
4.Develop one or more primary layouts and navigational models (e.g. task flow, wireframe, sketches)
5.Develop secondary layouts as necessary
6.Develop paper prototypes of the most promising candidates
7.Identify things you need to learn from users and choosers as you may need to do a little more prototyping
1.Do technology analysis
2.Develop essential architectural /design concepts
3.Identify training, tools, skills
4.Identify items that merit proof-of-concept prototyping (e.g. usually risk related items such as structure, api, security, performance, scalability, platform issues)
5.Develop hardware/ software prototypes
6.Evaluate suppliers
Form and Function Exploration Technology Exploration
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
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?
Primary Layout Exploration Technique
Tables help you explore the user’s organizational or mental model
Organizational model Task TaskLocation or map views Used to show visual relationships between various display objects.(e.g. physical maps, network topologies, drawing, process, desktop)
X
Alphanumeric viewsUsed when tabular comparisons, search, filter are important(e.g. spreadsheets, alarm managers, email lists)
X
Time viewsUsed when time is an important relationship(e.g. project management, calendars, planners, animation)
X
Category viewsUsed when the category is the important relationship(e.g. models, departments, organizations, classifications)
Hierarchy viewsUsed when seeing and understanding parent-child relationship is important(e.g. tree structure-based applications like Explorer or Outlook)
X X
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?
-
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 SoftwareTask Sorting (Functionality Sorting) X X
QFD – House of Quality (Functionality Sorting)
X
Spreadsheets (Computation Rules) X X
Decision Tables and Trees (Logic Rules) X X
Domain Models, Class and Entity Relationship (Object Relationship) Diagrams
X X
Architecture Views – Conceptual, Flow…Physical
X X X
Interaction Diagrams and State Diagrams X X
Prototypes X X X
Task Sorting
SimilarPrimaryTasks
SimilarPrimaryTasks
SimilarSecondaryTasks
SimilarSupportTasks
PrimaryTasks
SecondaryTasks
Supporting Tasks
TablestakesTasks
DifferentiatorTasks
Nice-To-HaveTasks
111
112
113
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/
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.
Communicating the Architecture – Put It On The Wall
Interaction Diagram
ER Data Model
Domain Class Model
Architecture Wall - Mapping Stories To ArchitectureIdentify work load based on architecture
Identify bottlenecks
Identify efficiencies (e.g. functionality required by N stories)
Identify feature and component teams affected
Database
Component
Component
Server
Client
Platform Layer Service Layer Application Layer
Database
User Stories
…Add reportEdit reportDelete reportList reportsSearch reportsCopy and paste reportsPrint reportsConfigure report attributesFormat reportsConfigure reporting database…
User Stories
…Add reportEdit reportDelete reportList reportsSearch reportsCopy and paste reportsPrint reportsConfigure report attributesFormat reportsConfigure reporting database…
Reporting Epic
Dashboard Feature
Mapping Stories Against The Architecture WallCreate 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…’
Database
Component
Component
Server
Client
Platform Layer Service Layer Application Layer
Database
S1
S22
S45
S18
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.
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
Use Cases In This Picture
1. Open business area2. Print business area3. Email business area4. Export business area5. Filter business area 6. Page list7. Open help8. Add report9. Add dashboard10. Add report configuration11. Add dashboard configuration12. List reports13. List dashboards14. List report configurations15. List dashboard configurations16. Open or view report17. Copy report18. Move report19. Delete report20. Open or view dashboard21. Copy dashboard22. Move dashboard23. Delete dashboard24. Open or view report config25. Copy report config26. Move report config27. Delete report config28. Open or view dash config29. Copy dash config30. Move dash config31. Delete dash config
GUI prototyping helps you design the system
“A GUI picture is worth a thousand stories”
Makes functionality concrete and tangible
Creates shared vision of the product
=
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.
Successful Software Development is about a Winning CultureSoftware 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!