Four Agile Principles for Business Transformation

Published on
May 25, 2023

At Stride, we employ the four principles of Agile software development to help our clients achieve their objectives. As a refresher the four principles of agile software are: 

  • Clear communication between teammates
  • Iterative release of working software
  • Close attention to customer feedback
  • Adaptation in response to change 

Our methodology is empirical, relying on testing a hypothesis through experiments, observing results, and making adjustments as needed.

There is a bounty of information about Agile methodology, but to summarize in the context of what we do at Stride:

  • Clear communication means everyone understands the goal(s) of the project, what each person is responsible for delivering, and how to communicate with one another. This transparency supports alignment, which helps teams move in sync toward a defined outcome.
  • Iterative release of working software means that we strive to break down ideas into the smallest unit of software that we can release and learn from. It enables us to learn faster and evolve our thinking through experimentation. 
  • Close attention to feedback is the work of inspection, assessment, and validation. Whether building a new product or process, we collect user feedback and use it to drive product development.
  • Adaptation is both understanding how to change a product in response to feedback and doing so quickly and nimbly.

Whether the goal is to de-silo operations or implement CI/CD in the development process, it is these four principles that Striders apply to our transformation work. To help put this in context, below is an example abstracted from multiple real-world customer engagements:

What are the four principles used for operational change

A client brings Stride in because changes are taking too long to be deployed to a product already in production. The client expected several recent changes to take approximately one month but instead took four, and management believes the cause of the delay is that the product management team is taking too long to define the problem. 

Working with Stride, the team agrees to conduct an experiment: identify a small change, such as a user request for an additional drop-down on one of the screens, and take that change through an entire design and development cycle, observing the work and timing of each step along the way. The team makes this decision collectively and agrees on the metrics/measurements beforehand (transparency).

The first run-through reveals multiple bottlenecks. Not only is product management having difficulty connecting with users to better understand the value of the feature, but the tests are not written until after the code is complete and checked in (inspection). In response, test development is moved earlier and processes are changed to make it easier for the PM to validate user requirements. The entire process is then run again – and again, until the cycle is where the business needs it to be (adaptation).

By choosing a very small feature, iterations can be executed quickly, improving the process with changes that can be scaled up to include bigger features or functionality. Using an objective and shared method of measurement results removes ambiguity in the assessment process of whether something new is worth adopting. And establishing a team-defined process with a clear goal creates buy-in because the process is relevant and useful to those who would actually be working with the new processes (The same concept applies to new tools.)

The four principles used for organizational change

Bottlenecks might also exist because teams are not aligned with each other due to being organizationally siloed – in some more extreme cases, siloing has caused problems even when a member of one team is physically located one desk away from a member of a different team. Agile espouses a much tighter team collaboration model than traditional approaches. 

The past four decades of Agile practice have proven that software development is more successful using a cross-functional team, removing the barriers of misalignment and miscommunication that hinder effective transformation. In these cases, Stride uses the same approach to change management: establish team agreement and alignment, test and evaluate small changes, and adjust the experiment until the desired outcome is achieved.

A final note on Agile practices in digital transformation

Digital transformation is a popular concept, particularly in traditionally analog industries. While technology often plays a role in our “How,” the companies we work with already use technology to create their products. 

However, there might be areas where tasks are still completed manually and where technology can improve efficiency and value of the output. For example, I worked with one client where we added automation for a legal department, which was not as tech-savvy as the engineering team. 

Not only were the legal teams still using old-school approaches to documentation (e.g., printing, signing, and scanning contracts), but the evolution of automated solutions to handle official documentation had reached a point where we could meet the company’s needs without too much custom coding required.

Author
Subscribe to newsletter
By subscribing you agree to with our Privacy Policy.
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
Share

Four Agile Principles for Business Transformation

Four Agile Principles for Business Transformation
Down Arrow

At Stride, we employ the four principles of Agile software development to help our clients achieve their objectives. As a refresher the four principles of agile software are: 

  • Clear communication between teammates
  • Iterative release of working software
  • Close attention to customer feedback
  • Adaptation in response to change 

Our methodology is empirical, relying on testing a hypothesis through experiments, observing results, and making adjustments as needed.

There is a bounty of information about Agile methodology, but to summarize in the context of what we do at Stride:

  • Clear communication means everyone understands the goal(s) of the project, what each person is responsible for delivering, and how to communicate with one another. This transparency supports alignment, which helps teams move in sync toward a defined outcome.
  • Iterative release of working software means that we strive to break down ideas into the smallest unit of software that we can release and learn from. It enables us to learn faster and evolve our thinking through experimentation. 
  • Close attention to feedback is the work of inspection, assessment, and validation. Whether building a new product or process, we collect user feedback and use it to drive product development.
  • Adaptation is both understanding how to change a product in response to feedback and doing so quickly and nimbly.

Whether the goal is to de-silo operations or implement CI/CD in the development process, it is these four principles that Striders apply to our transformation work. To help put this in context, below is an example abstracted from multiple real-world customer engagements:

What are the four principles used for operational change

A client brings Stride in because changes are taking too long to be deployed to a product already in production. The client expected several recent changes to take approximately one month but instead took four, and management believes the cause of the delay is that the product management team is taking too long to define the problem. 

Working with Stride, the team agrees to conduct an experiment: identify a small change, such as a user request for an additional drop-down on one of the screens, and take that change through an entire design and development cycle, observing the work and timing of each step along the way. The team makes this decision collectively and agrees on the metrics/measurements beforehand (transparency).

The first run-through reveals multiple bottlenecks. Not only is product management having difficulty connecting with users to better understand the value of the feature, but the tests are not written until after the code is complete and checked in (inspection). In response, test development is moved earlier and processes are changed to make it easier for the PM to validate user requirements. The entire process is then run again – and again, until the cycle is where the business needs it to be (adaptation).

By choosing a very small feature, iterations can be executed quickly, improving the process with changes that can be scaled up to include bigger features or functionality. Using an objective and shared method of measurement results removes ambiguity in the assessment process of whether something new is worth adopting. And establishing a team-defined process with a clear goal creates buy-in because the process is relevant and useful to those who would actually be working with the new processes (The same concept applies to new tools.)

The four principles used for organizational change

Bottlenecks might also exist because teams are not aligned with each other due to being organizationally siloed – in some more extreme cases, siloing has caused problems even when a member of one team is physically located one desk away from a member of a different team. Agile espouses a much tighter team collaboration model than traditional approaches. 

The past four decades of Agile practice have proven that software development is more successful using a cross-functional team, removing the barriers of misalignment and miscommunication that hinder effective transformation. In these cases, Stride uses the same approach to change management: establish team agreement and alignment, test and evaluate small changes, and adjust the experiment until the desired outcome is achieved.

A final note on Agile practices in digital transformation

Digital transformation is a popular concept, particularly in traditionally analog industries. While technology often plays a role in our “How,” the companies we work with already use technology to create their products. 

However, there might be areas where tasks are still completed manually and where technology can improve efficiency and value of the output. For example, I worked with one client where we added automation for a legal department, which was not as tech-savvy as the engineering team. 

Not only were the legal teams still using old-school approaches to documentation (e.g., printing, signing, and scanning contracts), but the evolution of automated solutions to handle official documentation had reached a point where we could meet the company’s needs without too much custom coding required.

Michael Kellman

Michael Kellman

Partner

No items found.
green diamond