Introducing Agile Development in Traditional Software Development Organizations

Agile @ TI
Last Updated 1/22/07
J. Cole
Intended Audience: Non-Technical

“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
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
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
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
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
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
 Nth iteration (IN) 1 week post IN-1
 Release N Determined by team

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
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)

10
Agile @ TI – Sample Story Narrative

11
Agile @ TI – Project Management Tools
Story List
Project roadmap
Issue management

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

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
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

Introducing Agile Development in Traditional Software Development Organizations

More Related Content

What's hot (20)

Viewers also liked (9)

Similar to Introducing Agile Development in Traditional Software Development Organizations (20)

Recently uploaded (20)

Introducing Agile Development in Traditional Software Development Organizations