Embedded Files
Case Study 2: FTSE 100 Investment Company
Note: a worked example of an agile transformation cycle is also available (PDF).
Note: a worked example of an agile transformation cycle is also available (PDF).
Case Study 1
Case Study 1
The Company
The Company
UK private medical insurance provider
Net worth over £567,000,000
1.8 million customers
2700 UK employees
Around 250 UK hospitals in network
7 teams engaged in agile practice
PMO coached to provide agile assurance and oversight
The Challenges
The Challenges
This organization was trying to implement DSDM, an established agile delivery framework that balances strategic and operational concerns. 3 early adopter projects had been launched, each of which addressed a key domain or workstream in the organization's portfolio of healthcare insurance products.
Unfortunately the associated agile practices struggled to gain traction, despite competent and knowledgeable coaches having been hired. The agile adoption initiative was effectively an unlimited work-in-progress. More manageable changes - discretely achievable and clearly focused - had not been identified or prioritized. Coaching was largely reactive and lacked direction, and the progress of the transformation was difficult to assess empirically. In short the organization lacked the control surfaces that are needed for a measured and managed approach to agile change.
Team-level symptoms included unclear timeboxed goals, and planning was confused with requirements refinement. Product ownership was disengaged from the development process, since incremental delivery was neither understood nor valued. There was no agile governance and team composition was subject to frequent and unforeseen change. The relationship between Business and IT was poor.
The SolutionThe agile transformation pattern was implemented so that the change program could be controlled and made empirically assessable. A DSDM/Scrum "target operating model" was configured, and which expressed the organization's sponsored vision for its future agile way of working. A transformation team was then identified. It consisted of a sponsor, coaches, scrum masters, business change agents, and managers with a stake in organizational accountability and governance.
With guidance from the coaches, the transformation team identified more than eighty discrete changes that would be needed to implement the vision. These were articulated with clear acceptance criteria and prioritized on the transformation backlog. A physical task board was used to help manage the backlog and provide visibility over work in progress, and regular "standups" were held to a weekly transformation heartbeat. Throughput metrics were harvested. A date for the implementation of the operating model was then forecast and a transformation burndown was tracked. Impediments to the transformation were exposed and their resolution was facilitated.
Tangible Benefits Obtained
Tangible Benefits Obtained
Time-to-market was demonstrably reduced to 3 weeks.
The transformation was stabilised and business engagement was improved.
Agile teams were no longer "early adopters" and the IT department became "agile by default".
A further four teams were brought into the programme.
An agile governance capability was established with oversight of financial controls, compliance, and agile maturity measures.
The client could continue optimizing its agile operating model using an established and proven mechanism*.
* One of the items on the transformation backlog was to identify and train in-house coaches. As an externally validated measure of competence, they achieved relevant scrum.org accreditations (PSM, PSPO, PSD). The client was then in a position to further optimize the transformation using in-house coaching resources.
Tangible Benefits Obtained
FTSE 100 investment company
Net worth over £540,000,000
4.5 million customers
6500 employees
Responsible for the administration of £320bn in assets
2 teams engaged in agile practice
PMO coached to provide agile assurance and oversight
The Challenges
Unlike the first study, there was no high-level sponsorship for transformation at all in this case, even at an IT departmental level. Certain middle managers with long service at the company were becoming increasingly concerned that the organization would not survive unless product and service innovation was improved, and the validated learning cycle closed. Senior executives were not opposed to such change and broadly acknowledged the threat. However, there was political resistance as there had been a failed agile transformation some ten years beforehand. Senior executives preferred to delegate the responsibility for any improvement...and hence the risk of any further failures...to those middle managers.
Sponsorship for agile practice therefore came from:
Those few middle ranking executives who saw the risk, who had a transformational vision, and who had the budget to hire coaches
Certain technical team members and team leads, some with experience beyond the company, who had seen agile ways of working and who were willing to engage in pilot initiatives.
This represented a transformational challenge. Without clear executive sponsorship, only local optimizations can be expected which do not empirically and clearly evidence improved product value. Benefits are limited: a bit of improved transparency here, perhaps some better accountability there. This can be worth doing in itself, on the basis that it still amounts to progress of sorts, but it is non-transformational in nature. Clear organizational sponsorship is needed for real enterprise transformation. Organizational inertia must be overcome, and if that is to be achieved, senior executives must be able to transmit a sense of urgency for change.
The Solution
Although organizational sponsorship was weak, enough was in place to establish and coach two clear Scrum Teams for pensions and related services. They did not own the entire journey into service for their products, as there was a separate QA "team", but they owned enough of the respective value streams for the delivery process to be inspected, adapted, and rendered transparent. Support was also obtained, from the department's quality assurance function, to conduct regular agile health checks on cadence. Metrics concerning the delivery of increments for potential release could then be elicited and the process of transformation subjected to a degree of governance. Empirical evidence of the likely benefits of further agile change could also be gathered.
The agile transformation pattern was implemented so that this pilot initiative could be empirically controlled. A transformation rollout team was established consisting of a middle manager as the immediate sponsor. This sponsor had a vision for the improved delivery of value at the level of pensions and related products. The team also had Scrum Masters and a senior coach and a transformation backlog of around sixty discrete changes was elicited. These were held electronically in an Excel spreadsheet and a transformation heartbeat was observed during which progress was inspected and adapted, and the transformation backlog revised and reprioritized. Agile health checks were conducted on-cadence by the department's quality assurance function.
Case Study 2
The Company
The Company
Delivery of clear and potentially releasable increments, for pensions and related products, was time-boxed to 3 weeks
Greatly improved transparency was achieved regarding the burn-down of work and work remaining
Sponsorship from enterprise level was established by an agile governance function
Funding of projects and programmes of work was revised to support an agile delivery cadence
Case Study 3
The Company
The Company
UK multinational retailer on FTSE 100 index
Net worth over £2,500,000,000
26 million customers served per week
Over 80,000 employees
Around 800 UK stores, plus over 400 internationally
7 teams engaged in agile practice
The Challenges
The Challenges
This well-known high-street retailer envisioned a technical uplift of core data and food ordering services into a cloud-based Azure environment. These services were currently running in a mainframe setting, and the decommissioning of this old infrastructure represented a key part of the challenge. However the client did not simply want a “lift and shift” of the “As Is” capability to a new technology stack. Rather, they sought a new “To Be” system which challenged existing assumptions about value and how it ought to be delivered. In other words, they wanted to make the most of potential innovation opportunities unconstrained by legacy systems and thinking.
The client also had a pre-existing strategic directive to use agile ways-of-working wherever possible, and hence an agile coaching capability was brought in at the beginning. It should be noted however that the connection between agile practices and an improved ability to innovate was not clearly understood by client stakeholders, at least to start with. Also, there was no clear governance or assurance function, with no clear oversight of the transformational approach, or of quality concerns such as technical debt.
One requirement stipulated by the client was that there should be a pre-delivery "Discovery Phase”. During this phase, it was expected that a Product Backlog would be elicited at epic level, the essential agile ways-of-working laid out and socialised as far as possible, and an architectural baseline established which could be used by delivery teams. Development and delivery infrastructure, including continuous delivery and integration environments, and automated test harnesses, would also be instantiated. In effect, the Discovery Phase was an opportunity to put an agile transformation framework into place gradually, and with less sudden change to the client.
The SolutionSince a Discovery phase had been provided for, which is unusual in transformation initiatives, the agile transformation pattern could be assembled without haste. Its various components were thus introduced and explained to the client before they had to be put into practice.
A Sponsored Vision for the initiative was first elicited.
A transformation team was identified. It consisted of a sponsor, coaches, scrum masters, and a transformation backlog owner. Later, a PMO with a stake in organizational accountability and governance would also be brought in.
A transformation backlog was drafted with clear acceptance criteria for each change. Each of the items in this list was captured as a change. Hence the Transformation Framework was used, during Discovery, to instantiate itself. A physical task board was used to help manage workflow and provide visibility.
Regular “stand-ups” were held on a daily basis, effectively giving a 24 hour transformation heartbeat throughout Discovery.
Delivery teams were identified for future coaching, and a team cadence of 3 weeks was proposed
Inspect-and-Adapt opportunities, including Retrospectives, were held to close the feedback loop.
Agile Ways-of-Working were clarified and based on Scrum practices.
Tangible Benefits Obtained
Tangible Benefits Obtained
A clear vision for Agile Transformation was elicited.
Innovative capability was improved, which was one of the most important requirements of the client. The ability to get early feedback meant that changes during Discovery could be, and were, acted upon rapidly.
Basic agile hygienes, including Daily Scrums and Product Backlog Refinement, were introduced and normed before development work started.
Clear Agile Ways-Of-Working were articulated and socialised before development began. A configuration of "The Agile Buddy Guide" was provided to stakeholders and team members.
Teams, roles, and responsibilities were evolved in an emergent way to reflect the lessons learned during Discovery.
All 5 teams involved in mainframe transformation were coached in agile practice.
Two teams beyond the mainframe transformation program were brought into the agile change initiative and coached.
A DevOps capability with CI/CD and automated testing was put in place before development work began
A Product Backlog at epic level was made ready for development.
Page updated
Google Sites
Report abuse