Building Blocks of an Agile Transformation: Develop & Execute a Framework of Small, Continuous Improvements

In our first blog entry about 'Planning your Journey' from the 'Building Blocks of an Agile Transformation' series, we introduced concepts and elaborated explanations key to Agile philosophy: its core values, principles overview, brief history and most importantly, how being Agile fits within a 'Continuous Improvement' mindset.

Agile, as much as Continuous Improvement, is more of a cultural niche of 'perspectives on how to tackle events', rather than a set of thoroughly defined processes.

That being said, there are many contributing elements an organization should consider agreeing upon prior to developing an Agile transformation roadmap: an Organizational Vision, Mission and high-level strategic goals must be carefully considered so all team members flock around them and push the organization's transformation towards its objectives.

Finally, the organization's current culture & organizational values have to be taken into account in order to understand what the current value-creation practices are and how they yield results in favor of preset goals.

Now, what about defining the high-level management strategy for your operations?

There are so many successful cases of business-proven alternatives out there that it can be tricky to decide on which processes and practices could better help an organization to stay on-track and thrive through its envisioned growth roadmap. For us at Sophilabs, we've already laid out (in the first post of this series) the case for Agility as a critical-to-success factor for fulfilling our vision and goals, supporting our cultural shift and fostering continuous improvement.

Let's do a brief overview of the most common management strategies to better support the case for our choice:

Choosing a Management Strategy: Lightweight Frameworks vs. Comprehensive Methodologies

Projects are in many ways the golden standard for delimiting and managing work, as well as its value-yield throughout the constant evolution of the business landscape. At any given point, professionals of virtually any industry have been acquainted to some degree with projects, if not fully groomed as project management professionals.

Because of this, the necessity of effective project management has been a must for a couple decades now; companies that want to innovate and revolutionize their markets need to effectively bridge the Business-Operations gap, optimizing resources and yielding better results each time. It's no surprise that a myriad of different methodologies, frameworks and methods rose throughout the years in support of the ever-evolving quest towards ideal management. There are two fundamental sides to effective project management:

1. The "Management Stack"

The "Management Stack" is a tool that can be used to decide whether to use a thoroughly-detailed methodology or a lightweight framework as management reference for a given project.

Methodologies in a nutshell are collections of specific principles, tools and practices that can successfully guide projects towards their defined goals. Their use-case benefits in projects are undeniable, especially to those types of projects or industries that have great product certainty and seldom deal with changes. The drawbacks, on the other hand, have to do with methodologies being very bulky and prescriptive, which means that not fully implementing it as prescribed could severely increase a project's uncertainty and risks.

Frameworks are somewhat leaner and more open constructs; they are structural references with fairly described high-level processes and enough room for practitioners to fit specific tools and practices into the tactical (lower-level) context as they deem valuable or fit into their current stack. Frameworks allow for great flexibility; they can borrow tools and techniques while aligning to a wide set of principles. A major drawback about frameworks may be that despite being lightweight, they can be hard to implement and manage effectively.

2. The "Value-creation approach": Predictive Vs. Adaptive

How we decide to operate our processes for value creation has a lot to do with the mindset behind implementing the Management Stack. In essence we're talking about "Predictive" or "Adaptive" operational approaches, which are usually (but not necessarily) tied up to the stack itself. Easily put, "Predictive" and "Adaptive" approaches differ from each other in the way in which they manage risk and uncertainty.

A "Predictive" approach deals with risk and uncertainty by anticipating needs, probable decisions and pretty much all possible scenarios (i.e. "comprehensive upfront planning") before contemplating value-creation activities and related management. This means there's a detailed project phase codependency: launch and execution depends on 100% fulfillment of Product Definition and Planning, while the latter depends on a thorough Product Conceptualization as the initiator. All of this means customers don't start perceiving value until a project is in its final stages. There's a set of industries that, because of the nature of their businesses, yield fantastic results and are very successful through being predictive.

An "Adaptive" approach on the other hand, deals with risk and uncertainty by reducing upfront planning to an "as-needed" minimum, increasing customer feedback cycles to maximize adaptability and ensure customers start perceiving incremental product value from the early development stages. This approach is especially ideal for industries that deal with highly innovative products with a high degree of abstract, conceptual work. Software development embodies those descriptions and, as we've stated before, is the precursor of adaptive approaches summarized in "Agile".

At Sophilabs we favor the use of an adaptive approach with lightweight frameworks such as Scrum for most new feature-creation and innovative products; and methods like Kanban for more time-constrained efforts like continuous product support.

We found that this core stack provides us with a complete but lean set of processes that complement nicely our Agility and continuous improvement agenda, while allowing us great flexibility to incorporate or dephase techniques, tools or practices as we need to better adapt, achieve our goals and cater to our customers' needs.

Scrum & Kanban: Adoption through an Agile Evolutionary Model

We've already asserted the case for Agile, for using lightweight frameworks and, more specifically, for using Scrum and Kanban; but now we're faced with a few questions:

• How do we foster the adoption of these Agile frameworks?
• How do we deal with resistance and ease cultural change?
• How do we determine the roadmap for such an endeavor?

After careful consideration and lots of pondering, we determined it was essential to define an Agility Evolutionary model to tackle these questions in a simple way.

Why an Agility Evolutionary Model

Models are mere representations of a system comprised of several dimensions, such as concepts & practices, in an ordained manner that facilitates the understanding and management of the subject the model in itself represents.

There's a lot of debate within the Agile world about the need for or apparent relevance of "Agile Models", with many Agile advocates stating they go against the very spirit of Agile. The general consensus in the Agile community seems to be that models in Agile could end up over-defining and constraining Agile's adaptiveness. However, many others advocate that some Agile frameworks are extensible in nature and could, and sometimes should, be complemented with concepts or practices that make them better fit organizational scenarios.

The Sophilabs Agility Evolutionary Model

Since we need to bridge the gap between how our operational frameworks and practices (Scrum, Kanban, Lean, XP & others), our organizational drivers (organizational vision, goals & culture) and our continuous improvement roadmap (tracing our adoption progress within a tangible scale) relate to one another; the idea of an Agility Evolutionary Model became attractive.

Fostering the Adoption of Agile

Promoting practices that revolutionize the accustomed old-ways can be very disruptive if it is not well-thought-out. We firmly believe in the solid backbone of enforcing good practices, groomed empirically to give successful results. Scrum and Kanban provide this foundation perfectly: they're lean, flexible, and very well-thought-out so teams can adopt them gradually yet continue refining their processes over time.

Easing Cultural Change

A customer-centric mindset, empiricism, self-criticism and continuous improvement through constant inspection and adaptation are central to both Scrum and Kanban, so any organization that abides by such tenets will not only drastically improve by adopting them, but will have a lot of fun while at it.

Laying out a Roadmap for Improvement

This might be the trickiest part yet, since Scrum and Kanban are not descriptive about process improvement other than referencing it as a natural outcome of process inspection and adaptation.

Our improvement roadmap approach is fairly straightforward: we believe that the sum of valuable applied practices makes up for the success of our endeavors. We also have stated that we're aiming for a significant cultural shift in which teams incrementally adopt these practices as part of their standard operational procedures core.

The question is: how do we achieve that? We pondered this question for a while with our teams and came to conclude that it's best if:

• The roadmap isn't excessively constrained. Pushing fixed goals with arbitrary deadlines could be counterproductive and put unnecessary pressure on teams. It's good to remember this endeavor isn't about crossing items off a list or incorporating practices just because, it's about understanding and accepting their underlying value building on top of their results. The latter also signifies the full adoption of new, improved behavior and cultural change.
• The roadmap conveys a clear picture of where we are and where we want to be. In other words, we should define how to measure and track progress with our Agility Evolutionary Model. The best way to do so is to define Agility milestones representative of different "Agility Levels" and for teams to track their "Agility Score", a mere representation of their current operational level. Successful teams greatly benefit from visually perceiving their progress through a simple & well-defined scale to guide their adoption efforts.

For the sake of simplicity, our Agility Evolutionary model is structured in four downstream tiers: 1) Dimensions, 2) Elements, 3) Practices and 4) Results.

Now, let's briefly explain them:

1. Dimensions represent top-level categories for objects in our model, in our case they are: "Roles", "Processes & Artifacts" and "Results".
2. Elements outline base components inherited from our preferred frameworks and methodologies, that fit logically within upper-tier Dimensions; e.g., Framework/Methodology Elements "Development Team" and "Agile Coach" are grouped within the "Roles" Dimension.
   This Tier also represents an important model constraint: given the base framework or methodology used by the team assessed, not all Elements measured in Scrum will be accounted for in Kanban and vice-versa.
3. Practices, in turn, refer to objects whose compliance is measurable and are identified as valuable for the overall process agility improvement. Practices are usually grouped below Elements.
4. Results, in the context of our model, are rather special since there are two types: Tier Results and Dimension Results. Let's define both:
   • Tier Results represent a practice's (non-)compliance. Teams (i.e. specific projects) use the Tier Results to assess whether they comply with a model-prescribed practice or not. Tier Results values are absolute: "Yes" or "No", since a practice is either being complied with or not.
   • Dimension Results represent the aggregated compliance value from 0 to 100, i.e., it's 'Agility Score", constrained by a defined organizational "Scope" and/or "Range" of Tiers. Pretty much in the same way a spreadsheet filter would allow us to refine valuable information, Dimension Results constraints allow for great scalability of the model:
     • Organizational Scope constraints mean we can choose to focus on the Agility Score for a specific team, a subset of teams or even the whole organization.
     • While Constraining a Range of Tiers, allows us to determine the Agility Score for specific Elements or Dimensions for the selected scope. E.g. Determine a project's Agility Score for the "Business Representative" Element, or perhaps for the "Processes & Artifacts" complete Dimension; instead of the Agility score for the whole project.

The table below represents a use-case example of the complete model for a project, broken down by its tiers:

Agility Level within the Agility Evolutionary Model

To help teams understand and track their progress through the Agile transformation journey, we also defined 5 incremental Maturity Milestones, that we actually prefer to call "Agility Levels". These levels are:

According to the assessed Agility Score for a given scope and range, we determine the current Agility Level in order to better understand how to channel efforts for continuous improvements in the future.

An Agility Score of 89 as in the previous example, represents an Agility Level of "5"; careful consideration of missing or deficient practices has to be taken when thinking in further progress.

Lastly, put your Agility Evolutionary Model to work

In order to achieve their full potential, teams and individuals must foster a self-critical culture that continuously pursues improvement.

Anyone from teams to whole organizations can use the Agility Evolutionary Model to baseline their current Agility Level, pinpoint their improvement areas and develop smart action plans around them then, in an iterative fashion, track and control their Agility Level evolution through time.

At Sophilabs we've been implementing this model successfully for about 6 months now and results speak for themselves:

• We have achieved Agility Level 4 within a few months after starting at a soft Level 3.
• Projects are currently operating effectively and continue to work for uncovering and fulfilling improvement opportunities.
• Individuals and Teams have become more process-aware and vigilant of compliance, since they've progressively developed an understanding of process value.
• Commitment to our Vision, Goals and Principles has remarkably grown; everyone is more aware and engaged to deliver quality in these areas.

In upcoming blog posts, we'll take a closer look at our results, actions plans that emerged out of them and our journey putting them into action.

References

• Road-mapping Your Way to Agile Fluency, Kelsey Van Haaster, 2016
• The CMMI Agile Adoption Model, Mukta Telang, 2015
• Measuring Agile Maturity in the Enterprise, Amjad Gani & Jim Starrett, 2017
• The Agile Fluency Model, Agile Fluency Project, 2014
• Agile Maturity Model – 3 Different Approaches, Udayan Banerjee, 2011