Oct 2012 Presentation for Agile NJ
•Download as PPTX, PDF•
2 likes•963 views
Presentation given at Agile NJ on Feb 6, 2012 about rolling out Agile to the Enterprise.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Similar to Oct 2012 Presentation for Agile NJ
Similar to Oct 2012 Presentation for Agile NJ (20)
Recently uploaded
Recently uploaded (20)
Oct 2012 Presentation for Agile NJ
- 1. Rolling Out Agile to the Enterprise Ilio Krumins-Beens
- 2. Hi, I’m Ilio Krumins-Beens. I am passionate about Agile.
- 3. (1) Achieve Executive Buy-In (2) Respond to Change (3) Scale Agile Practices My Objective Photographer: Erich Stüssi Photographer: familymwr
- 4. USING A REAL EXAMPLE
- 5. Satisfaction with current software practices (Baseline) Productivity Transparent Alignment Quality Meets Adaptability Schedule Rapid TTM 0 -10 -20 -30 -40 -44 -50 -47 -54 -60 -55 -70 -80 -90 -70 -75 -83
- 6. Satisfaction with Technology (8 Months later) Productivity Transparent Alignment Quality Meets Adaptability Schedule Rapid TTM 100 86 90 80 70 60 50 40 30 20 10 0 79 71 80 70 60 57
- 7. 0 -10 -20 -30 -40 -50 -60 -70 -80 -90 Rapid TTM Schedule Adaptability Quality Alignment Transparent Productivity -44 -47 -54 -55 -70 -75-83 Productivity Transparent Alignment Quality Adaptability Schedule Rapid TTM What Changed? 100 90 80 70 60 50 40 30 20 10 0 71 86 79 80 70 60 57
- 8. Implemented Dedicated Teams Central Pool 15 Cross-Functional Teams BAs PMs Dev QA 1 Product Strategic Shared Services Shared Services (IT Ops, DB, etc.,) Production Support 2 3 1 2 3 1 2 3 4 5 6 4 5 6 Shared Services (ITOps, DB, etc.,)
- 9. Implemented an Iterative Approach Source: Evanetics
- 10. Time-To-Market (In Calendar Days) 2010 2011 (Pre-Agile) 2011 (Agile) 250 192 200 150 140 100 50 0 27
- 11. (1) Achieve Executive Buy-In (2) Respond to Change (3) Scale Agile Practices My Objective Photographer: Erich Stüssi Photographer: familymwr
- 12. Achieve Executive Buy-In • • • • • • • • Prioritize your stakeholders Get a transformation sponsor Agree to what success will look like Create and communicate your plan Get external validation and help Show incremental progress Promote early success to build momentum Be proactive and completely transparent
- 13. Agile Transition Roadmap as of 10/14/2011 2Q11 3Q11 1Q12 4Q12 4Q13 Phase 1 - Prototype 2 – Transition to Dedicated Teams 3 – Roll Out Agile 4 – Establish Management Agile Practices (Scrum) Practices Beyond Tech 5 – Technical Excellence Features Pilot Agile and Agile Inspired practices on ATA Fixes, Nursing RN OC LSAT 2.5, MCAT Catalyst • Dedicated Teams • Select Product Owners • Comm. Program • Develop Assessments • Healthy PBL for Tier1-2 Teams • Focused support for 7 teams • Focused Support for 8 teams • Product owners tools • Healthy PBL for Tier 3-4 Teams • Sync with IMO • Dashboard Reporting • Improve Off-shore vendor Agility • Co-locate Teams • Set up Agile Team Rooms • Performance Management •Compensation practices •Integration into Budget Cycle •Develop Better Product Visioning / Road mapping techniques •Automated Regression test implemented •Continuous integration •Automated builds •Increased deployments to production Users Grad Apps, Nursing, LSAT, and Catalyst Stakeholders Tier 1-3 teams Tier 1-4 Teams Kaplan Execs General Kaplan audience Offshore Vendors Kaplan Execs General Kaplan audience Tier 1-4 Teams Tier 1-4 Teams Kaplan Execs General Kaplan audience Offshore Vendors Tools Jira, Daptiv Jira, Confluence PlanetK, Daptiv, Jira, Confluence, PlanetK, Daptive, Virtual Meeting Tools Jira, Confluence, PlanetK, Virtual Meeting Tools, Success Factors TBD
- 14. Q4 2011 Agile CoE Release Plan Release Goals Get teams to minimum level of self- sufficiency on Product Owner (Product Vision, Roadmap, Release Planning, and Backlog management) and team practices. Improve alignment of SBU objectives to projects through: •Creation of uber roadmap(roadmap of roadmaps) •Involving Product Owners and Finance leads in project creation and tracking •Introduction of portfolio management practices Straw man Performance management practices for agile teams Collocate teams Sprint 7 Sprint 8 Sprint 9 Sprint 10 Sprint 11 Dates 10/19 – 11/1 11/2 – 11/15 11/16 – 11/29 11/30 – 12/13 12/14 – 1/10 Sprint Themes Project Process and Alignment Kickoff Introduce Product Owners and Finance Populate Roadmap of Roadmap Confirm Roadmap of Roadmaps with Senior Execs Performance and Portfolio Practice Recommendations Epics •Remote Training •New Project Workflow •Roadmap Repository •KBS / Kaptest Process •Jira – User mgmt, Carryover Guidance, Training •PO and Finance Mtg •Inc. Visit •Why Uber Roadmap Mtg •Team Specific Metrics •Populate Uber Roadmap •Release Plans added to Daptiv •Collocate teams •Roadmap Review with Senior Execs •Performance mgmt process •Cost Per Team •Review 2012 teams with PO and Exec Sponsor •Continue Performance management proposal •Portfolio planning proposal
- 15. (1) Achieve Executive Buy-In (2) Respond to Change (3) Scale Agile Practices My Objective Photographer: Erich Stüssi Photographer: familymwr
- 16. Eat Your Own Dog Food Photographer: JnL Run your transformation effort like an Agile Project
- 18. Release Planning
- 19. Sample Epics / User Stories • As the CTO, I have roadmap to Technical Excellence that lays out the priority and timing of implementing Agile Development, Quality, and Release Practices, so that I can track progress against implementing these. • As a Product Owner, I am educated on the budget monitoring process, so that I can work with the Financial Lead effectively. • As a Scrum master, I attend a workshop to learn best practices around meeting facilitation and conflict resolution, so that I can do my job more effectively. • As the Resource Manager, I have gotten all remaining Agile Team members up on time sheets, so that time reporting will cover all team members.
- 23. Recent Sprint Review Process / Governance: • • • • • 2011 Performance Evaluations Update Time Reports Update Resources in Daptiv Creating New Projects In Daptiv Scrum of Scrums Survey Alignment • Budget Monitoring • Technical Excellence Roadmap • Roadmap of Roadmaps Coaching / Support Recommendations • Post-Mortem on Team Composition • Release Planning Best practices Training / Workshops: • Product Owner and Effective Stakeholder Management – APLLE • Research and Agile Teams - APLLE • Facilitation Techniques for Scrum Masters • • • • • • Observe Pre-College Ceremonies SF1 Sprint 0 Support Monitor Scrumban Attend Demos Team coaching New Product Owner support Communication • Blog posts (2) Performance management • Implement Recognition Program
- 24. EXAMPLES OF INFORMATION SHOWN IN SPRINT REVIEWS
- 25. High Level Assessment (HLA)
- 26. HLA Burndown
- 27. Challenges Identified • • • • • • Fractional assignments Off-Shore Vendors External Factors affecting team velocity Product Owner Empowerment Adopting new roles still a challenge Resource Constraints limiting amount of team support
- 30. PO and Fin Lead Alignment Session Objectives: Agree on process for roadmaps, CERs, and IMO requests Identify 2012 Projects that need CERs
- 31. “BUT, YOUR NOT DELIVERING WORKING SOFTWARE”
- 32. Why it works? • Demonstrate the practices you are asking teams to follow • Creates transparency of progress • Enables short feedback loops • Able to effectively Respond to Change
- 33. Trust me, you’ll like eating your own dog food Photographer: Brain E. Ford
- 34. (1) Achieve Executive Buy-In (2) Respond to Change (3) Scale Agile Practices My Objective Photographer: Erich Stüssi Photographer: familymwr
- 35. Scaling Agile Practices • • • • • Coaching a must Develop support mechanisms for agile teams Align Roadmaps Extend Agile beyond internal tech teams Focus on Technical Excellence that enables agility • Collocate Teams (If Possible)
- 36. How much coaching support do you have? Sprint Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5 Sprint 6 Sprint 7 Sprint 8 Sprint 9 10 Support Ranking Pilot Team Pilot Team Tier 1 Tier 1 Tier 1 Tier 1 Tier 2 Tier 2 Tier 2 Tier 2 Tier 3 Tier 3 Tier 3 Tier 3 Tier 3 Tier 4 Tier 4 7/278/9 8/108/23 8/249/6 9/079/20 9/2110/4 10/510/18 10/19- 11/211/1 11/15 Sprint 11 11/16- 11/30- 12/14/ 11/29 12/13 -1/10 Legend Focused support (over 10 hours of dedicated team support within a sprint) Basic support (5-10 hours of dedicated team support per sprint) Limited support (less than 5 hours of dedicated team support within a sprint)
- 37. “People support a world they help create.” - Dale Carnegie Agile Transition Teams provide an opportunity for those who will be going through a transformation to provide feedback and feel listened to. Quote Taken from : Building an Elite Product Development Team workshop, 2/3/2012
- 38. SCRUM SCRUMS OF 15 Cross-Functional Teams 1 3 1 2 3 1 Photographer: Philippe Heckel 2 2 3 4 5 6 4 5 6
- 39. Scrum of Scrum Wall
- 42. Align Roadmaps Objective: Create alignment across Business Systems Roadmaps. Focus business goals, identify cross-team dependencies, risks, and provide holistic view of the features being delivered
- 43. Extend Agile Beyond Teams • • • • • Annual Reviews Hiring Practices and Career Paths Recognition programs Pay / Incentives Alignment to Budgeting and Finance Processes
- 44. Technical Excellence that Enables Agility – Development practices (TDD, BDD, Pair Programming, Refactoring, Emergent Design) – Automated testing – Continuous Integration – Frequent delivery
- 46. Tips if your transformation is under resourced • • • • • • Attend all demos Create a “Community of Practices” Develop targeted workshops / materials Share books, blogs, white papers, resources Promote change agents Encourage participation in agile community
- 47. (1) Adapt to Changing Needs (2) Achieve Executive Buy-In (3) Scale Agile Practices My Objective Photographer: Erich Stüssi Photographer: familymwr
- 48. 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.
- 49. Mike Cohn’s ADAPT Tools Awareness Ability • • • • • • • • • Communicate that there’s a problem Use metrics Provide exposure to new people and experiences Focus attention on the most important reasons or two for changing Desire • • • • • • • • • Communicate that there’s a better way Create a sense of urgency Build momentum Get the team to take agile for a test drive Align incentives (or, at least, remove disincentives) Focus on addressing any fears Help people let go Don’t discredit the past Engage everyone in the transition Source: Mike Cohn, ADAPTing to Agile for Continued Success, Agile 2010. Provide coaching and training Hold individuals accountable Share information Set reasonable targets Just do it Promote • Publicize success stories • Host an agile safari • Attract attention Transfer • Transfer the effects of agile beyond the current group • A team transfers to its department • A department transfers to its division, etc. • If you don’t transfer, the transition will eventually and inevitably fail • Too much organizational gravity pulling us back toward the status quo • Example: - f you don’t align promotions, raises, annual reviews, those will work against you
- 50. Agile Enterprise Adoption: Observed Antipatterns • Insufficient depth/competency in the product owner role • Inadequate coordination of vision and delivery strategies • Waterscrumming-Agile development in a nonagile portfolio/governance model • Insufficient refactoring of testing organizations, testing skills (TDD), test automation • Lack of basic team proficiency in agile technical practices Adapted from: Dean Leffingwell, Scaling Software Agility: Agile Portfolio Management, March 17, 2009, Slide 30
- 51. Additional Resources Dean Leffingwell’s Blog: http://scalingsoftwareagilityblog.com/ Portfolio Management in the Scaled Agile Framework : YouTube and presentation deck
Editor's Notes
- 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 2008Certified Scrum Master (CSM), Certified Scrum Product Owner (CSPO)<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.
- We all come here with different levels of agile expertise equipped with different tools and techniques to help organizations go through change. Some of us may have amazing tool kits, others of us may have a sparse but functional set of core tools, and others of us might be trying to use umbrellas to hammer in nails. My goal is for you to walk away better equipped to approach a transition to agile. I am going to be primarily focusing on how:-> how to achieve executive buy-in-> why it is essential to be able to adapt to the changing needs and priorities of your organization and a technique for doing this-> mechanisms to support scale agile across multiple teams. To help with this, I want to tell a story …
- Working at a company where:Low Trust between the business and technology.Business had no confidence that Tech would meet it’s commitment. Real “Us vs. Them” MentalityDespite heroic efforts and long hours, business felt underserved by technology.Key: Awareness of a problem.CEO gets convinced that we should try Agile. After a brief pilot, CEO tasks me to roll it out to the entire organization in 6 months. Respond to change prioritiesPositive return on investment (ROI)Alignment between IT and business objectivesTransparent about project progress and statusHighly productiveHigh-quality finished productMeets agreed-upon scheduleRapid time to marketExplain SurveyGood thing was: Awareness of a problem.
- 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 technologists in the following areas.<Click>We asked:How satisfied are you with our current software practices in each of these areas:Highly productive, Transparent about project progress and status, Alignment between IT and business objectives, High-quality finished product, Respond to change priorities, Meets agreed-upon schedule, have a Rapid time to market
- April – BaselinePilot 3 teams for 2 months. September – initial surveyDecember – 2nd surveyKey: Desire to change.
- Wasn’t that Technology or business partners sucked. Same people. Survey sample didn’t change. 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.
- <Explain>Result: Time to Market Reduced dramatically. 2010=722011 (Pre-Agile) = 322011 8/1 – Late Nov.
- Let me talk briefly about how I went about achieving executive buy in.
- As I mentioned early, there was clearly Awareness of a problem, and a Desire to Change. I prioritized stakeholders by interest and influence. Those of high power and interest are ones to manage closely.I met with the CEO, CTO, Chief Administrative Officer (CAO), Division Presidents, VP of Development, Project Sponsors, Tech Leads, Developers, Project Managers, Business Analysts, QA Leads, Customer Service reps (as a proxy for external customers), and internal users that the technology group served. I asked open ended questions to understand what the interviewee wanted from the transformation and to identify what was and was NOT working in the current process. {Explain Bullets}The following Misconceptions can sink your transformation:* Agile teams are always 5-10x better.* Becoming agile is easy.* Only technology needs to change.Going Agile is NOT a Panecia.<Explain Bullets>
- 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.
- There is NO WAY you can plan your Agile Transformation effort from A-Z and expect it to go perfectly to plan. You NEED to have a way to inspect, adapt, show incremental and progress. Here’s how to do it.
- <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
- <Explain how the CoE uses these roles, ceremonies, artifacts.>
- Here are some example stories. All have acceptance criteria that explain the conditions of satisfaction. In Sprint planning, the team does Planning Poker to estimate the story point value and then we commit to how many points we can take on based on historical velocity. Stories get broken down into Tasks.
- <Add Picture of physical task board if possible>Throughout the sprint we track progress against completing these stories with a burn down. We keep a physical task board, burn down, in addition to the backlog management system. Our team room is in a very public place (purposefully), and Scrum of Scrum is held there so scrum masters see that we’re following the practices we’re asking teams to do. Also, anyone struggling with a ceremony can attend ours.
- This is something we’ll show at a sprint review. A listing of all the short titles done in a srpint. And we’ll select a few to demo. Average of 20 – 25 stories per sprint.½ - 3 points
- The agile coaches working with the teams assessed all the teir 1-4 teams on whether they had a None, Somewhat working,
- After 4 sprints.Fractional assignments – Fractional assignments are not increasing productivity. Instead, high quality professionals are having challenging working on two or more teams at a time.Off-Shore Vendors – Number of vendors, geographic distance, time shifting, ramp down, and cultural differences all challenges to agile implementation.External Factors affecting team velocity - Coordination and communication with Tech Ops on major initiatives affecting team velocity (cage migration, server consolidation, software upgrades). Product Owner Role and Empowerment should be empowered by SBUs and any decision making should occur prior to being communicated to the teams for being included in sprint planning.Adopting new roles still a challenge. Team self-organization works both ways: team members are expected to take initiative and scrum masters should not feel that the members step on their toes. This will take time for some team members.Resource Constraints limiting amount of team support
- A small team – we have full team members, as well as three fractional members – can reach a lot of people in a short period of timeSince August, we’ve reached nearly 400 peopleNote: Includes people who have been to multiple training sessionsActual face-to-face training (or remote)
- Small differencesFractional ResourcesProduct Owner / Scrum Masters part of implementation teamMore Work-In-Progress Don’t Identify a single sprint goalFractional ResourcesI often have fractional resources (someone who is on more than one team) as part of a transformation team, where as I am against it on a agile software team. It is not because, most organizations under invest in the resources required to initiate and sustain a large transformation. A successful transformation requires many different skills beyond those proficient in coaching agile practices. If possible, I like to get representation from Project Management Office (PMO), Human Resources (HR), Communications, and Finance on the transformation team. This is for several reasons:being part of the transformation team allows these people to learn about agile practices first hand (because you are running the project like an agile project). These people will act as force magnifiers for the agile transition with their colleaguesif you are on a team (and feel part of that team) you will be much more invested as compared with spending X% of time supporting another person’s initiative it allows me to leverage the specialized skill set and experience the person brings with them People from shared services Finance and HR often have unique and valuable perspectives on the organizations culture. They can provide a helpful perspective in considering how to approach your transformation. Sprint Planning and During the IterationOn software teams, I advise product owners to present a sprint goal so the team can rally around building a set of related features. On a transformation, the team is often working on many different efforts, so having a singular sprint goal is less valuable. It is a MUST however to have goals for release planning and clearly defined objectives when creating your transformation road map.In sprint planning, I also have found it helpful when members of the team select which stories they want to work on during sprint planning. Having a point person see a story through maintains continuity and helps manage external dependencies. Sometimes transformation team members select stories in-line with the expertise that that person has, but frequently another person will ask to work on it, so they can get experience in that area or to balance out the distribution of work. Every sprint, however, we find that multiple people collaborate on tasks within that story. This is due either to one person having extra capacity, or someone having too much on their plate. This happens informally, but also during our daily scrum if we're trending behind based on our sprint burn down chart. When working with a software team, I tell them to limit the Work in Progress (WIP) and focus on completing the highest priority stories in the sprint backlog first. The stories in a transformation backlog often have dependencies outside the team, so I find the my transformation teams will have more a higher percentage of open stories a few days into a Sprint than a typical software team. Preparing for the Sprint ReviewTransformation teams may need choose what they present at the sprint review and spend more time preparing the presentation than a software team. I advise software teams to show all the features they completed in a sprint and spend as little time as possible in preparing fancy power points for the demo, because the working software they build should be the focus of the Sprint Review. The general rule of thumb I give to software teams is NOT to spend more than 2 hours collectively preparing for the demo. It is important to make sure participants attend a well run demo, but completing the features prioritized by the product owner according to the team’s definition of done is the team’s top priority. I have found that transformation teams cannot present everything they work on in a sprint at the demo. Transformation teams work on meta-stories that require being creative about the best way to show them at the demo. On average, the transformation team that I am working with completes between 20 and 25 stories a sprint. If we were to try and demo each of these, the sprint reviews would be 4 hours long and my team would have to spend an inordinate amount of time preparing for the demo. Instead, we select a few stories that we want to highlight at the sprint review and tend to spend slightly a bit more time preparing for our demos than the typical software development team. A few days before the end of the sprint, my transformation team will take 5 minutes after a daily scrum to indicate which stories be believe should be shown in the sprint review. We do a silent vote, where each member gets three votes and they can apply 1 - 3 votes to any story. The stories with the highest votes are usually are the ones we demo. As product owner, I reserve the right to select other stories to demo, but most often the team selects the stories that I think are important to show. Furthermore, hearing why team members believe a specific story is valuable to highlight often convinces me.We rotate demo deck duty, and the primary person who worked on the story prepares how to demo the story at the sprint review. S/he will create the materials for the sprint review and send to the person on demo deck duty who compiles everything in one presentation. We do a run through the day before the sprint review and each person who is presenting explains what they want the audience to take away from their presentation. The team gives each other feedback and we fine tune the presentation prior to the sprint review. Our sprint reviews are scheduled for an hour and often run that long. I email a brief description of what is going to be covered the day of the demo to key stakeholders and typically 10 - 25 stakeholders show up. At the start of the demo, we display a list of all the stories we worked on in the sprint and with a different color font indicate which ones we plan to present. Anyone in the audience can request that we speak to a story that is NOT selected for the demo. After that, the team takes turns demoing what was selected to highlight. Often we get feedback during the demo or suggestions on things that we can work on in future sprints. We always speak to the progress we are making in the transformation and cover how we are doing against the transformation roadmap and release goals. The Sprint Review follows the same agenda that our software teams follow.SummaryOverall, I try to run an transformation as similar as I can to an agile software project. Sure, the output of a software team and transformation team are different, but the basic principles behind why agile works applies to both. If you try to run a mid-to-large transformation like a waterfall project your chance of success is much less. You need to have a motivated team that is focused on delivering highest value, able to respond to the changing needs of the organization, focused on quality, and that is continually reflecting on how it can get better. Although fractional resources are part of the transformation team, asking them to present their work often makes them an extremely invested members of the team. All the members of my transformation team take our sprint commitments very seriously. We are ruthlessly transparent when we don’t complete stories. There is a temptation to alter the acceptance criteria to count stories as being complete before the review because transformation stories often have external dependencies. I advise that you stick to the initial acceptance criteria discussed in sprint planning and use the sprint review to surface the blockers that prevented the transformation team from completing the story. By showing your incremental progress against the transformation roadmap and release goals, the team proves that it is delivering value. Holding a consistent sprint review creates a feedback loop with your stakeholders. By working in iterations or sprints, you can adjust the stories planned for the next sprint to address issues surfaced in the demo or to address the highest priority issues.
- In the time remaining I want to discuss practices the practices that we use to scale agile to 15 teams. Later I reference authors that have scaled agile practices to 50 – 100 teams.
- Staggered coaching – Focused which is more than 10 hours of support per sprint, Basic 5 – 10 hours, limited (less than 5)
- Agile Transition Teams. - Dave was wasn’t using this in the context to suggest that Coaching Mantra.Agile transition teams can take two forms:A Dedicated team who is responsible for executing against the agile transformation.A group of cross-functional stakeholders who give part of their time to help with the transition.
- Purpose: Ensure communication across teams, especially focused on integration / overlap.(15 minutes Check-In / 15 minutes other issues: Release Attendees: Facilitator, Scrum Masters, Tech Representation (Optional), and Members of Transition Team (Optional)Duration: 30 minutes / Frequency: Twice a week*Agenda:What has your team done since we last met?What will your team do before we meet again?Is anything slowing your team down or getting in their way?Are you about to put something in another team’s way?Status of Cross-Team Dependencies (if any)Parking Lot ItemsRelease Related QuestionsAnnouncementsCoE Attendance: Opportunity to see what’s issues the team are dealing with. Often time use the Working Agreement:If you cannot attend a specific meeting, please delegate and empower the delegate to provide the update for your team.Other Issues covered: Release issues, Hard DependenciesOther companies use it as a time to share “Dev Notes”
- Add picture of physical board if possible.
- Purpose: Address any impediments raised by the dedicated teams that could not be resolved informally. Must be: It is an action-oriented meeting where issues are resolved and/or next steps are determined in the meeting itself.Attendees: Facilitator, CTO, All Tech Managers, Product Owner of Transformation, necessary Scrum Masters, and any other ad hoc participants requiredDuration: 30 minutes / Frequency: Weekly* (Canceled if no issues)Deadline: Items for review no later than 5 p.m. the day prior to the meeting.Frequency of holding meeting: 25% of the time. Weighted more heavily when we started the transformation.Many of the issues raised are NOT specific to agile implementation.
- <Explain>Questions on Shared Resource Form:What dedicated agile team is making this request?What is the Shared Service Role that is being requested?In one or two sentences, please describe your request.Is this request associated with a JIRA ticket? If yes, include this information here as well.What dates / sprint / release will the shared service resource be needed? You might not know everything just yet, but any info you can provide will be helpful.
- Held multiple workshops where Product Owners presented to each other the projects / features they want to accomplish. Expectation was that the near term is more well defined than the long term. Identified risks, dependencies between teams. Maintain a physical roadmap of roadmaps. Product Owners meet twice per month to update each other.
- We all come here with different levels of agile expertise equipped with different tools and techniques to help organizations go through change. Some of us may have amazing tool kits, others of us may have sparse but functional set of core tools, and others of us might be trying to use umbrellas to hammer in nails. My walk away with better equipped to approach a transition to agile. I am going to be primarily focusing on how I think it’s essential to be able to adapt to the changing needs and priorities of your organization, how to achieve executive buy-in, and mechanisms to support scale agile across multiple teams. To help with this, I want to tell a story …
- 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.
- Source:Dean Leffingwell, Scaling Software Agility: Agile Portfolio Management, March 17, 2009, Slide 30