Highlights of actions taken to during the 2006/2007 introduction of Agile development techniques to Tribune Interactive's software development and business stakeholders.
Introducing Agile Development in Traditional Software Development Organizations
1. Agile @ TI
Last Updated 1/22/07
J. Cole
Intended Audience: Non-Technical
2. “We Need to Move Faster”
Agile Champions
Tribune Interactive CTO
Senior developers
• High level of initiative
• Constructive criticism of challenges to rapid development
Selling Agile to Senior Management
Accelerated availability of early iterations of product
Increased ability to evolve product
Ability to start projects sooner (but not necessarily completed sooner)
Reactions
• Extremely positive, willing to invest in Agile training BUT
• Difficult to overcome inertia of ingrained development practicies
2
3. 3
Agile @ TI – Thoughts on Structure and Organization from October
‘05
Product Development
Small, empowered teams (3-5)
Minimal stakeholder documents and initial communication
• Initiation document, use case inventory/story list, critical wire frames and page
designs (those used to obtain approval from senior management)
Ongoing collaboration with technology to elaborate on prioritized storylist to support
iterative cycles
Technology
Small, empowered teams (4+ depending on timelines,etc.)
Integration of tracking and behavioral mechanisms to support customer-feedback loop
Weekly or bi-weekly software releases (after initial 2-3 week development cycle)
Local Markets
Provision of “beta” area on web site
Feedback on initial stakeholder documents
This assumes completion of earlier Strategic Marketing, Product Development, ISC
conversations
4. 4
Agile @ TI
What is Agile?
A conceptual framework for software development projects
Various implementations of the framework
Most often used in small organizations
Gaining acceptance in large organizations and enterprise software organizations
Not Web 2.0 software development
TI’s approach to Agile
Leverages many Agile concepts
Recognizes reality of where we are today vs. long-term goals
Provides an opportunity to address change in an evolutionary manner
• “Walk before you can run”
Key Agile Concepts
Individuals and interactions over processes and tool
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
5. 5
Agile @ TI – Early Observations
Agile will remind you of traditional “waterfall” methodologies
Similar steps, but repeated weekly or bi-weekly
Recycled concepts w/a “twist” – e.g. use cases => stories
Optional efforts are now enforced with a high degree of discipline – e.g. unit testing
“Flipped” ExtroVert from waterfall to Agile in the middle of the project
Introduced issues, but overall still feels directionally correct
Highlights issues with introducing Agile at TI – will customize the methodology, like other
organizations
• Opportunity to adjust the process for future projects
• Collaboration between Technology, Product Development and Marketing is critical
due to “just in time” estimation and prioritization process
TI’s ability to successfully leverage Agile development rests largely
on how the organization approaches Iteration 0 (or its variants)
Iteration 0 is Critical!
6. 6
Agile Development – The Ideal
•TI processes do not currently allow for assignment of resources prior to project approval
•This step is critical to estimating final release and production schedules
7. 7
Agile @ TI – Current Proposal (revised from October ‘05)
Obtain approval from senior management Approval Date(AD)
Product Development
Initiation document – business case, storyist V1.0, wire frames, etc.
Iteration 0 (I0) 2-4 weeks post AD
Product Development & Technology
Storylist V2.0 – Success criteria, confirm prioritization ,pre-IPM effort estimation
Environment – Create environments (Dev, QA, User Acceptance,etc.)
Prepare initial iteration schedule and release plan
**Review iteration schedule/release plan, revise if necessary
First iteration (I1) 5-7 days post I0
Technology, Product Development
See next slide for detailed efforts
Second iteration (I2) 1 week post I1
Technology, Product Development
Nth iteration (IN) 1 week post IN-1
Technology, Product Development
Release N Determined by team
Technology, Product Development
8. 8
Agile @ TI – Storylist Artifacts
• Story Cards
• Fundamental building block of Agile/XP
• Feature description
• Small, measurable
• Can be completed in 1-2 days by 1
developer
• Includes any relevant assumption(s)
• Used for preliminary estimation of effort
• Assigned a “pre-ipm” value
• Relative weighting – a scale of effort
• No direct correlation to number of days
for the effort
• Later refined into “ideal days” estimates
• Some teams use actual index cards
• Aggregate cards and create a file with
additional details to support next steps
As a USER
I want a home page for each neighborhood in my market that
displays only content related to that neighborhood
ASSUMPTION: Only content with a geocode
5
Pre-IPM
Points
Page 143
Story #151
9. 9
Agile @ TI – Weekly Iteration Schedule (actual)
Each day begins with a 15 minute “stand-up” meeting of all team
members
Day Day of Week Event Owner
1 Thursday AM Iteration Planning Meeting
Review of Past Iteration
Review progress
Demo of new functionality
Planning for Current Iteration
Story presentation
Iteration planning/tasking
Story selection/assignment
PM (Manish)
Developers
Developers & QA
BA (Sandra)
IPM (Olivier), PM (Manish)
Developers
1 Thursday PM Select Stories for the next iteration
Determine needed design and send to
Manifest Digital
Publish and distribute list of selected
story cards
Update MS Project plan and send to
Product Development project manager
(Jim Marzullo)
BA (Sandra), IPM (Olivier), PM (Manish)
BA (Sandra), PM (Manish), IPM (Olivier)
IPM (Olivier)
PM (Manish)
2-3 Friday & Monday Create story analysis artifacts for next
iteration
BA (Sandra)
4 Tuesday AM Publish and distribute story analysis
artifacts for next iteration to team
(evstoryreview@tribuneinteractive.com)
BA (Sandra)
5 Wednesday Noon Send feedback and request for
clarification to EvStoryReview mailing
list
Stakeholders
5 Wednesday PM Update and publish story analysis
artifacts for next iteration based on
feedback
BA (Sandra)
11. 11
Agile @ TI – Project Management Tools
Story List
Project roadmap
Issue management
12. 12
Agile @ TI – Project Management Tools
“Burn Down” charts and capacity charts
Measures the team’s velocity vs. overall project goal
Reflects the development capacity of the team
Should increase over time
13. Agile @ TI
Project post-mortem informed TI’s Agile approach
All story estimates are in ideal days w/contingency
• Point abstraction increases the difficulty of managing business stakeholders
Use explicit contingency until project stability supports confidence in velocity metrics
• Team velocity is sensitive WRT team dynamics, experience of business stakeholder, availability of
business stakeholder, etc.
Technology should play a greater role in story selection for early iterations
• Business stakeholders’ focus on consumer-facing features can compromise early infrastructure
stories
Test coverage should improve by 5% each iteration until 85-90%
• Team members will require additional time to master TDD
Next Efforts
Integrate distributed team members into project (in-progress, results are positive)
Integrate offshore team into projects(2nd attempt)
Permanent reconfiguration of team’s working environment
Investigate more sophisticated Agile project management tools
Finalize criteria for selection of Agile approach for other projects
Stakeholder sensibilities and availability
Aptitude and attitude of most likely team
Project’s business climate
13
14. 14
Agile @ TI – Next Steps
Resolve Iteration 0 disconnects
Develop estimates that allow us to answer typical senior management questions
Minimize amount time on detailed requirements in favor of actual product development
What is the minimum information that will satisfy business model justification and reasonably accurate
estimates in support of approval by senior management?
Resolve “just in time” estimation disconnects
Pre-IPM estimations are used to communicate broad schedule and timing, and obtain buy-in from
management
Subsequent story refinements may result in estimations that exceed pre-IPM estimates
Expand Training
Agile methodology, Story development fundamentals, etc.
Leverage a training organization
• Mesh “classroom” theory with ongoing, real-world learnings from ExtroVert
Select first 100% Agile project
• Incorporate the process from project inception to completion
Q&A