Ilio Krumins Beens and Maureen McMahon: Kaplan Transition to Agile
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share

Ilio Krumins Beens and Maureen McMahon: Kaplan Transition to Agile

  • 989 views
Uploaded on

Ilio Krumins-Beens and Maureen McMahon discuss Kaplan's transition to agile at the BISG Agile Content Development Summit, 3/27/12.

Ilio Krumins-Beens and Maureen McMahon discuss Kaplan's transition to agile at the BISG Agile Content Development Summit, 3/27/12.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
989
On Slideshare
989
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
20
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide
  • 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

Transcript

  • 1. KTP transition to Agile Ilio Krumins-Beens Maureen McMahon
  • 2. Hi, I’m Ilio.ilio.krumins-beens@kaplan.com www.iliokb.com @iliokbagile
  • 3. MOTIVATION FOR CHANGE It took That’s NOT much longer than I expected! what I wantedNot clear There is toowho is responsible much processfor… 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
  • 4. Satisfaction (Baseline) Meets Adaptability Transparent Alignment Productivity Quality Schedule TTM100 80 60 0 11 0 0 40 4 20 7 0 44 44 46 26 42 19 17 0 -48 -33 -42 -59 -38 -56 -54 -20 -40 -11 -7 -12 -19 -60 -11 -19 -29 -80-100 Generally Satisfied Completely Satisfied Generally Dissatisfied Completely Dissatisfied
  • 5. Satisfaction (2.5 Months) Meets Adaptability Transparent Alignment Productivity Quality Schedule TTM100 80 60 13 13 11 2 40 11 5 5 20 44 58 47 33 38 44 28 0 -38 -18 -32 -44 -43 -38 -46 -20 -11 -40 -5 -11 -11 -14 -15 -60 -21 -80-100
  • 6. Satisfaction (5 Months) Meets Adaptability Transparent Alignment Productivity Quality Schedule TTM100 80 18 15 18 60 18 15 15 13 40 20 62 68 52 56 64 55 44 0 -18 -12 -2 -21 -21 -18 -24 -38 -20 -2 -2 -9 -9 -6 -40 -6 -60 -80-100
  • 7. Satisfaction (7 Months) Meets Adaptability Transparent Alignment Productivity Quality Schedule TTM100 80 17 14 15 60 18 16 28 28 40 20 47 43 53 58 59 63 53 0 -19 -13 -21 -20 -17 -18 -25 -20 -5 -17 -8 -7 -10 -3 -6 -40 -60 -80-100
  • 8. -90-80-70-60-50-40-30-20-10 0 Productivity-70 Transparent Alignment Quality -44 -47 Baseline Adaptability -54 -55 Schedule TTM -75-83 What Changed? 0 10 20 30 50 60 70 80 40 Productivity Transparent Alignment Quality Adaptability 7 Months Later Schedule 75 71 71 73 75 78 69 TTM
  • 9. Implemented Dedicated Teams Central Pool 15 Cross-Functional TeamsBAs PMs Dev QA 1 2 3 4 5 6 Product 1 2 3 Strategic Shared Services 1 2 3 4 5 6 Shared Services (IT Ops, DB, etc.,) Shared Services (ITOps, DB, etc.,) Production Support
  • 10. Implemented an Iterative Approach Source: Evanetics
  • 11. Time-To-Market (In Calendar Days) 2010 2011 (Pre-Agile) 2011 (Agile)250200 192150 14010050 27 0
  • 12. IF YOU’RE GOING TO TRY AGILE …
  • 13. Awareness that there is room for improvementDesire to changeAbility to work in an agile mannerPromote early success to build momentum and getothers to followTransfer the impact of agile throughout theorganization so it sticks Source: Mike Cohn, ADAPTing to Agile for Continued Success, Agile 2010.
  • 14. Think First … and define what success looks like •Prioritize your stakeholders •Get a transformation sponsor •Agree to what success will look like •Create and communicate your plan •Baseline current state •Get external validation and help© Black Country History Museum www.blackcountryhistory.org
  • 15. Agile Transition Roadmap as of 10/14/2011 2Q11 3Q11 1Q12 4Q12 4Q13Phase 1 - Prototype 2 – Transition 3 – Roll Out Agile 4 – Establish 5 – Technical to Dedicated Management Agile Practices Excellence Teams (Scrum) Practices Beyond TechFeatures 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 RoomsUsers 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 VendorsTools 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: JnLRun 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
  • 20. Maureen McMahonEVOLVING AGILE FOR PUBLISHING
  • 21. Agile Initiative at Kaplan PublishingWORKING NOT WORKING (YET)Customer focus Comfort level with rolesAbility to adjust plan in response to learning Hard deadlines + strict requirementsAbility to iterate Freezing requirements between sprintsBusiness/tech collaboration Separate standups not scalableOrganization-wide buy inFace-to-face communicationResults
  • 22. Thank You!