1. 1Š Life Cycle Engineering 2014Š Life Cycle Engineering 2014
The Business Analyst in an Agile Environment
Presented by Justin Petite for SCGMIS
2. 2Š Life Cycle Engineering 2014
⢠12 years in a number of roles supporting
software and the SDLC
⢠Past 4+ years adapting and applying Agile
and Scrum to SPAWAR projects
⢠PMI â Agile Certified Practitioner
⢠Scrum Alliance Certified Scrum Master
⢠Scrum Alliance Certified Scrum Professional
jpetite@lce.com
@JustinPetite
JUSTIN PETITE
3. 3Š Life Cycle Engineering 2014
STARTING LINEUP
⢠5 minutes
⢠Confidence in your understanding of Agile
⢠Without talking
4. 4Š Life Cycle Engineering 2014
AFFINITY ESTIMATION
⢠Visualize and create groups by relative scale
⢠Comparison by subjective measure
⢠Good for large groups, and large quantities
⢠Intended to be fast, and just precise enough
to get started
More on this laterâŚ
5. 5Š Life Cycle Engineering 2014
OBJECTIVES
⢠Explore Agility, the Agile Manifesto, and Agile
principles
⢠Understand how business analysis fits into the
Agile environment
⢠Introduce personas and user stories
⢠Experience a variety of analysis tools and
techniques used on Agile projects
6. 6Š Life Cycle Engineering 2014
System
Requirements
Software
Requirements
Analysis
Design
Code
Test
Operations
âWATERFALLâ
7. 7Š Life Cycle Engineering 2014
MANIFESTO FOR AGILE
SOFTWARE DEVELOPMENT
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right,
we value the items on the left more.
8. 8Š Life Cycle Engineering 2014
AGILE
An iterative and incremental (evolutionary) approach
to software development which is performed in a
highly collaborative manner by self-organizing teams
within an effective governance framework with âjust
enoughâ ceremony that produces high quality
software in a cost effective and timely manner which
meets the changing needs of its stakeholders.
Scott Ambler
http://www.agilemodeling.com/essays/agileSoftwareDevelopment.htm
9. 9Š Life Cycle Engineering 2014
AGILITY
Agility is the ability to both create and respond
to change in order to profit in a turbulent
business environment
Agility is the ability to balance flexibility
and stability
Jim Highsmith
Agile Project Management (2nd Edition, 2010)
10. 10Š Life Cycle Engineering 2014
WHY AGILITY
⢠Need to more effectively respond to change
â Organizational needs
â Market demands
â Threats and opportunities
⢠Manage evolutionary change to products,
processes, and culture
⢠Frequently and incrementally deliver value to
reach a desired goal or outcome
11. 11Š Life Cycle Engineering 2014
BENEFITS
⢠Greater responsiveness to changing priorities
⢠Measured increase in productivity
⢠Lower costs
⢠Managed risk through greater visibility
⢠Increased customer satisfaction
⢠Better overall quality
⢠Improved team morale
12. 12Š Life Cycle Engineering 2014
VALUE IN âWATERFALLâ
cumulativebusinessvalue
time
13. 13Š Life Cycle Engineering 2014
AGILE VALUE PROPOSITION A
cumulativebusinessvalue
time
14. 14Š Life Cycle Engineering 2014
AGILE VALUE PROPOSITION B
cumulativebusinessvalue
time
16. 16Š Life Cycle Engineering 2014
AGILE PRINCIPLES
1. Our highest priority is to
satisfy the customer through
early and continuous delivery
of valuable software.
2. Welcome changing
requirements, even late in
development. Agile
processes harness change
for the customer's
competitive advantage.
3. Deliver working software
frequently, from a couple of
weeks to a couple of months,
with a preference to the
shorter timescale.
4. Business people and
developers must work
together daily throughout the
project.
5. Build projects around
motivated individuals. Give
them the environment and
support they need, and trust
them to get the job done.
6. The most efficient and
effective method of
conveying information to and
within a development team is
face-to-face conversation.
17. 17Š Life Cycle Engineering 2014
AGILE PRINCIPLES
7. Working software is the
primary measure of
progress.
8. Agile processes promote
sustainable development.
The sponsors,
developers, and users
should be able to
maintain a constant pace
indefinitely.
9. Continuous attention to
technical excellence and
good design enhances
agility.
10. Simplicityâthe art of
maximizing the amount of
work not doneâis
essential.
11. The best architectures,
requirements, and
designs emerge from self-
organizing teams.
12. At regular intervals, the
team reflects on how to
become more effective,
then tunes and adjusts its
behavior accordingly.
18. 18Š Life Cycle Engineering 2014
AGILE METHODOLOGIES
⢠Extreme Programming (XP)
⢠Scrum
⢠Kanban
⢠Scrum-ban
⢠Disciplined Agile Delivery (DAD)
⢠Scaled Agile Framework (SAFe)
⢠Dynamic Systems Development Method (DSDM)
⢠Feature Driven Development (FDD)
⢠Lean software development
19. 19Š Life Cycle Engineering 2014
AGILE PRACTICES
⢠Cross-functional teams
⢠Timeboxed iterations
⢠Story-driven modelling
⢠Backlogs (product, release, sprint)
⢠Acceptance Test Driven Development (ATDD)
⢠Test Driven Development (TDD)
⢠Continuous integration and deployment
⢠Pair programming
⢠Information radiators
⢠And many, many others
20. 20Š Life Cycle Engineering 2014
Accredited to Michael Sahota & Olaf Lewitz
22. 22Š Life Cycle Engineering 2014
Value
(Releasable Product)
Quality
(Reliable, Adaptable Product)
Constraints
(Scope, Cost, Schedule)
AGILE TRIANGLE
Jim Highsmith
23. 23Š Life Cycle Engineering 2014
AGILE METHODS DO:
⢠Position us to be more responsive to changing
priorities
⢠Allow better predictability of output for the
foreseeable time horizon
⢠Improve accountability
⢠Make priorities and risk calculations more
transparent
24. 24Š Life Cycle Engineering 2014
AGILE METHODS DON'T
⢠Make engineers write more lines of code per
day or designers create output faster
⢠Preclude the need to make good organizational
decisions about product, priorities, and
customer needs
⢠Allow the rest of the organization to assume
they think they know what lies months ahead
25. 25Š Life Cycle Engineering 2014
AGILE MYTHS
⢠âAgile is the silver bullet for our organization!â
⢠âAgile doesnât scale, so it canât work for our
organization!â
⢠âNo more documentation or deadlines!â
⢠âSince we donât do things upfront, we have no
design and poor architecture!â
⢠âWith so much rework going on, nothing new, and
innovative gets worked on!â
⢠âAgile makes us faster!â
26. 26Š Life Cycle Engineering 2014
ORGANIZATIONAL AGILITY
⢠More than just âdoing Agileâ
⢠Discipline of managed change through continuous
inspection, evaluation, and adaptation
⢠Tailored to the organization
⢠Leverages Agile methods appropriately at each level:
â Individual
â Team
â Project
â Program/Portfolio
â Executive
27. 27Š Life Cycle Engineering 2014
THE AGILE BUSINESS ANALYST
⢠Analysis still essential to software development,
regardless of project size, complexity, or
methodology
⢠Analysis is still about asking the right questions
⢠Vital to the agile requirements decomposition
paradigm
⢠Has an immediate impact on development
⢠Plays an integral role on the development team
29. 29Š Life Cycle Engineering 2014
ITERATIVE & INCREMENTAL
âIncrementingâ builds a finished piece
Assumes the customer
has a fully formed idea
of what they need
Jeff Patton - 2008
http://www.agileproductdesign.com/blog/dont_
know_what_i_want.html
30. 30Š Life Cycle Engineering 2014
ITERATIVE & INCREMENTAL
Jeff Patton - 2008
http://www.agileproductdesign.com/blog/dont_
know_what_i_want.html
âIteratingâ builds something imperfect to validate and refine
Iterating allows for less
developed ideas to
evolve and be refined
34. 34Š Life Cycle Engineering 2014
SCRUM ROLES
⢠Scrum Master
â Lead, promote, facilitate, organize, and coach Scrum
â Remove impediments for the team
⢠Product Owner
â Own, manage, and communicate the Product Backlog
â Advocate for the customer
⢠Scrum Team
â Turn work from the backlog into a âpotentially
shippableâ increment of working software
35. 35Š Life Cycle Engineering 2014
ANALYST PATTERNS
http://www.romanpichler.com/blog/business-analysts-in-scrum/
36. 36Š Life Cycle Engineering 2014
ANALYST PATTERNS
http://www.romanpichler.com/blog/business-analysts-in-scrum/
37. 37Š Life Cycle Engineering 2014
ANALYST ANTI-PATTERN
http://www.romanpichler.com/blog/business-analysts-in-scrum/
38. 38Š Life Cycle Engineering 2014
RESPONSIBILITIES
Product Vision
Product
Backlog
Guidance to
Scrum Team
Stakeholder
Expectations
PRODUCT
OWNER
39. 39Š Life Cycle Engineering 2014
5 LEVELS OF AGILE PLANNING
Vision
Roadmap
Release
Sprint
Daily
Suggested
Time box*
Outcome
Annual Vision
Semi-Annual Roadmap
Quarterly
Release
Backlog
2-4 weeks
Sprint
Backlog
15 mins daily â3 Questionsâ
40. 40Š Life Cycle Engineering 2014
PRODUCT VISION
The product vision is a
high level statement
that provides the team
with a shared
understanding of the
what the end product
will look like.
41. 41Š Life Cycle Engineering 2014
PRODUCT VISION
Bill Shakelford: âDesign the boxâ
Front of the box
⢠Product Name
⢠Graphic/logo
⢠3-4 key selling points
Back of box
⢠Description of key features
⢠Screens/mockups
Spine
⢠System requirements
42. 42Š Life Cycle Engineering 2014
ELEVATOR PITCH
FOR (target customer)
WHO (statement of need)
THE (product name) is a (product category)
THAT (product key benefit, compelling reason to buy,
problem being solved, etc.)
UNLIKE (primary competing alternative)
OUR PRODUCT (final statement of key differentiation)
Geoffrey Mooreâs âElevator Pitchâ, Crossing the Chasm (1991)
43. 43Š Life Cycle Engineering 2014
AGILE PRODUCT CHARTER
⢠Mission: The âWhyâ, higher purpose, or the reason
for the projectâs existence.
⢠Vision: the âWhatâ of the project stating what will be
done in the project to achieve its higher purpose.
⢠Success Criteria: The success criteria are
management tests that describe effects outside of
the solution itself â Defines âDoneâ
44. 44Š Life Cycle Engineering 2014
AGILE PROJECT CHARTER
⢠1 page (A3)
⢠High level, but specific
⢠Eliminate boilerplate
⢠Aligned with stakeholder
Shared understanding of
the charter is critical to
enabling team members to
collaborate effectively on
large, enterprise projects
45. 45Š Life Cycle Engineering 2014
TARGET PRACTICE
⢠5 Minutes
⢠Pick a product
⢠Try a method
â Product Box
â Elevator Statement
â Charter (A3)
â What else works for you?
Successful vision defines at a high level:
User â Opportunity â Critical features
Other context specific objectives and success factors
46. 46Š Life Cycle Engineering 2014
ROADMAP
⢠Connects the Product Vision to the execution plan
⢠Provides the team with visibility, incentive, and focus
⢠Not a commitment ⌠a visualization of the plan
July Aug Sep Oct Nov
Security
User Admin
Payments
User Admin
Product Admin
Fulfillment
Security
47. 47Š Life Cycle Engineering 2014
BIG ROCKS
Grouping like features can be helpful for planning
These are often referred to as Themes or Epics
Security
Login with
username/password
Password Reset
SSL 3.0
User Admin
User account DB
Update user info
Register User
Payment
Credit Card
Auto draft
PayPal Integration
49. 49Š Life Cycle Engineering 2014
CHART YOUR COURSE
⢠10 minutes
⢠Brainstorm how to
deliver value early
⢠Come up with some
high level themes
⢠Roughly prioritize
⢠6 â 9 month horizon
50. 50Š Life Cycle Engineering 2014
PERSONAS
⢠A fictional character based on role, and real
qualitative understanding of your user base
⢠Emphasize the user-centric approach and
promote empathy for the user and customer
Picture
and Name
Details
Goals or
Solution
Choose a picture and a
name that are
representative, and that
allow you to develop
sympathy for the
persona
Relevant characteristics
and behaviors:
Demographics, job,
lifestyle, spare time
activities, attitudes,
common tasks, etc.
Why would this specific
persona want to buy or
use this product?
What problems are
solved for this persona?
What benefits are this
persona seeking?
52. 52Š Life Cycle Engineering 2014
TIPS FOR USING PERSONAS
⢠Start with quick and good enough - adapt over time
⢠Distinguish user personas from customer personas
⢠Choose a primary persona
⢠Make personas believable
⢠Stay focused and precise â problems and benefits
⢠Keep the personas visible
⢠Connect personas to user stories
53. 53Š Life Cycle Engineering 2014
INTRODUCE YOUR USERS
⢠5 minutes
⢠Come up with 2-3 user
personas for your product
⢠Tie userâs problem to your
productâs solution
⢠Ensure each user has a role
55. 55Š Life Cycle Engineering 2014
USER STORY
⢠Simple and concise statement of requirement
from a user perspective
⢠Originated in Extreme Programming (XP)
⢠Ron Jeffries: 3 Câs
â Card
â Conversation
â Confirmation
56. 56Š Life Cycle Engineering 2014
THOUGHT TEMPLATE
A conversation with the stakeholder:
â âAs aâ specific user or persona
â âI wantâ need, feature, or functionality
â âSo (that)â purpose and value of delivery
57. 57Š Life Cycle Engineering 2014
ACCEPTANCE CRITERIA
⢠Flip the card over to record expectations:
â User
â Customer
â Product Owner
â Team
How has the customer defined success for this story?
58. 58Š Life Cycle Engineering 2014
INVEST
Independent
⢠Can ideally stand alone as a working
product increment
⢠Avoids dependencies with other stories
whenever possible
59. 59Š Life Cycle Engineering 2014
INVEST
Negotiable
⢠Stories are concepts not contracts
⢠Can and should be revised or rewritten
up until they are planned in a sprint
60. 60Š Life Cycle Engineering 2014
INVEST
Valuable
⢠Should deliver value to the end user,
customers, and/or stakeholders
⢠Why else would a story matter?
61. 61Š Life Cycle Engineering 2014
INVEST
Estimable
⢠The story provides the Team with enough
information to approximate size
⢠By understanding size, we can then plan
62. 62Š Life Cycle Engineering 2014
INVEST
Sized appropriately (Small)
⢠Ideally can be completed in one iteration
⢠Small for near-term work
⢠Larger for work further out is ok, realizing
further decomposition will be needed later
63. 63Š Life Cycle Engineering 2014
INVEST
Testable
⢠Acceptance criteria establishes common
expectations across team members and
stakeholders
⢠Critical to understand not just what will be
tested, but also how it will be tested
64. 64Š Life Cycle Engineering 2014
OTHER KINDS OF STORIES
Technical Foundation:
âAs a developer, I need to upgrade the database
software so we are running on the correct
supported versionâ
Research (Spike):
âAs lead architect, I need to research and
evaluate COTS products that are compatible
with our current systemâs architecture so we can
reduce the risk of future issues with integrationâ
65. 65Š Life Cycle Engineering 2014
OTHER KINDS OF STORIES
Design:
âAs a UI/UX engineer, I need to create the initial
design for the account management screens so
that I can begin to gather customer feedbackâ
Other possible types of work items:
Defects, maintenance, training, documentation,
development infrastructure, automation, etc.
66. 66Š Life Cycle Engineering 2014
STORY WRITING
⢠15 minutes
⢠Write stories
â From the perspective
of your personas
â Leverage/adjust your
roadmap for value
â Remember the
template:
As a <user>, I need to <do something>, so
that I can <accomplish some goal>
67. 67Š Life Cycle Engineering 2014
PRODUCT BACKLOG
⢠An ordered list of work items needed to deliver the
desired product, features, or system
⢠The Product Owner decides the order with input from
the development team and stakeholders
⢠Always ready, never done, ever evolving
⢠Modelled in greater detail and smaller size at the top
⢠Maximizing value to the customer is the objective
70. 70Š Life Cycle Engineering 2014
USER STORY MAPPING
⢠Organizes and prioritizes user stories in two
dimensions
⢠Provides a useful tool for the entire team to
understand the big picture
⢠Can be useful when building a feature-rich product
based on business processes, workflow, or tasking
⢠Attributed to Jeff Patton -
www.AgileProductDesign.com
75. 75Š Life Cycle Engineering 2014
PRIORITIZING
What is value to the customer?
âFinancial
âBusiness
âReduced cost to develop and support
âInnovation
âRisk reduction
âMarket factors
âCompliance
âDeadline
77. 77Š Life Cycle Engineering 2014
PRIORITIZING
Business
Value
Cost Impact
Risk
Removed
Total
Story A 7 4 8 9 7
Story B 10 2 5 6 5.75
Story C 2 6 3 5 4
Story D 4 10 6 2 5.5
Decision Matrix
- Good for teams
supporting
disparate
customers
- Incorporates
multiple factors
- Scored as a
group
80. 80Š Life Cycle Engineering 2014
EVALUATE YOUR STORIES
⢠5 minutes
⢠Kano Analysis
âMust have
âSatisfier
âDelighter
⢠Label your story cards
⢠Ask around
81. 81Š Life Cycle Engineering 2014
FACTORS TO CONSIDER
⢠Minimally Marketable Feature (MMF)
⢠Minimum viable product (MVP)
⢠Earned Business Value (EBV)
⢠Risk
⢠Architecture and infrastructure
⢠Dependencies and integrations
⢠Constraints: Schedule & Costs
82. 82Š Life Cycle Engineering 2014
DEFINITION OF DONE
⢠What do we mean by âpotentially shippableâ
⢠When is the team finished with a story? A
feature? A release?
⢠Evolves over time
⢠Suited to the teamâs unique environment
⢠Incremental maturity
⢠Helps to ensure quality is âbuilt inâ
83. 83Š Life Cycle Engineering 2014
ESTIMATION
How long is this going to take?
84. 84Š Life Cycle Engineering 2014
ESTIMATION
âEstimation is the process of finding an
approximation, which is a value that is
usable for some purpose even if input
data may be incomplete, uncertain, or
unstableâ
⢠Too many variables
⢠Too much unknown
⢠Too far in the future
⢠Individual biases
85. 85Š Life Cycle Engineering 2014
ESTIMATES BECOME PROMISES
⢠Estimates drive expectations
âCustomers
âStakeholders
âBusiness
⢠Estimation may add value ⌠But, is
only valuable within a threshold of
risk and cone of uncertainty
87. 87Š Life Cycle Engineering 2014
AGILE ESTIMATION
⢠Story estimates are abstract - not time based
⢠Derived from other âknownâ factors:
â Effort
â Complexity
â Uncertainty
⢠Informed by past performance
⢠Originate from those who will do the work
⢠Best to be roughly right than precisely wrong!
88. 88Š Life Cycle Engineering 2014
RELATIVE SIZING: DOG POINTS
⢠Golden Retriever
⢠Great Dane
⢠Border Collie
⢠Chihuahua
⢠Cocker Spaniel
⢠English Bulldog
⢠2 minutes
⢠Order from
smallest to largest
⢠Compare your list
with your neighbor
89. 89Š Life Cycle Engineering 2014
RELATIVE SIZE
T-Shirt XS S M L XL XXL
Fibonacci 1 2, 3 5, 8 13, 20 40 100
90. 90Š Life Cycle Engineering 2014
SIZING TECHNIQUES
⢠Affinity Estimation â group stories of similar size and
then assign points
2 5 8 13 20 40
91. 91Š Life Cycle Engineering 2014
PLANNING POKER
⢠Product Owner tells the story
⢠Team briefly discusses
⢠Team members reveal their estimates all at once
⢠Discuss outliers
⢠Repeat until estimates converge
92. 92Š Life Cycle Engineering 2014
ESTIMATING WITH POINTS
⢠Donât spend too much time on each story
⢠Estimate only as much as is needed for planning
⢠Large stories should be set aside to be broken down
⢠Estimates come from the team â resist individual
âanchoringâ
⢠Only re-estimate when relative size of a story has
changed
93. 93Š Life Cycle Engineering 2014
VELOCITY AND CAPACITY
⢠Velocity
â The demonstrated
average number of points
completed in an iteration
⢠Capacity
â The maximum amount a
team can get done in an
iteration
94. 94Š Life Cycle Engineering 2014
ITERATION PLANNING
⢠Start at the top
⢠Identify specific tasks for each story
⢠Estimate tasks in ideal hours for each task
⢠Stop when capacity is reached
Hours In Sprint
Planned
Absent Allocation Buffer Capacity
Jim 80 16 100% 25% 48
Joe 80 0 100% 25% 60
Jane 80 0 50% 25% 30
Jenny 80 8 100% 25% 54
Jack 80 0 50% 25% 30
400 24 100% 25% 222
95. 95Š Life Cycle Engineering 2014
BACKLOG GROOMING
⢠At least once a sprint
⢠Consult with the customer
⢠Break down or split large stories
â Many ways to do this
⢠Give the team a preview, but not too far ahead
⢠Refine acceptance criteria and design tests
⢠Estimate size
96. 96Š Life Cycle Engineering 2014
SPRINT CADENCE
⢠Rhythm and ritual
97. 97Š Life Cycle Engineering 2014
BURNDOWN CHARTS
⢠Represent work remaining
â By Release (points) or iteration (hours)
98. 98Š Life Cycle Engineering 2014
LOTS OF OTHER METRICS
⢠Goal: Measure and communicate progress
through meaningful and highly visible means
⢠Force the right conversations early
⢠Help teams recognize their cadence
⢠Uncover risk and areas of opportunity
⢠Inform conversations⌠not replace them
99. 99Š Life Cycle Engineering 2014
RETROSPECTIVES
⢠The most powerful tool available to an Agile team
⢠Observe, inspect, and adapt:
â What worked well?
â What didnât work well?
â What will we improve?
⢠Focus on the team, not the product
⢠Avoid dwelling on external factors
100. 10
0
Š Life Cycle Engineering 2014
PROJECT INITIATION
Decompose project requirements (scope) to
create the first iteration of the project
schedule, roadmap, and backlog
Form the cross-functional agile team(s) of
individuals with the roles and skills necessary to
deliver on the projectâs requirements
Train the team, educate the customer,
and communicate expectations
Get started sprinting following the standard practices
to learn how to best adapt in the future
¡ Incorporate feedback from retrospectives
¡ Build âmuscle memoryâ around good practices
¡ Establish common understanding of
Agile fundamentals
¡ Agree to a cadence
¡ Decide on initial technologies
¡ Identify and negotiate stakeholder
roles and responsibilities
¡ Agree to the metrics by which project
performance will be measured
¡ Establish the definition of done
¡ Set up visible progress indicators
Work
Breakdown
Structure
IMS /
Roadmap
Agile PM Tool
User StoriesUser Stories
Systems
Requirements
Document
(SRD)
Systems
Requirements
Document
(SRD)
PWS/CDRLPWS/CDRL
Product OwnerProduct Owner
TestersTestersDevelopersDevelopers
Scrum MasterScrum Master
101. 10
1
Š Life Cycle Engineering 2014
KEEP THE AGILE CONVERSATION GOING
⢠Software engineering
practices
⢠Agile team dynamics
⢠Scaling up
⢠Contracting and
government
⢠Metrics
⢠Planning
⢠User story writing
⢠Testing/Quality
⢠Retrospectives
⢠Configuration management
⢠Release management
⢠Information assurance
⢠Fostering culture
⢠Organizational transition
⢠Change management
⢠Industry certifications
⢠Management and executive
sponsorship
⢠More than software
102. 10
2
Š Life Cycle Engineering 2014
CONTINUOUS LEARNING
⢠Take a class
⢠Attend a conference
⢠Get certified
⢠Engage online
103. 10
3
Š Life Cycle Engineering 2014
HELP FOR THE TRANSITION
Agile Coach
⢠Supports the successful introduction of Agile to your
organization and team
⢠Shares subject matter expertise and experience
⢠Helps avoid common mistakes and pitfalls that
hinder adoption and delay value
⢠Acts as a neutral and objective third party
⢠Is a supportive partner and mentor across the
organization
104. 10
4
Š Life Cycle Engineering 2014
THANK YOU!
Please let me know how I can do better next time!
jpetite@lce.com
@JustinPetite
Hinweis der Redaktion
Affinity: a similarity of characteristics suggesting a relationship, especially a resemblance in structure
Waterfall â 1970 â Winston Royce â âManaging the Development of Large Software Systemsâ
âPersonal views about managing large software developmentsâ mainly spacecraft mission planning, commanding, and post flight analysis
âWaterfallâ coined by the DOD in their standards for developing military computer systems.
Clearly stated that this model fails without iteration
February 2001: 17 leaders in the software development industry seeking an alternative to documentation driven, heavyweight software development processes.
Highlight:
Iterative and Incremental - Evolutionary
Highly collaborative
Self-organizing teams
effective governance framework just enough ceremony â cultural discipline & best practices
High quality, cost effective, and timely â project triangle
Meeting changing needs of the stakeholder within the project triangle â value
Highlight:
Responding to change
Rooted in values
Bounded by principles
Enacted through practices
Many people may think that Agile is just another software development process. There is a lot more to Agile than just a process or just a set of practices. Agile (or agility) is a mindsetâa cultural way of thinking about software development.
The agile methods are focused on different aspects of the Software development life cycle. Some focus on the practices (e.g. XP, Pragmatic Programming, Agile Modeling), while others focus on managing the software projects (e.g. Scrum). Yet, there are approaches providing full coverage over the development life cycle (e.g. DSDM, IBM RUP), while most of them are suitable from the requirements specification phase on (FDD, for example). Thus, there is a clear difference between the various agile methods in this regard.
DSDM = Iterative Waterfall
Embedded in those methodologies are practices such asâŚ
Requirements Practices
Development Practices
Testing Practices
Release Management Practices
Configuration Management Practices
Iterating â Not intended to be perfect
Generates feedback
Takes a keen understanding of the purpose/solution what is being built
A true Scrum Team consists of a ScrumMaster, a Product Owner, and a Team. These three roles are collectively responsible for the delivery of the finished software. Each role also carries distinct responsibilities to optimize the Scrum Teamâs flexibility and productivity.
ScrumMaster â Responsible for ensuring that the Scrum Team adheres to the values, practices, and rules of Scrum. The ScrumMaster role is that of facilitator, organizer, and coach. Most importantly, the ScrumMaster is responsible for removing impediments â anything that may be preventing the team from making progress towards delivery.
Product Owner âSolely responsible for managing the Product Backlog and ensuring it is visible to the Scrum Team. The prioritization of the backlog represents the voice of the customer, and illustrates the top business needs and their alignment with the overall vision of the project.
Scrum Team â Turns work from the backlog into increments of potentially shippable functionality every iteration. The true Scrum Team is cross-functional; meaning, the members of the Team have all the skills required to create an increment of working software. True Scrum Teams are also self-organizing. While the Product Owner defines what the Team will work on, the Team itself decides how the work will get done in an iteration. The optimal size for a Scrum Team is seven people, plus or minus two. For projects with larger teams, Scrum can be scaled up to support better coordination and productivity across multiple teams working from the same backlog.
PO Proxy can make things complicated and confusing
The Product Owner is:
the singular voice of the customer that a Scrum Team must satisfy
the central business point of contact for defining product requirements & direction
The Product Owner must have:
deep understanding of the business drivers for the organization/program
authority to make decisions/prioritize work
commitment to follow the Scrum framework
The Product Owner is responsible for:
Communicating the Product vision at all levels
To teams, stakeholders
Ensuring that Program stays aligned with Product Vision
Identifying the desired features/functionality and the value each should produce (Product Backlog)
Ordering the desired features/functionality
Providing Continual Guidance/Information to the Scrum Team
Requirements
Acceptance Criteria
Agreement on Design Approach
Be available to the Team
Establish proxies & an interaction model if needed
Managing Stakeholder expectations
Release Planning â level of confidence on estimates
Scope Management
Visibility
Participation at Sprint Reviews
Product Management â Strategy towards vision
*at least
Bill Shakelfordâs âDesign the boxâ exercise
Front of the box
Product Name
Graphic/logo
3-4 key selling points
Back of box
Description of key features
Screens/mockups
Spine
System requirements
Bill Shakelfordâs âDesign the boxâ exercise
Front of the box
Product Name
Graphic/logo
3-4 key selling points
Back of box
Description of key features
Screens/mockups
Spine
System requirements
1. What does success look like to each of the participants? The mission needs to identify what
the people who charter the team value. Consider too the goals of each of the contributors.
2. What is the product of the team expected to look like? What features? What are the
architectural constraints? What interactions will the system have with itâs environment?
3. What attributes will the project be constrained by? What are the resource and schedule
constraints? What issues are known to be significant?
A shared understanding of these dimensions is critical to enabling the team members to collaborate
effectively.
1998 and 2001
As a <stakeholder>, I would like to improve <some quality dimension> from <current level> to <desired level>, so that I can <achieve some goal>
One trick I learned to keep my user stories small is to only allow enough scope so that all of my acceptance stories can be written using a ball point pen on the backside of the user story index card. Another physical constraint!
If your user story has more than 3-4 acceptance tests, really analyze the story and see if it makes sense to break it down even further so you can fit all its acceptance tests on the back of the card. Doing so might help you break down those larger stories into more digestible pieces.
Typical attributes to help with order:
Value
Dependency
Complexity
Cost
Size
âFlatâ
Visualize the story!
Product goals describe what outcome or benefit received by the organization after the product is in use
Ideal time vs actual time
No longer a question of Time when the schedule is fixed. Better question is how much, not how long.
Empirical process control
A COACH CAN:
support the successful introduction of Agile to your organization and team
improve teamwork and increase productivity
mentor and up-skill executives and managers.
GOOD COACHES ARE:
Knowledgeable: They have a deep understanding of Agile practices and processes.
Experienced: They have worked on Agile projects.
Communicators: They can listen and talk with people from across an organization.
Collaborators: They work with teams and organization to find answers.
Leaders: They can motivate and inspire teams.