When a company embraces the agile path, the first question is: “Where do I want to go?” and not “What is the right framework to do agile?” A disciplined approach to change can help you to choose from possible practices such as a “design pattern book” for agile transformation, and to identify when a practice is promising and when the current context is not the most favorable for it.
Felice Pescatore, software engineer and agile business coach, spoke about applying a disciplined approach to change at Agile Business Day 2020.
We know from different studies that an agile framework can be a good starting point, but can become too prescriptive and pull down the enthusiasm of the people involved in the transformation journey, because it is too far from reality, Pescatore said. This effect is often called the “framework prison,” and the challenge is to adapt the power and the suggestions of the framework to its own context without following a dogmatic approach.
Pescatore combined the PMI Disciplined Agile toolkit and the Lean Change Management philosophy for an agile transformation at a company in the medical sector base in Italy. Change actions were done as experiments where the results were evaluated to decide whether to continue or to try something else.
Pescatore suggested to think of a disciplined approach to change like an anthill:
Every ant moves in a coordinated way to collectively help in the big challenge. In our case, the “ant” is the vector for a “small change” that we selected to help the company make a small improvement, verify it directly in daily work, testing the response of the people impacted and using actionable metrics to evaluate the results. If these results live up to expectations, we can continue to refine the adoption, if not, this isn’t a problem: we can quickly identify a different tactic to adopt, and take it to the ant!
PMI Disciplined Agile suggests to develop a mindset based on three pillars: principles, guideline and promises. Pescatore explained that the principles provide a philosophical foundation for business agility, the promises are agreements that we make with our fellow teammates, our stakeholders, and other people within our organization whom we interact with, and the guidelines help us to be more effective in our way of working (WoW) and in improving our WoW over time. Simple to describe… hard to implement…, Pescatore said.
InfoQ interviewed Felice Pescatore about using agile frameworks in agile transformations.
InfoQ: What challenges do you see when organizations want to use agile frameworks?
Felice Pescatore: There is not a single “best framework,” but there can be several helpful frameworks to support a company in its own transformation challenges. In this scenario, when a company is trying to choose a framework, the first attention point is its actual context and the capacity to compare the use of the candidate frameworks in a similar scenario. Typically, this is the main duty of a transformation agent, or an agile business coach, who paints the starting point on a canvas and identifies the best fitting model related to the picture.
InfoQ: At Agile Business Day you presented a transformation experience a company in the medical sector went through. Can you describe why they decided to go on this transformation and how it took off?
Pescatore: The company had two main goals:
- To review its internal communication and collaboration approach to better support doctors and nurses in their work
- To create a shared strategic approach to better focus on the business goals and create the right alignment between marketing, sales and the technical staff. This was very relevant because the focus of last year’s was too much related to a day-by-day reaction to external needs.
We started the activity the first day by defining the “transformation lighthouse”, which is helpful in selecting a coherent set of experiments to develop the new customer-centric vision, actively supporting the innovation requested by the specific market.
InfoQ: How did the company develop its Way of Working (WoW) in an agile manner?
Pescatore: We applied what I call “The Disciplined Approach to Change”: the combination between the PMI Disciplined Agile toolkit and the Lean Change Management philosophy. Concretely, we considered every new action an experiment; for example, we can think about the problem of sharing the know-how about the coding of a module. In this case, we identify a way to do that, for example pair-programming, define a time for the experiment, for example one sprint, and define the related metrics, for example every piece of code must be known at least by two people. At the end of the sprint we evaluate the results, and if the metrics are satisfactory we continue to invest in the practice and extend it to other teams; otherwise we try a different one with the same goals.
This tactical approach was supported by strategic tools, like the Strategic Change Canvas and the DA Process Goals (you can find more info on this on leanchange.org and pmi.org), and reinforced by specific review events. We created the “change frame” (about three iterations) at the end of which we reviewed all the results to be sure that the selected practices were coherent and confirmed the supposed validity.
InfoQ: How did they apply agile to revise their quality procedures while ensuring compliance?
Pescatore: This was a hard point because the company is governed by a lot of external regulation and law related to its core business. We dealt with it in a pragmatic way and used the common iterative and an incremental approach; starting from the current procedure, we identified what could be, with a minimum upgrade, and aligned in a fast way with the new selected agile lifecycle (one similar to Scrum, known as “Agile lifecycle” in PMI DA). For example, there was a testing strategy structured in levels (functional, integration, and so on) and we decided to keep this high-level description, but we refined and investigated the way in which the testing was made.
On the other side, we completely recreated the procedures that were not coherent with the new agile approach, formalizing them after the experiment and after stabilizing the new practices. For example, initially the development lifecycle was described like a classic waterfall approach; after we experimented with the DA Agile lifecycle and we decided that it was the right one, we changed the related document to reflect this decision.
At the end of every change cycle we worked to create a coherent documentation in order to be confident that we were supporting the audit actions the right way, and to be sure that we were totally aligned with the law and regulation. To be clear: we reduced the amount of the documentations, and partially automated the filling of the template extracting; for example, many documents are filled automatically from the product backlog items through a custom supporting tool, but, clearly, it was not possible to remove it completely!
InfoQ: What’s your advice to organizations that want to start an agile transformation or are on an agile journey?
Pescatore: Oh… it’s very simple but powerful: you must always remember that agile is not your goal! You must develop your agility to create an antifragile company where your people can push the culture on and be continually engaged in new challenging goals.
Culture is hard to change and only the company people can do this: by dedicating time and resources for it, creating a psychologically safe environment which allows them to share the effects of their experiment, reflect on results, and consider failure a natural way of reducing the options for changing, rather than a reason to blame someone.