This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
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.
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
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
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.
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)
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
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
§ 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.
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
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
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