O SlideShare utiliza cookies para otimizar a funcionalidade e o desempenho do site, assim como para apresentar publicidade mais relevante aos nossos usuários. Se você continuar a navegar o site, você aceita o uso de cookies. Leia nosso Contrato do Usuário e nossa Política de Privacidade.
O SlideShare utiliza cookies para otimizar a funcionalidade e o desempenho do site, assim como para apresentar publicidade mais relevante aos nossos usuários. Se você continuar a utilizar o site, você aceita o uso de cookies. Leia nossa Política de Privacidade e nosso Contrato do Usuário para obter mais detalhes.
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
Ilio Krumins Beens and Maureen McMahon: Kaplan Transition to Agile
KTP transition to Agile Ilio Krumins-Beens Maureen McMahon
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
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.
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
Eat Your Own Dog Food Photographer: JnLRun your transformation effort like an Agile Project
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
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
Implemented the right way, Agile will leave you satisfied Photographer: Brain E. Ford
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