3. MOTIVATION FOR CHANGE
It took
That’s NOT much longer
than I expected!
what I
wanted
Not clear There is too
who is responsible much process
for… and overhead
The product does If it isn’t done now
not have all the there will never be
features another chance
I requested
Photographer: Bridget Coila
13. Awareness that there is room for improvement
Desire to change
Ability to work in an agile manner
Promote early success to build momentum and get
others to follow
Transfer the impact of agile throughout the
organization so it sticks
Source: Mike Cohn, ADAPTing to Agile for Continued Success, Agile 2010.
15. Agile Transition Roadmap as of 10/14/2011
2Q11 3Q11 1Q12 4Q12 4Q13
Phase 1 - Prototype 2 – Transition 3 – Roll Out Agile 4 – Establish 5 – Technical
to Dedicated Management Agile Practices Excellence
Teams (Scrum) Practices Beyond Tech
Features Pilot Agile and • Dedicated Teams • Focused Support for 8 • Performance •Automated
Agile Inspired • Select Product teams Management Regression test
practices on ATA Owners • Product owners tools •Compensation implemented
Fixes, • Comm. Program • Healthy PBL for Tier 3-4 practices •Continuous
Nursing RN • Develop Teams •Integration into integration
OC LSAT 2.5, Assessments • Sync with IMO Budget Cycle •Automated builds
MCAT Catalyst • Healthy PBL for • Dashboard Reporting •Develop Better •Increased
Tier1-2 Teams • Improve Off-shore Product Visioning / deployments to
• Focused support vendor Agility Road mapping production
for 7 teams • Co-locate Teams techniques
• Set up Agile Team
Rooms
Users Grad Apps, Tier 1-3 teams Tier 1-4 Teams Kaplan Execs Tier 1-4 Teams
Nursing, LSAT, and Kaplan Execs General Kaplan Kaplan Execs
Catalyst General Kaplan audience audience General Kaplan
Stakeholders Offshore Vendors Tier 1-4 Teams audience
Offshore Vendors
Tools Jira, Daptiv Jira, Jira, Jira, TBD
Confluence Confluence, Confluence,
PlanetK, PlanetK, PlanetK,
Daptiv, Daptive, Virtual Meeting
Virtual Meeting Tools Tools, Success Factors
16. Eat Your Own Dog Food
Photographer: JnL
Run your transformation effort like an Agile Project
17. Scaling Agile Practices
• Coaching a must
• Get an Expert to help you
• Develop support mechanisms for agile teams
• Tailor after trying base practices
(with expert help)
• Align Roadmaps
• Focus on Technical Excellence that enables
agility
• Collocate Teams (If Possible)
• Extend Agile beyond internal tech teams
18. Thinks to watch out for
• Agile is NOT a panacea
• Watch out for common misconceptions
• We’ll go agile after two day training
• Insufficient depth/competency in the product
owner role
• Waterscrumming, Agile-Fall, Scrumbut,
• Inadequate coordination of vision and delivery
strategies
• Insufficient support / funding for a
transformation effort
19. Implemented the right way, Agile will
leave you satisfied
Photographer: Brain E. Ford
23. Agile Initiative at Kaplan Publishing
WORKING NOT WORKING (YET)
Customer focus Comfort level with roles
Ability to adjust plan in response to learning Hard deadlines + strict requirements
Ability to iterate Freezing requirements between sprints
Business/tech collaboration Separate standups not scalable
Organization-wide buy in
Face-to-face communication
Results
Worked with Software and Web application teams for 15 yearsWorking with Agile (Scrum / XP) teams for over 8 years.Rolled out Scrum practices at Oxygen Media and WeplayCurrently, Executive Director, Agile Practices, Kaplan Test PrepCo-Authored / Presented: "Using Agile Practices to Spark Innovation" HICSS 2007, "Collective Product Ownership with Scrum" Agile 2007, "Great Scrums Require Great Product Owners" HICSS 2008“Rolled out Agile to the Enterprise” at Agile NJ in FebruaryCertified Scrum Master (CSM), Certified Scrum Product Owner (CSPO), Project Management Professional (PMI)<Click>I’d like to get a sense of how many of you are already familiar with Agile Practices so I know how in depth to go. -> Raise your hand if you’re new to agile and would appreciate basic concepts explained. -> Raise your hand if you are well versed in agile.
When I joined Kaplan over two years ago, I was impresesed how motivated and hard working our teams and business partners were. Despite this, the feeling that I often got when talking with people was <click>.<Explain sentiments>Success CriteriaIncreased transparency on status of feature development through iterative developmentClearer accountability to product decisions through identification of single product ownersImproved partnership between implementation team and business partnersMore productivityIncreased “happiness quotient” of implementation and business partners
Needed to assess baseline before implementing any changes.Developed a survey with the Research Department which is well regarded within the company for trustworthiness to assess satisfaction with current software practices. Distributed the survey to a sampling of both business partners and implementation partners. How satisfied are you with our current software practices in each of these areas:Adaptability - Ability to Respond to change prioritiesTransparent about project progress and statusAlignment between IT and business objectivesHighly productiveHigh-quality finished productMeets agreed-upon scheduleRapid time to marketAny guesses on the level of satisfaction? <Click>3% Completely Satisfied34% Generally Satisfied47% Generally Dissatisfied15% completely Dissatisfied That’s 62% unsatisfied and only 3% completely satisfied across the board. Yikes!><><><><><>My objective was to move team members and business partners from unsatisfied to satisfied on these areas.
After 2.5 months, we moved to 51% satisfied with 9% complete satisfied.
After 5 months we went to 73% satisfied with 16% completely satisfied.
After 7 months we’re still at 73% satisfied, but moved up to 16% satisfied in the top box of completely satisfied.
What Changed? <click> to cause the baseline of 63% unsatisfied to 7 months later having 73% satisfied?Well, we didn’t hire a completely new implementation teams. We didn’t replace all our business stakeholders. And we didn’t change managers so it wasn’t that technology, business partners, or management sucked.Same people. Hmmm…
Move from a central pool of resources to 15 dedicated teams. Our goals were to:- Empower Business units more autonomy in business discretionary projects- Provider an easier means to realize “quick wins”Led implementation team through one empowered voice ( product owner) Embrace change as part of project implementationCreate stronger sense of ownership and deeper domain knowledge through team based assignmentsEnable closer coordination between business and tech partners
<Explain high level difference between waterfall / agile>Selected product owners who set the priorities for the implementation teams to execute against, teams worked against the highest priority stuff, started working in shorter iterations ( 2- 3 weeks) where teams demoed working, tested, and “potentially shippable code” at a regular cadence.
Any guesses how many calendar days the average project took in the old model? Any guesses on the new model?Result of using dedicated teams delivering iteratively was:Result: Time to Market Reduced dramatically. 2010 n=722011 (Pre-Agile) n = 322011 8/1 – Late Nov.<Explain Grapefruits and Tangerines>
This is an acronym that I wasn’t something I wasn’t familiar with when I started on my agile transformation. I was introduced to it by Mike Cohn, and it resonated with me so I am sharing it with you.
Before you jump into Agile <click>, it’s important to define the problem or opportunity that you want to address in going to agile. The best success criteria is tied to KPIs or specific business metrics. And you should baseline before you start the transformation.Success CriteriaIncreased transparency on status of feature development through iterative developmentClearer accountability to product decisions through identification of single product ownersImproved partnership between implementation team and business partnersMore productivityIncreased “happiness quotient” of implementation and business partners
Before creating a roadmap, we created a vision statement.The Agile CoE establishes clear lines of responsibility and accountability. Product owners are given authority to define what their delivery team works on and are accountable to the value that their team delivers. Teams are responsible the quality and extensibility of the features they build .. [and] are given the authority to determine the best way to execute and deliver against the product owner’s vision. Managers of product owners and tech teams are responsible for removing impediments that are blocking teams from reaching their optimal performance.The Agile CoE supports small, empowered teams to achieve the product owner’s vision by planning, developing, testing, and demonstrating “potentially shippable” features to stake holders every iteration. The Agile CoE helps teams become more cohesive, self-governing, and continually improve through on-going coaching and assessments. Agile principles become ingrained into the corporate culture through compensation and performance management practices, integration into the annual budget process, and alignment to the overall vision of becoming a best of breed digital company.
<Explain Product Development Metaphor>When rolling out agile practices, the equivalent of “eating our own dog food,” is running your transformation effort like an agile project. Doing so allows you to:demonstrate the practices you are asking teams to followinspect and adapt to the specific needs of your organizationgain support of executives and stakeholders with transparency and demonstration of incremental progress