Today’s Goal: Share lessons learned from 5+ years practicing and leading Agile rollouts as a PMO Director that led to successfully and consistently delivering business value
What were the goals we were trying to achieve in rolling out agile?
Visibility into what your teams are working on, how much time is being spent on development vs support. What types of support requests are your teams spending time on? What patterns exist. Creating a culture of burning visibility will allow you toReal learning starts once you put your ideas in front of real usersWe are trying to build the best possible product for our customers. IMO, the best way to do this is complete transparency in what the team is working on, proactive risk management and regular communications. This is true whether you are currently practicing agile or not. So how do we create this burning visibility @pointroll? * Everything the teams are working on is visible in agile lifecycle management tools (Rally)* All development projects being requested follow a one-piece flow through the PMO who has a holistic view across the entire organization* We have multiple levels of planning that are made available (release, iteration, daily)* We work in 2-week time-boxes (sprints); We manage the work daily through a burndown chart; We create a release plan based on the features to be developed based on customer priorities.* At the end of the sprint, we review what worked, what didn’t work as a team and discuss team practices we should start, stop or continue. * This allows us be proactive during a project, not after and pivot easily if needed. * At the end of the sprint, we review our release plan. Did new information become available? Did we meet our commitments? Did priorities change? Working in 2-week time-boxes allows us to make quicker decisions and be more responsive to our clients (internal or external) needsUsing Rally, we give the business visibility into the state of development for any project being developed at Pointroll. What is the team working on? How much work is remaining?
if it is not measureable, it is just your opinion. Make data driven decisions. Agile teaches us to make empirical decisions based on real data. Here are some examples of what we measure… (a side note, all of the below data is looked at via individual sprint and sprint over sprint to look for pattern analysis): Team velocity – accepted work from sprint to sprint. Estimates to actuals (as a coaching tool for managers, not big brother watching how well someone estimated) Stories committed vs stories accepted Earned business value – revenue earned less development costs Unplanned work Support hours Cycle time Test case runExample – Not driving work to completionTeam members were working on lots of work, not driving to completionStarted measuring Work in progress resulting in:Reduce multi-taskingIncreased throughputBetter collaboration and teamwork
Value stream analysis – asked how do we speed up from client request to cash in the door – optimizing the wholeRemoved feature lists that were open to interpretation – created user stories and acceptance criteria in terms of business value, no technical jargonClearly outlined what Done meant to the featureClearly defined what is was notMade lots of assumptions – but that is the purpose of a user story – emphasis on conversation – conducted US reviews with clientsAt the end of each iteration, demonstrated fully functioning featuresAdapted release plans based on this empirical dataRemoved the concept of Change Requests Information flows into teams through the PMOWeekly story review, generate LOE for pricingSOWs for all client implementationsAll work products are expressed in the form of user stories and have definition of done, acceptance tests and limitsUser Stories & Acceptance Criteria are part of contracts
Just because you are doing agile development, does not mean you need to stop managing projects. The team still needs to manage risk, develop communication strategies, document (when appropriate).
The team practices are meant to define team norms, roles and expected behaviors
Agile is a framework for making decisions, it is not a process. A process is a repeatable event, the same everytimeAgile provides the basic framework for how teams manage work, requirements, planning and productivityFrameworks are meant to be adapted over timeHow one team operates within the framework may be different than others, encourage this self-organizationProvide your teams the authority to influence what happens within their team, release or product Create a plan to address issues and measure. Understand what questions you are trying to answer.
At times you will feel frustrated, uncomfortable and confused. Keep at it. Ask yourself, are these new problems that agile caused, or are these problems that always existed that agile is surfacing. Key Takeaways: Strong executive support along with training, coaching, and continuously inspecting and adapting are essential components to Agile success Optimize the whole, not just technologyData driven decisions – KPIs, team and quality metrics
Agile Lessons Learned From the Trenches
Lessons Learned from the Trenches @Pointroll<br />Presented by: Brendan Flynn<br />Agile Comes to Chicago<br />April 5, 2011<br />
Agile @ Pointroll<br />Practicing Agile since 2007<br />Leverage practices from Scrum, Lean, TDD<br />7 Teams, average 10-14 people p/team<br />Multiple product lines <br />All teams on consistent 2-week cadence<br />Agile utilized for product development, internal platform development and contracted client implementations<br />Regular production code releases every 2 weeks<br />Rally is used to manage Agile lifecycle<br />Confluence (wiki), JIRA (support), Team City (CI), are some of the other tools we use regularly to create visibility throughout<br />
Problems we had to address<br />Rapidly changing, incomplete or inadequate business &/or technical requirements<br />Organizational priorities were unclear to teams<br />Team had “do whatever it takes attitude” which resulted in over promising and under delivering, resulting in business frustration<br />Build quality into development framework; as opposed to testing for quality<br />Visibility / Resource allocations<br />No clear performance metrics<br />
What have we achieved?<br />True alignment of business and technology<br />Always working on highest organizational priorities <br />Consistently delivering business value every 2 weeks<br />More responsiveness to customer<br />Improved customer satisfaction<br />Improve quality/Reduced defects<br />Transparency into development lifecycle<br />
Top lessons learned rolling out agile<br />Burning visibility<br />Executive support is critical to success<br />Make data driven decisions<br />Make business decisions<br />Value of training<br />Optimize the whole (not just tech)<br />You still need to manage projects<br />Rigorously inspect and adapt<br />Agile is a framework, not a process<br />Agile is hard work<br />
Create burning visibility in everything you do<br />If it is not visible, you should not be working on it<br />Visibility into what your teams are working on<br />Visibility into how much work is remaining, in-progress, complete, for the sprint, release<br />Visibility into how much time is being spent on development vs. support, the types of support<br />Visibility into the number of defects, technical debt, failing test cases<br />Baseline and measure<br />Identify patterns and create a plan with your team for improvement<br />
Executive Support<br />When rolling out any new framework, there is a lot of noise and misconceptions in an organization<br />Create a bottom-up implementation with top-down executive support to help communicate and develop buy-in<br />Tactics we use for achieving executive support:<br />PMO holds weekly meetings with executive mgmt to review what teams are or plan to be working on against organizational priorities/project pipeline<br />Utilize metrics to show, not tell. Show costs, business value delivered, quality<br />At portfolio level, manage capacity vs. requested work showing resource variances<br />End of sprint summary – team, business & quality KPIs<br />
Make data driven decisions<br />“If it is not measureable, it is your opinion”<br />Support the story you are trying to tell with data<br />What do we measure? Team and quality metrics<br />How do we use it? To coach; Inform teams, stakeholders and executives<br />How often? Daily, sprint & pattern analysis sprint-to-sprint <br />
Example Team & Quality Metrics<br />Velocity<br />Estimates vs. Actuals<br />Unplanned work<br />Work in progress limits<br />Earned business value<br />5 Why’s root cause analysis<br />Development costs<br />Committed stories vs. accepted stories<br />Number of Deferred stories and why<br />Defects by functionality<br />Defects by discovery source, environment, priority<br />Test coverage<br />Test execution trends<br />
Make business decisions<br />Delivery teams @Pointroll provide a service<br />We try to never speak in absolutes… “There is no way we can get this release complete by this date”<br />Provide a holistic view of all projects across teams, people and provides options, impacts and risks<br />Allow business to make decisions about priority<br />Consistent team cadences allow easier priority decisions when planning 2-weeks vs. 2-months<br />
Value of training<br />Ensure that EVERYONE receives training… product, development teams, management<br />Cost of training worth investment to ensure everyone on level playing field<br />Creates understanding of the proper rhythm of an Agile team<br />TRAINING WAS THE EVENT WE CAN ALL POINT TO AS THE TURNING POINT IN OUR ADOPTION<br />
Optimize the whole<br />Conduct value stream analysis to determine where waste is occurring <br />How can you speed up the time it takes to go from concept to cash in the door<br />Look at how information flows into teams<br />Are there hand-offs? Lots of cycles back and forth? What assumptions are being made?<br />Make work ready; great teams spend 5-10% of current sprint preparing for the next sprint<br />
You still need to manage projects<br />Tried and true project management tactics are still needed in any agile adoption<br />What issues and concerns does the team have?<br />What risks exist? What are your mitigation strategies? <br />Create action plans, communication strategies and clear ownership <br />Leverage adaptive planning techniques, review release plans after each sprint and proactively adapt based on team velocity<br />
Rigorously inspect and adapt<br />We are not text book, we have leveraged practices from Scrum, Lean, TDD, PMBOK and tailored agile to our needs<br />We have evolved our practices over time – and will continue to do so<br />How we practice agile today is different than what we did 4 years ago or even 2 years ago<br />Establish team practices, regularly review as part of your teams retrospectives (start, stop, continue)<br />
Agile is hard work<br />Agile is hard work; Requires change at every level<br />Requires new techniques on how to approach work<br />Strong executive support along with training, coaching, and continuously inspecting and adapting at team and organizational level are essential components to Agile success<br />Optimize the whole, not just technology<br />Make data-driven decisions to tell your story <br />
I knew it was working when…<br />A developer said, “how did I ever build software before” [before using agile frameworks]<br />Our CMO said in a company meeting, “you just don’t hear noise of projects not being completed anymore”<br />Our CEO started using terms such as sprint, team’s velocity, release plan, burn down and other “agile” terms<br />Sales and Account Management began writing user stories and acceptance criteria in contracts<br />We began releasing client work in shorter, multiple releases, not a single huge release<br />I had visibility into the entire portfolio of projects and where resource gaps existed<br />
Contact me to continue the conversation…<br />Brendan Flynn<br />firstname.lastname@example.org<br />http://www.pointroll.com<br />