About this Publication
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.
As a result of our optimization for lean delivery we had an empowered team, improved quality, know velocity and capacity and an organization that is learning to deal with changes and project complexity. In the short term we achieved greater transparency of projects, increased collaboration and knowledge sharing across teams and the team now had a better understanding of the “what” and definition of done and a process to handle unknowns and respond to changes. Projects are now managed in programs of work and we now have a product and service delivery roadmap to ensure enterprise aims for product development are linked to implementation strategy and delivery.
1. INTRODUCTION
This paper outlines my experience of implementing a Lean start up strategy to develop capability and maturity that could be scaled across the organization. I was brought in as a consultant to run the service delivery team who were finding it hard to keep up with the rapid growth in demand for products and services. They knew they had to fix this quickly because the company’s push to move into new markets such as the USA, meant that they needed to have processes and methodologies that could be rapidly deployed and extensible to other markets.
I will outline how the capability uplift strategy was developed to address the key issues and challenges in our service delivery environment. My aim was to create a modern, robust and effective product development and delivery capability that could be scaled to the whole organization through a focus on optimizing for Lean delivery. Through the implementation of Scrum and Lean principles, we were able to improve delivery times, structure the organization for success and develop a resourcing model for team delivery that was scalable from project to programs of work across the organization.
2. Background
From a startup company 10 years ago, over the previous 3 years the organization had grown from 200 employees, largely in its head office base, to now over 1000 employees across 30 offices in Australia, New Zealand, Europe, and rapidly branching out into the USA market.
The company is a global, independently owned eHealth Software Company with proven experience in delivering interoperable, connected solutions for healthcare facilities, organizations and regions. Their products and solutions are implemented in more than 30 countries, used by hundreds of thousands of clinicians, and help to facilitate care for tens of millions of patients. The company has successfully been able to deliver innovative technologies in the primary care and hospital space which has seen improved integration between healthcare systems so that clinicians and allied health professionals can see end to end workflow for their patients and access and order imaging, pathology and medications records through the base platform.
As a health professional (Nursing) now working in ICT as a product manager and program manager for the past fifteen years, I have been drawn to the Health IT software development as you can see tangible benefits and outcomes of your work in the real savings to lives and costs through these innovations and can understand issues from the client and user perspective.
It was highlighted at the executive level that the Australian region was not performing well and that what had worked in the past, was no longer working and it needed to be fixed. We knew these were the issues in our region, however when I started to engage with other regions and the global program management office (PMO), it became clear that what we were experiencing in Australia as a more mature market for their products, could be a potential risk for other regions as they grew and matured from a small customer base to a larger network of clients and hospitals all over the country and the globe.
As a consultant, when I was brought in to manage the service delivery team, I found that we had very dedicated clients who had been loyal to the start-up company from the beginning as they were looking for innovative solutions to integrate their clinician and community systems. There had been some early success but the company was unable to keep pace with demand of existing clients as well as move into new regions/markets.
2.1 Key Issues and Challenges
We conducted client interviews to uncover the key issues and challenges. These included project overruns, decreasing project margin, increased non billable work, no roadmap for product development or service delivery, projects managed in isolation, poor quality, clinical risks and the fact that growth had meant lots of new starters and there was difficulty onboarding and up skilling new recruits. From our analysis of the client feedback we applied lean principles[1] to address five areas of improvement.
Process issues– Lack of agreed understanding on processes and governance led to misunderstandings in roles, responsibilities and accountability for aspects of delivery within the organization. This impacted our ability to provide clarity regarding product forecasts, costs, and to fully account for the risks involved in development, integration and delivery.
Wastes due to functional silos – Upstream processes operate independently of downstream delivery processes. This resulted in unrealistic expectations of clients of delivery milestones and estimate costs lower than actual costs and a backlog of projects that all seemed to be blocked by product issues.
Waste in resourcing models – Individuals and team resources were cherry-picked rather than on assessment of team mix necessary to assure successful delivery with minimal risk. As a result, project contribution margins had decreased. The resourcing model was “body shopping” out key team members who worked in isolation. Growth meant there were a lot of new starters but it was difficult to on-board resources quickly.
Quality issues – Milestone driven timeframes established upstream resulted in all available time being absorbed by development with little time for testing. The teams were working on a number of legacy projects that had been in progress for over two years, and this meant that the solution being implemented was no longer the supported version. Non-billable project work (re-work and technical debt) was 24% of hours.
Lack of “big picture” thinking – The current projects had grown organically and there had not been a program view applied to delivery of the Health Account. The team did not have a full understanding of interdependencies and where their projects fit into the larger picture for the client and organization. Their silo approaches meant that there was no collaboration or knowledge sharing across the organisation.
3. Capability Uplift for Service Delivery
The goals were to improve quality of the product in order to build trust and improve our capability to manage the value stream of products – from conception through to delivery and after-sales engagement with reduced risk and improved bottom-line. We also needed to improve the predictability of estimates on costs of product development, increase transparency of the value stream and product pipeline and maximise the revenue stream through a focus on quantifying value and removing waste over reduction in costs.
3.1.1 Approach
Prosci® ADKAR®[2], a change management framework, was used as the basis for increasing the maturity of the service delivery team through taking account of developing Scrum Masters, and the Team through five distinct stages. Recognition was given to individuals, project teams, and the entire program team, as separate entities to consider for movement through the five stages of change as each moved through the stages at a different rate. To support ADKAR, the Conscious Competence model[3] (Figure 1) was be used to reinforce that learning new skills also requires opportunities for practice in vivo to reinforce behavioral change.
Figure 1 – Zen Ex Machina’s application of the Conscious Competence model to ADKAR®
3.1.2 Maturity Uplift Objectives and Activities
The Capability Maturity Model Integration (CMMI®)[4] was used to assess the organization’s current capability for project delivery and the overall potential, therefore, to begin adoption of more improved service delivery for the program. Rating the organization against the CMMI showed an organization where processes were not consistently applied and were very much dependent on individual knowledge and capability rather than reflective of an organizational capability. Whilst the global PMO was in the process of defining organizational standards for project delivery, they are at the early stages of developing the PMO.
The organizational maturity baseline CMMI® rating was 1. The maturity uplift was as much a risk mitigation strategy to lessen the likelihood and impact of project failure as it was capability building.
3.1.3 Applied Lean Startup and Scrum
To address the process and quality issues our objectives were to apply Lean Startup as the strategic cornerstone of delivery and introduce Lean metrics to the (product) value stream to remove waste. The aims and objectives of the maturity uplift are outlined in Table 1.
Table 1- Aims and Objectives
We implemented Scrum and used Scrum of Scrums as a framework to assist the organization to scale its agile capability to a program and portfolio level. By adopting a program approach we had to juggle the competing project schedules and priorities and this is where the program layer of governance helped to rank order the product backlog based on organizational strategic initiatives rather than project based goals. This allowed the program of work to be considered and made dependencies and critical paths more visible to the decision makers. The team was able to focus on what was of most value to the client and the program layer was accountable for determining the release train order.
The team utilised Jira to capture the user stories and tasks and monitor progress throughout the sprint. Having the Jira board displayed on TV screens in the service delivery area was also a key success as it helped enable all team members and product owners to understand, velocity, burndown and what was still to be done and facilitated conversations around the board.
3.1.4 Governance
Our objectives included creating robust governance, risk and project/product management frameworks to support and optimise lean delivery while maximising ROI to the company and our customers. This also encompassed implementing a framework designed to assist the organisation to scale its agile capability across regions. We sought to understand the factors of the organisation beyond delivery that would need to be adapted in their processes to support optimisation for delivery.
Our governance model now looks at decision points at all levels (project, program and portfolio) and is helping to ensure that we have clear lines of escalation and using a RACI model (Responsible, Accountable, Collaborate, Inform) to ensure we effectively manage scope and requirement changes.
Figure 2 – Governance Model
3.1.5 Developed a Product and Service Delivery Roadmap
We started with a pilot project team with a program of work and created a roadmap for deployment of the strategy at a program level that if successful could be replicated and scaled throughout the enterprise. This was the first time the organization had had a global view of the pipeline of all products coming through and articulates an upgrade roadmap to move clients to the newer products.
The organization had previously had mixed success in their adoption of Agile. Product development team was using an Agile approach (Scrumban) whilst service delivery continued with a waterfall approach so there was a disconnect between product sprint cycles, sales team proposals for new work and service delivery waterfall based phases. The roadmap helped bridge that gap and allowed the service delivery and product teams to work together on client delivery rather than product development being isolated from implementation.
3.1.6 Restructure of Service Delivery
Optimizing for Lean delivery and alleviating our growing pains would require a restructure of resources. We needed to move away from functional silos and create multidisciplinary product based teams. We removed the functional reporting lines and created feature driven teams that focused on the user’s view and use of our products. The team members were at first overwhelmed by starting this process mid delivery of some projects.
We knew that we still needed knowledge based support for functions and therefore we created communities of practice and these knowledge leaders networked with their global counterparts to develop the company knowledge bases. We had just set up a global PMO so I worked with them to look at how this would work well for our technical, clinical, business analysis, project management and enterprise/solution architecture practices not just in Australia but how we could scale this model for other regions/countries.
In a health environment, clinical risks found in workflows and system configuration can have major health consequences for patients if they are not identified. The Scrum process meant that we had a clinical consultant embedded with each team and therefore systems were validated and checked by a clinical and a technical resource. One of the biggest wins we have had from adopting this approach was improved quality.
3.1.7 Cultural Change
The move to Scrum and enacting the restructure was very difficult as this was a cultural change across regions (USA, Australia/NZ, Europe and Asia) and needed the executive leadership team approval and support as the implications of what we were doing in Australia had impacts for the delivery model for the global organization. When I look back, it took 4 months to get this executive support to proceed, which at the time seemed like an eternity as I was fighting fires daily, however I acknowledge now that that may seem a relatively quick period of time. The key factor was that we had a key client who was very unhappy and was a global reference site.
This key client had been one of the company’s first client so had been with them from the beginning. I reached out to product development colleagues, in head office and found that many of the issues I was facing were similar in other countries it was just the size of the account (they had bought the suite of 15 products) that made these problems surface more quickly. We presented to the global executive leadership team who agreed that this was a problem they would soon face in other regions (particularly USA) and therefore we had CEO support to set up a group to look at this across the whole organisation rather than just in my region.
We had a lot of resistance from senior members in the team as the new structure took away their functional or role based power. Managers used their referent power within the team to actively block the process to reinforce their command and control project delivery paradigm and continued to tell the team how to do things and manage by schedule. They continued to focus on their own projects and lacked “big picture” recognition of how their behavior was negatively impacting the wider program. This was a problem we had to tackle head on and some tough discussions were had and some tough decisions were made.
3.1.8 Resourcing and Billable Utilization
The billable utilization paradox was a big challenge and we struggled with this in those early months as the company’s financial reporting for revenue is recognized based on invoices and time sheets indicating percentage of completion of projects against the budget and estimate to complete. We need to track team’s work for billing however most of our projects were fixed costs so the hours worked didn’t result in the customer paying more; it resulted in a lower billable rate for the project.
From a utilization point of view, Scrum’s structural and process changes meant that all team members were fully utilized on a program of work, however the billability on projects was lower due to project health issues with legacy projects taking longer than expected to deliver, lots of rework and product development issues.
What we did to resolve this billability paradox was to go back to basics and understand the purpose of reporting billable time. Billable time is captured so that payroll can pay wages and to invoice customers, it was never intended to be a process to manage a project schedule. We rationalized the matrix of project based coding to capture the high level things that were important. We felt it was important to capture what it actually takes for the team to deliver these projects, rather than focus on the individual’s billability as this resulted in negative behaviour with some individuals gaming the system to make their billability look better.
We looked at fixing the root causes of the delays rather than blaming the individuals for having low billable rates. Our communication of metrics changed from just focusing on billability to communication of sprint goals and delivery of these goals to show we were making progress. WIP limits helped to ensure the team was focused on the user stories of most value rather than cherry picking work based on whether there were some billable hours still attached to this work.
3.2 Limitations and Problems with Scaling Agile
Growing pains meant we also had to address methodology concerns as to how to scale what was successful for one project to the whole organization. One of our key problems was that the platform integration and business goals for our clients needed our Scrum of Scrums to be across projects and focused on a program level for each account. There were multiple PMs contributing to a common backlog and each wanting their user stories ranked higher in the backlog to meet their contractual obligations (milestones and payment schedules). This issue was compounded by the fact that we adopted this approach mid-way through the delivery of some projects and therefore were applying a new approach to a previous waterfall costed project. This retrofitting was not easy and some of the legacy projects struggled to adapt to the new approach (increased non billable hours in the short term).
There couldn’t be multiple Product Owners for the common backlog so we had to make one PM accountable and responsible for the backlog’s rank order and the other PMs contributed their stories. This was messy to start with and there was much confusion and in-fighting over scarce resources. Ultimately the order of projects and their user stories became a program discussion at the program board and the order would be based on account’s strategies and objectives. This structure was implemented at each account with the Services Director as Master Scrum Master with oversight over the body of work across the region for the organization.
We also had to contend with each account manager and/or project team, suggesting that the methodology couldn’t work for them because their situation was “unique” or “special”. Our experience in implementing this over the 12 month period suggested that each account had more in common than they had differences and in fact resulted in a recognition that the organization was previously pilling up technical debt because the sales and project teams weren’t collaborating and were “reinventing the wheel” rather than leveraging problem solving knowledge from other teams who had implemented similar work at other client sites.
3.3 Outcomes of the Delivery Uplift
Adopting Scrum helped to improve delivery capability and enhance product co-development partnerships and decreased the risk of failure to deliver the Program of work in a timely fashion. This was done through employing a number of methods and techniques, including working collaboratively with stakeholders and end-users, simplifying governance and increasing accountability and employing iterative methods, rather than a ‘big bang’ approach. Encouraging frequent inspection and adaption, teamwork and collaboration between the project’s members ensure that knowledge and skills were shared within and across teams as the process scaled from project delivery to program and portfolio level delivery.
The artefacts and learnings from the Australian pilot were adopted by the global PMO and we are now helping to roll out this framework to other regions. Once clients become a program of work, we had a scalable and proven method to ensure we continue to deliver a quality outcome.
An important part of our aim was to optimize for lean delivery. Scrum’s processes are explicitly engineered to identify and decrease waste and the organization was able to ensure that through the Prince2 governance framework the project was empowered to be responsive to changes in its environment so that delivery aligns with changing user, stakeholder and organizational needs. This ensured that all of the Program’s features delivered were useful and of high-value.
4. What We Learned
To increase the likelihood of success of the initiative it was critical to have the executive leadership team engaged to champion and encourage the adoption of Scrum and support the maturity uplift. There was resistance from some managers so having executive support visible to the teams was an important factor and this executive support needed to be maintained throughout the project rather than just being visible at the start of the project.
Implementing this approach midway through project delivery was not ideal and it may have been less problematic to commence the approach with new work rather than legacy projects. The legacy projects had a lot of product and version related issues so at times it felt like the process was hindering this as the teams were often caught up resolving design issues (technical debt) and there was limited time for planning and communication. However, applying the new approach to the most complex/complicated projects that were in need of recovery meant that we had confidence to then apply this approach to less complex problems as we had seen the process was working for us.
Our experience has shown that Scrum can be scaled at an account level from project to program level through use of good governance, Scrum of Scrum and program coordination of the Release train. The portfolio view of programs and projects is also critical to ensure that the right resources and knowledge (lessons learnt) are applied at the right time with collaboration across the organization from product development, account/sales and implementation teams to optimize for lean delivery and remove waste in the service delivery team. Ultimately our customers responded well as they could start to see business value being delivered and this process helped us to work in partnership with our customers on a transition plan to achieve a service delivery roadmap to meet their strategic goals for the next two years.
5. Acknowledgements
I would like to thank and acknowledge my Zen Ex Machina business partners who have worked with me to develop and refine our behavioral approach to Scrum coaching. Finally I would like to thank Michael Keeling for all his help in shepherding me through this process and for his valuable time and insights to help me develop this experience report.
REFERENCES
[1] Poppendieck, Mary and Tom Poppendeick. 2007. Implementing Lean Software Development: From Concept to Cash. Boston: Addison-Wesley
[2] Hiatt, Jeffrey. “ADKAR – How to implement successful change in our personal lives and professional careers”, http://www.prosci.com/adkar-model/overview-3/
[3] Burch, Noel. Gordon Training International, “The Conscious Competence Learning Model” http://www.gordontraining.com/free-workplace-articles/learning-a-new-skill-is-easier-said-than-done/
[4] CMMI Institute “Capability Maturity Model Integration “ http://whatis.cmmiinstitute.com/about-cmmi-institute