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. 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
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. 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
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. 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
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
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. 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. 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. 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. 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/
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
…
…
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. 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. 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!