Growing pains scaling agile in service delivery LAST Conf 2014

of 26 /26
Growing Pains Scaling Agile to Achieve Greater Capability in Service Delivery By Mia Horrigan Managing Director Zen Ex Machina @miahorri

Embed Size (px)


The team I was working with had a “great problem” – more work than we could deliver. However this success brought mixed blessings as the strain of growing so quickly was starting to show. We had a backlog of work, process issues, resourcing and quality issues and a lot of knowledge residing with one or two of the original start-up team who were now single points of failure. The innovative, "can do" attitude of the start-up company was still there but we were having growing pains. We knew that what we were experiencing in our market (Australia) would eventually be seen in our USA market if we didn’t find a solution to our growing pains. We looked to Lean and Agile as a multidisciplinary approach to achieving an effective product strategy, development and delivery capability that could be scaled to the whole organization.

Transcript of Growing pains scaling agile in service delivery LAST Conf 2014

  • Growing Pains Scaling Agile to Achieve Greater Capability in Service Delivery By Mia Horrigan Managing Director Zen Ex Machina @miahorri
  • Growing Pains
  • Start Up Growing Pains More work than team could deliver Process, resourcing and quality issues Knowledge residing within a few individuals - Single points of failure 30 offices in AU, NZ, EU and rapidly expanding in USA Grown from 20 to 200 to 1000 within 7 years 48% of staff joined in last 12 months
  • Decay Start- Up How Business Grow Youth Growing Pains 2nd Youth Maturity Turnover Profit Moment of Truth: Cusp of the comfort zone Years in Business ToplineRevenue/Profit Healthy Business Curve The Slow Death Crash & Burn
  • Key Issues Project overruns Decreasing margin Lots of non-billable work being done No product or service delivery roadmap Projects managed in isolation Lots of new starters, difficult to on-board Poor quality Low level of maturity
  • Level 1 - Initial Processes unpredictable, poorly controlled and reactive Level 2 - Managed Processes characterised for projects and is often reactive Level 3 - Defined Processes characterised for the organisation and is proactive (projects tailor their processes from organisation's standards) Level 4 Quantitatively Managed Processes measured and controlled Level 5 Optimising Focus on process improvement Capability Maturity Model (CMMI) We were here
  • Capability Uplift Strategy Lean Start-up Aim Objective How Improve resource and capacity planning processes Scrum masters involved in assisting resource and capacity planning for the Sprints Increased accuracy of estimations of work effort Capability planning occurs Planning is established on a continuous cycle Engage Executive, Directors Product teams Team, PMO and Delivery team strategic planning SM Coaching Clinics with scenario-based training SM and POs mentoring one-on-one Buy-in from SMs Implement and enhance (Agile/Scrum) project delivery Sprint cycle goals for projects achieved Continuous planning embedded into Sprint cycles Reporting as part of the project cycle Achieve level 2 CMMI maturity rating within 3 months Support from CIO and Director for the Agile Framework Peer review by Business / Global PMO of key artifacts. Engagement of the business during planning and review stages of projects Up-skill and train Scrum Masters as owners of the process Ensure Scrum Masters are moving towards conscious competence Achieve CMMI level 3 maturity rating within 3- 6 months Engage Scrum Coach Wkly Coaching Clinics /Lean coffees Backlog of Coaching Clinic topics that represent value to SMs and align to the strategy and guiding principles Conduct Coaching Clinics and one-on-one sessions with Scrum Coach Implement and enhance governance processes Improved transparency Resources allocated appropriately across projects PRINCE2 aligned Successful project management recognized as more than just on time and on budget Implement RACI from projects to Program Continue backlog refinement meetings of Applications Development Forums and Project Board to rank projects Identify standards for tolerances and baseline
  • 5 Areas of Improvement (Lean Principles) Process issues Lack of governance, and understanding of processes, roles & responsibilities Waste due to functional silos Upstream operated independently of downstream Waste in resourcing model Cherry picking and body shopping Quality issues Milestone driven timeframes not realistic, no testing time, non billable rework 24% Lack of big picture thinking No program view of delivery, or interdependencies, limited collaboration
  • Approach
  • Unconsciously competent 3 months Consciously competent 2 months Conscious competence and agile adoption Consciously incompetent 1 month Aim: Learn what the rules are Aim: Learn how the rules apply Aim: Learn why the rules apply Outcome: Awareness of change required to produce repeatable outcomes Outcome: learned behaviours with repeatable outcomes Outcome: Empowered to change the rules and know the consequence You know that you dont know and it bothers you You know that you do know something but it takes effort You know how to do something and it is second nature You know how to do something and it is second nature
  • Team Issues Its wasnt easy, there was lots of resistance
  • WIIFM- Whats In It For Me ? Organisation Based on businesss Priorities High visibility on project progress Ensure effective use of resources Help with the change and adoption Product Roadmap and upgrade path articulated Service Delivery Happy client area Certainty around resources Collaboration and multidisciplinary approach Better quality through Build/Test process Ability to manage projects within a program framework
  • Scaling to Program Level Implemented Scrum and Scrum of Scrums as framework to assist organisation to scale its agile capability Program approach to manage competing schedules and priorities Program governance ranked order of product backlog and release train order Team left to focus on what was of value to client
  • Governance Decision points at all levels RACI to manage scope and requirements Portfolio Program Project
  • Restructure of Service Delivery
  • User vs. Product Focused Intelligent Integrations Smarter Hospitals (EMR) Rhapsody PCEHR SMD Integration Engine Products/Solution Clinical portal HIS Meds Mgmt Orders Clinical Documentation SMT ED Whiteboard Mobile IAM (Caradigm) Healthier Populations (EHR) BIS OHBI Healthcare Pathways Mobile Patient Portal Ereferrals EMPI (Nextgate) Orion product View Customer View Product View
  • Cultural Change Moving to Scrum was a cultural change Needed executive leadership approval and support took time Lot of resistance from senior members of team as new structure took away function role based power Managers blocked the processes PMs lacked big picture thinking negatively impacted program Had to make some tough decisions Had an unhappy client who was a global reference site
  • Made it Visual
  • Billable Utilisation Paradox Revenue based on timesheets and % complete against budget and estimate to complete But most projects were fixed costs so longer delivery eroded billable rate Scrum Utilisation >95% but project health issues meant billable utilisation was 60% Gaming of the system Changed to communicating sprint goals, progress and value delivered WIP limits helped to ensure team had focus on value
  • Limitations and Problems with Scaling Methodology concerns of scaling from project to portfolio and regions Started midway through fixed priced projects Confusion and in-fighting over scarce resource Multiple PMs contributing to common backlog but only one product owner (skewed)
  • One Product Backlog ProductBacklog a a c b d c Develop Product Backlog items to 20/20/60 levels of granularity Create Definition of Done Create sufficient specificity and clarity in Product Backlog to commence first Sprint Planning & Design ExecutingInitiating Develop Program Backlog (Epics) Develop Epics acceptance criteria Rank new Epics in Program Backlog Brief Product Owner Brief Teams Undertake estimations of Epics Agree deployment milestones a a c Sprint Backlog Sprint Planning 4-week Sprint Production Ready Increment Analysis Design Development Testing Daily Scrum Remove impediments Team-based work Capacity planning Capability planning Succession planning Create goal for items to be completed by the end of the Sprint Create tasks Release into Test Demo with the Client Lessons learned for the Team for next Sprint
  • Communicated Sprint Goals to Clients
  • Successfully Scaling the Program Scrum of Scrums One product owner with Program Director as master Scrum Master Pairing of knowledge resources with new starters Re-use of framework and program roadmap across regions and client sites Communities of Practice shared lessons learnt across regions at global PMO level
  • Outcomes Improved delivery capability Product co-development partnership with Sprints Decrease risk of failure to deliver on time Working collaboratively with stakeholders Robust governance and accountability Iterative rather than hero efforts Sharing skills and knowledge Scaled from project to program to portfolio Adopted learning to global PMO Lean delivery identified and decreased waste
  • Good Management Practice
  • Fin [email protected] @miahorri