envisioning improving productivity and qaulity through better backlogs agile portugal

©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


mailto:[email protected]

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

....


Requirements?!

Testing?!

Predictability, Quality, Productivity, Agility and Value


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


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)


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


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

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)

http://www.cooper.com)

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

http://personas.quarry.com/docs/QuarrySamplePersonas.pdf

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/

http://www.gsm.mq.edu.au/wps/wcm/connect/internet/Root/r

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


http://web.sxu.edu/rogers/sys/decision_tables.html

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?


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

=

http://en.wikipedia.org/wiki/Software_prototyping

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!