introducing agile development in traditional software development organizations

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

Upload: juliannacole

Post on 22-Jul-2015

158 views

Category:

Career


4 download

TRANSCRIPT

Agile @ TILast Updated 1/22/07J. 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

Sell ing Agi le 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 wil l remind you of tradit ional “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

“Fl ipped” 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 abi l i ty to successfully leverage Agile development rests largely on how the organization approaches Iteration 0 (or its variants)

Iteration 0 is Crit ical!

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 ADProduct 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 I0Technology, Product DevelopmentSee next slide for detailed efforts

Second iteration (I2) 1 week post I1Technology, Product Development

Nth iteration (IN) 1 week post IN-1Technology, Product Development

Release N Determined by teamTechnology, Product Development

8

Agile @ TI – Storyl ist Art ifacts

• 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 USERI want a home page for each neighborhood in my market that displays only content related to that neighborhood

ASSUMPTION: Only content with a geocode

5Pre-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 I teration Review progress Demo of new functionality Planning for Current I teration Story presentation I teration 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 ([email protected])

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

Issue management

Project roadmap

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 availabilityAptitude and attitude of most likely teamProject’s business climate

13

14

Agile @ TI – Next Steps

Resolve I terat ion 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 t ime” 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