There may be teams in the organization that may adopt some agile behaviors, but it can't reap the full benefits of agility if it remains in an isolated 'box' within a non-Agile organization.
Agile transformation helps an organization change its operating model and structure. By adopting the correct transformation roadmap the organization can reach value.
However, It's important to note that there are always legal systemic, and technological barriers that make transformation difficult. For example, it's really hard to do agile when the bottleneck is an old platform that runs on servers earning millions in revenue.
However, the challenges can be overcome if the habitual working behavior of individuals, and teams change.
The transformation can not be successful if executives don't understand the unit of value behavioral change brings, the time required, and budgeting needs.
Making a justifiable plan that illustrates how "being agile" will result in success.
With the plan in place, we have a set of hypotheses of changes for the delivery system in different time frames to understand How does that culture, and practices point to an improvement in the system?
This article aims to provide insight into how to develop a plan with valid change hypotheses that enhances agility and improves business outcomes.
How to think about transformation
Agile is a mindset represented by values, and principles, manifested through various practices. The mindset is to think differently than what happens in everyday work.
In many organizations, embracing a new mindset is not an option, instead, they prefer to put practices into place.
Unfortunately, practices do not necessarily create an effective and positive impact on the delivery system. For instance, it is common in many organizations for practices such as Scrum to fail.
The reason is that the underlying logic of the activities, and the values that should be acquired are not taken into consideration by executives, teams, and individuals.
In software production, most impediments are complex or complicated. Therefore, removing them is challenging. To overcome those impediments, it is necessary to investigate the underlying systems of delivery, the business architecture, the technology architecture of the organization, the creation and structure of teams, decision-making mechanisms, and the enabling entities inside an organization.
If you are not dedicated to removing them using proper solutions, the practices will unavoidably be defined as a process overlay on top of the organization.
To overcome these challenges, we should create the context within the enterprise for the agile transformation to happen.
When you bet on practices, you have to have a hypothesis for how they will impact the behaviors to create values. Therefore, all practices should be aligned around teams, business capabilities, and value streams and tied to the organization's strategic objectives.
If we can establish the proper organizational structures, equip them with the appropriate practices, and make at least a subset of the organization function effectively, we can encourage the development of the organization's agile culture.
Orchestrating agile transformation
To organize the transformation, it is mandatory to establish a leadership coalition in order to define the end-state vision, to elaborate the state of teams or networks of teams, to develop the transformation strategy, to identify what needs to be done, when, and for how long, and to determine if the architecture is defensible.
Furthermore, executives should be aware of the quality and quantity of the current delivery, what training and coaching is needed, what investments are necessary, what activities and outcomes are anticipated after 90 days.
Then, we need a framework that describes a chart of a course for the team, creates alignment with management, and secures organizational support for improvement.
During transformation, we need to conduct checkpoints to assess progress, retrospect and adjust. A tight-loose-tight (TLT) approach helps to learn how effectively the plan is doing as well as extract-transform-load (ETL) reviews which compare strategy and outcomes.
Finally, by taking feedback into account, our comprehension of the state of transformation will advance.
Basic prerequisites for adopting agile
There are three variables that are absolute fundamental preconditions for any agile framework to work.
Those are:
Product backlog
Team
Working tested software
As illustrated in Figure A below, in order for an organization to scale, it has to utilize governance, structure, metrics, and tools for the benefit of software product delivery.
Figure A: Fundamentals of doing Agile
1. Product Backlog
One of the first preconditions to look for is how a team should create a backlog in the level of expected specificity. For example, how product backlog items should:
Have a certain cinematic format?
Be independent, negotiable, valuable, estimable, small, testable (INVEST)?
Include cards, conversation, confirmation (CCC)?
Be driven from a use case?
Use specific ways of collaboration around them?
As organizations scale, the governance of product backlogs will be challenging to create economic trade-offs in the face of constraints. Hence, the teams must use different methods to make decisions, prioritize and determine business value.
2. Team
In the realm of agile, a group of people who were given tasks is not referred to as a team.
An agile team is a group of individuals with T-shaped skills who work together side by side and swarm around work.
Individuals must possess the necessary skills for the team and access to the entire potential technical work scope to deliver the items in the product backlog.
The issue with malformed teams is that they lose faith in their abilities when they are unable to reach the definition of "done".
The number of teams grows as we scale, thus we need the appropriate structure to deliver the notion of done. Therefore the following questions should be answered:
What does it entail to establish a cross-functional team or network of cross-functional teams that collaborate to work together on the entire stack? What is the best way to create orchestration?
What metric should we use to control that?
How do you want to follow work across it?
How are we going to make trade off decisions?
How should dependencies be managed?
3. Working, tested software
Adopting Agile is about regularly producing increments of valuable working tested software. When we talk about working tested software, our focus is not only on writing code, but also on making sure that we build the right thing, defect free, without introducing technical debts.
Moreover, metrics and tooling strategies are becoming more crucial as organizations grow to support learning of software products.
When adopting agile, the aforementioned basics must be enhanced. Therefore, in order to have enough time to develop useful features, product teams may sometimes need to cut back on producing lines of code.
Incremental and iterative transformation
The agile transformation's core unit values include adaptability, motivation, knowledge management, and enhancing business performance.
But “How can those be gradually improved across the board?”
The process of transformation has to be incremental and iterative.
The incremental transformation divides the organization into the smaller slices, each of which can be transformed to provide value. The selected slice must include teams from different organizational onion levels that affect business outcomes.
We keep moving forward with an incremental transformation to gradually eliminate dependencies and obstacles while making sure the entire organization is moving toward agility.
The iterative nature of transformation allows a team to gradually mature its teamwork and skills, enhance business processes, renew customer support technology, and strengthen end-user capabilities.
In iterative transformation we answer "How continuous improvement ought to be organized in order for a team to get from where it is right now to where it needs to be in the future?”
Therefore, it is necessary to have something like a roadmap and a release plan to ensure that executives are aware of the rationale for their financial commitment on transformation.
The rest of this article explains, how to create an iterative agile transformation plan.
Iterative transformation plan
James Shore and Diana Larsen's Agile Fluency model (AFM) assists organizations in targeting the zone where the benefits outweigh the costs involved.
In each zone, there are specific proficiencies that the team must be fluent in, as well as investments that must be made to generate the benefits.
Different organizations need various types of investment to be proficient in agile.
Investments are more than just funding for recruits or external training. It also means preparing the organization for reduced productivity or investing in relocation of certain people to enhance communication.
When investing in learning solutions, coaching, mentoring, training, and tooling, it is important to first establish some desired results and then do a gap analysis to determine how far the teams have to advance to reach the desired outcomes.
AFM includes the following zones :
Focusing on value: This zone focuses on business priorities; visibility into teams’ work; and ability to change direction. The main investments in this zone is on team structure; management; and work environment.
Delivering reliably: This zone is looking for low defects; high productivity; and technical longevity. The organization should primarily invest in development skills; engineering practices; integrating testing and operations.
Optimizing outcomes: This zone focuses on delivering high-value releases and better product decisions. The main investments are embedded product management; team ownership of budgets and plans.
Strengthening: This zone focuses on better organizational decisions and cross-team learning. The main investment will be the time and risk required to create novel organizational management strategies.
Moreover, each zone has various maturation levels:
Learning: The team is learning the skills.
Proficient: The team is able to exhibit the skills when it concentrates on them.
Fluent: The team exhibits the skills automatically, without conscious effort, as long as it has a coach as part of the team.
Independently fluent: The team exhibits the skills without needing a coach.
To move in zones, Alexey Krivitsky shows team autonomy, organizational structure, and product-centric alignment need to be changed (Figure B). Teams need to transform from being user-focused to product- and service-focused, as well as from working individually to working collaboratively.
Figure B: Teams transformation to reach different fluency
In order to make the transformation smooth, the first step is to identify the innovative and adaptive teams. Then, it is necessary to determine, where the teams stand in terms of fluency?
Agile Fluency Diagnostic (AFD) is a guided self-assessment tool to assess a team which helps you to learn the current state of a team. Moreover, AFD helps us to observe whether agile behavior happens and determine the distance between you and the zone that you target.
Dialogue with the team can establish the basis for improvement. The dialogue should aim to determine:
What proficiencies does the team have?
Which skills and practices are currently being used?
What values in the context of agile it generates?
What kind of problems have emerged in the retrospective?
Then, a change agent can help chart a course that will continuously improve the team by identifying the steps that need to be taken to get into the target fluency "zone".
Organizations can also use an Agile Fluency Radar (Figure C). It aids in illustrating how tools and practices are distributed in each zone to develop the anticipated proficiencies.
Figure C: Agile Fluency Practices Distribution
In focusing zone, a team needs to develop its teamwork, planning, ownership, accountability, and improvement skills to impress executives by showing them the progress of work, reducing risk of building wrong thing, correctly prioritizing business concerns, increasing values, incremental progress on business volume, reducing misunderstandings and hand-off delays among teams or team members.
It is possible to assess the success of being in this zone by monitoring metrics, such as cycle time, Work In Progress (WIP), amount of features blocked, etc.
For a team that targets the delivery zone, minimizing risk and cost, collaboration, development, design, DevOps, quality skills are needed, along with the earlier systemic flaws discovery. In addition, release forecasts need to be provided, more time should be spent on improvements to make the future changes cheaper and faster, align with market cadence, and improve retention and productivity.
The effectiveness of this zone can be evaluated using metrics like deployment frequency, lead time for changes, mean time to recover, change failure rate, etc.
In the optimizing zone, the team should have autonomy, and discovery skills to improve the position of the product in the market, cancel low-value business concerns, meet business objectives, create business opportunities, promote optimal cost/value decisions, eliminate handoffs and speed decision-making. An example of metrics which measure change impacts is pirate metrics.
The team's strengths in each zone should be identified to build on them and make sure they are not lost over time. Moreover, the improvement area that the team can handle itself needs to be listed. Also, the investment areas that the team can work on should be provided.
We need to provide the reports for the executives and teams transformation. The executive report examines systemic changes and investments, whereas the team report is about teams strengths, and improvement areas.
The teams that are fluent apply all zone-related skills without conscious effort, but choosing all skills takes the most effort and investment. It is therefore necessary to have a dialogue with management to answer the following questions:
What is the targeted zone for a team?
Which proficiencies should the team earn?
What investments a team needs to emerge proficiencies?
What benefits will be gained after transformation?
What tools and practices are needed by the team? What must be learned? What must be practiced?
What policies or practices are not aligned with agile and should be changed?
By the end of these meetings, executives, teams, and change agents will know where they are, where they are headed, what benefits they will gain from transforming, and what skills, practices, and investments they will make.
The key variables that share mindset in the targeted fluency zone are condensed in the Agile Fluency Canvas (AFC). In Figure D, you can see an example of how an AFC canvas can be used to identify hypotheses that may help a team move toward agility and reach the Focusing Zone expectations.
Figure D: Agile Fluency Canvas
Conclusion
In this article, we discussed that when adopting agile, one needs to pay attention to three things: the basics of transformation, the change in organizational behavior, and the process of implementing transformation.
There is an iterative and incremental nature to the transformation for implementing agile across the entire organization and making teams evolve to do their jobs in the new environment.
Transformation should assist product teams to achieve maturity by improving the quality of backlogs, team structures, and tested working software to develop outcomes to be responsive to changing market cycles.
For agile transformation to succeed, we need an operational and organizational model that evolves. Therefore, it is important to follow a transformation model that enables us to transform incrementally and iteratively.
There is an AFM model that supports iterative transformation to determine the set of proficiencies that teams should be fluent in to adopt Agile behavior as well as understand the potential benefits and investments needed.
The change agents can utilize the tools such as Agile Fluency Diagnostic, Radar, and Canvas to develop their transformation plan.
Figure E: Transformation roadmap example
By doing so, you get a better understanding of the organization's strengths and weaknesses. Moreover, it helps change agents to create and visualize the evolution of the team's needs and behaviors over time through the following transformation roadmap example (Figure E). At the end, the iterative improvement can be achieved in the plan–do–check–adjust (PDCA) cycle process.
Bibliography
James Shore, Diana Larsen The Agile Fluency Model．[Online][Cited: 06 03 2018．]https://martinfowler.com/articles/agileFluency.html
Wolf-Gideon Bleek What is an Agile Fluency Diagnostic? [Online][Cited: 08 06 2020．]https://www.linkedin.com/pulse/what-agile-fluency-diagnostic-wolf-gideon-bleek/
Alexey Krivitsky Map Your Route to Mastering Agile Fluency [Online][Cited: 06 11 2022．]https://www.orgtopologies.com/post/map-your-route-to-agile-fluency
Asad Safari How to use the Agile Fluency Model [Online][Cited: 02 05 2020．]http://factfulagility.com/2020/05/how-to-use-the-agile-fluency-model/
Behzad Nazarbakhsh
Read also
Experience the new way of doing product management
