Website Upgrade Incoming - we're working on a new look (and speed!) standby while we finalise the project

Going Agile

Many organizations try to catapult into agility.  Striving to instantaneously transform their traditional practices and culture.   Unfortunately, this strategy is usually painful and often fails.

The Scrum Guide states, “Scrum is easy to understand, but difficult to master.”  Basic training can be quickly and easily accomplished in just a few days.  However, being Agile is a mindset that requires time to develop and mature.

Agility is a journey and not a destination.  Similar to other pursuits where the goal is mastery, the more we progress and discover, the more we recognize there is so much more to learn.  This article describes some best practices for becoming Agile and guiding this transformational journey.

 

An Agile Approach to Agility

Agile incorporates incremental and iterative delivery approaches.  Value is delivered incrementally in defined cycles.  Based on feedback, we iterate to refine, adapt, and improve what has been provided.   

We can use the same approach for our Agile transformation.  A product roadmap communicates the long-term vision and serves as a guide.  A product backlog prioritizes which changes should be implemented based on their expected value to the organization.  New practices and ways of working can be delivered every few months.  The organization can iterate and adapt its methods based on observation and feedback.

It is impossible to predict how the introduction of new practices will change the environment.  Periodic demonstrations and retrospectives can be used to assess the state of the transformation, gain insight, and guide the next steps.  

We should use a market segmentation approach for deploying the transformation across the organization.  Business processes and their enabling applications should be profiled to understand the associated opportunities and constraints.  This knowledge can guide the customization process, helping to ensure that practices are aligned to the needs.

A/B testing concepts can be used to experiment with different approaches and practices.  By testing the response to and effectiveness of different practices, the organization can increase its rate of learning.  Agile methods are best when tailored, so understanding what works well in your organization’s various departments and groups may provide powerful insights.

 

Preparing the Environment

Agile represents a culture change for many organizations.  The transformation’s success will be influenced by the environment and its receptivity to change.  Experience demonstrates that cultures are very resilient and easily resist change—direct assaults are rarely effective.  We can reduce resistance by gradually introducing practices that are non-threatening and predispose people toward Agile.  

At one company with a deeply embedded traditional culture, we started acclimating the organization a year before the formal program launch.  We created a working group of people with Agile experience and those interested in learning more.  The group identified actions that could be taken to prepare the teams; including:

1.     Co-locating the team,

2.     Adopting daily stand-up meetings,

3.     Developing team norms,

4.     Experimenting with information radiators,

5.     Creating persistent development teams,

6.     Conducting periodic retrospectives and implementing changes to the execution process,

7.     Reducing time to release,

8.     Building cross-functional team that had end-to-end accountability for a release, and

9.     Creating opportunities for team members to develop personal relationships and friendships.

We set soft goals and asked that teams implement at least three accelerators within the first 6-months.  We tracked adoption rates to identify potential early adopters and change champions.  We also created an environment where teams were encouraged to experiment.  Encouraging experimentation and gathering feedback helped create a more effective program and open atmosphere.

 

Selecting an Agile Framework

There are several methodologies underneath the Agile umbrella.  While Scrum is the predominant framework, it should not be the default choice. Organizations and individual teams should evaluate their needs when selecting which methodologies and practices to follow.  

Scrum is a lightweight methodology that enables agility.  It has a prescribed set of roles, ceremonies, and artifacts that provide the scaffolding for the required cultural changes.  While Scrum practices are easy to adopt, some organizations resist the cultural change.  Outwardly they are following Scrum; but they are missing out on the real payback.  It is like driving a car with one flat tire.   

Scrum is most effective on projects where there are compelling needs for close and regular collaboration between stakeholders, the product owner, and the development team.  New product launches and applications with significant user-experience development are well suited for Scrum.  

Kanban is the leading flow-based Agile framework.  Kanban offers many advantages.  It can be easily implemented within existing organizational structures and be less disruptive than Scrum.  Kanban also does not require fixed delivery cycles which can be constraining.

Other practices, such as Test-Driven Development (TDD) and DevOps, can be layered into Scrum or Kanban and be matured over-time.  TDD is the practice whereby acceptance criteria are documented, and test cases are written before the code.  Unit testing and code integration is done early in the development process.  DevOps is a set of principles, practices, and technologies that enable the continuous delivery of value.  

 

Aligning to the Business Needs

A successful Agile transformation strategy is aligned to the business needs.  Agile should not be a one-size-fits-all across the enterprise.  Business processes and their associated applications have unique characteristics that should inform the strategy and practices.  

One way to align the strategy is to evaluate the required pace of change and the ability to absorb change.  For example, standard operational business processes such as accounting have a lower need and ability to absorb change.  On the other hand, sales and marketing functions may want to change product features more quickly and can easily absorb that change.  

Required Pace of Change

Products and processes that provide organizations with a competitive advantage or need to quickly adapt to changing circumstances will need to accommodate frequent and regular changes.  For example, the ability to quickly launch a new product may provide a company with a strategic advantage.  Similarly, the ability to rapidly respond to a security threat may be critical.

Some standard business practices and products may prefer slower or less frequent change cycles.  For example, human resource processes may only require changes on a quarterly or annual basis.  Benefits enrollment, performance appraisal, and similar methods may only need to be updated once a year.   

Ability to Absorb Change

Both the business and technology profiles of an application may constrain or enable the ability to absorb change.  It is easy to envision the technological drivers that facilitate the ability to rapidly absorb change.  Applications built on newer, micro-services and cloud-enabled architectures can be updated and modified more quickly than those on legacy platforms.

Business processes may also be constrained in their ability to change quickly.  For example, accounting processes usually operate on a monthly cycle.  Accounting groups do not want changes more often than that.  Enterprise resource management (ERM) applications may require extensive interface and regression testing cycles that are more easily accommodate a quarterly release cycle.

This analysis provides valuable information when developing the Agile strategy and helps focus and optimize the rollout of Agile practices:

  • Applications with the need for a high rate of change and the ability to absorb change may benefit the most from Agile and be good candidates for early adoption.
  • Applications, where there is neither the ability to move quickly nor the need, will have a lower payoff.
  • Applications, where there is a need to change quickly but the capability, does not exist may be areas where infrastructure investments are required as a first step.

An Agile transformation is a journey.  Attempts to make the transformation predictive without taking the opportunity to learn, adjust, and adapt will lead to sub-optimal outcomes. 

© 2019, Alan Zucker; Project Management Essentials, LLC

To learn more about our training and consulting services, or to subscribe to our Newsletter, visit our website: www.pmessentials.us.    

Related Project Management Essentials articles:

Image courtesy of: https://www.munich-business-school.de/insights/en/2016/knowing-doing-being/

Market Place

No results found... (try selecting a different content filter)