Agility over Agile

March 17, 2014

The article Agility over Agile, authors Alexandru Bolboaca and Adrian Bolboaca, is published in the Today Software Magazine, no 21.

Agility over Agile

Here’s a common situation nowadays: a large company learns about Agile and decides to adopt “agile processes”. The leadership team creates a transition plan that includes training, coaching, and consultancy. They monitor the advance by asking: how many teams are agile? Because when we’ll be over 80%, we’re done transitioning and we’re agile. Right?

Wrong. How agile the company doesn’t matter. The only thing that matters is its agilityhow fast can the company change when the context changes. Agility is a property of the organization, not of a team. Improving agility usually includes using agile and lean practices at a team level, but it’s not the full story.

 

Who needs increased agility?

If we look at it this way, then it’s obvious that not all companies need agility. Specifically, the company doesn’t need agility if all the following criteria apply:

  • it has a strong business model that brings great profit
  • it doesn’t want to expand in other markets or business models
  • its clients want a long release cycle (1-2 years).

Hospitals are an example of clients that don’t want to update their software more than twice a year. Accountants are also known to be conservative users who would prefer fewer updates rather than more. While agile practices can help structure the work in such a context, the business value they create will be limited. Certainly, not all hospitals or accountants fit this model, therefore any business needs to decide for itself.

If we turn this argument around, we end up with reasons for increasing a company’s agility:

  • when the market forces it to deploy improved quality faster
  • when the market has changed and the business needs to adapt
  • when the business needs to enter a new market
  • when the business wants to grow fast

Notice that we’re talking about increasing the agility. Any business has some agility, the problem is how to increase it to respond to external forces that push it to change.

Measuring agility. A utopia?

Can we measure the agility of a company? Measuring it directly is obviously highly risky and very expensive because we would need to simulate external forces on it and see how fast it changes.

We can, however, look at past events and discuss hypothetical situations. For example “what would you need to do to reduce the release cycle from one year to 6 months?”. If the answer is “that would be impossible” or “that would be extremely difficult” then agility is obviously not very high. Another example: “how fast could you release a completely new product from an idea you have today?”. If the answer is “one year” or “6 months”, you can definitely do better because 3 months is a usual benchmark with this regard.

At this time, there is no definite collection of questions that you can ask to measure your agility. The interesting questions are highly dependent on the context of the business and on its objectives. This is where the experience with various organizations of an agile coach comes useful.

Principles and Practices to Support Increased Agility

Once the business has decided what to improve, it’s time to define an experiment and focus on principles and practices.

Principles are the foundation of any transition, while practices define how one does certain things. For example, the agile principle the most efficient and effective method of conveying information to and within a development team is a face-to-face conversation leads to the practice of having collocated teams and to organizing meetings such as Daily Scrum, Planning or Retrospective where the whole team is physically present whenever possible. The principle of fast and often feedback translates to the practices of:

  • getting feedback from customers on features
  • developers writing unit tests so that they get fast feedback on the correctness of their changes
  • continuous integration to allow fast feedback on changes committed
  • fearless feedback between team members to improve the team collaboration.

Principles are the backbone of the transition: whenever the purpose of a practice is not well understood, the principles help decide whether to stop doing it or improve the way its done.

Some practices are very important for agility. For example, truly self-organized teams, that can make decisions inside boundaries set by managers, allow much faster response to change than centralized decision making. While their workings are often non-intuitive and seem chaotic, it is proven to work and it is part of a new brand of management that deals with complex systems, most commonly known as Management 3.0.

Occasionally practical reasons prevent teams from following a certain principle; that’s when the practices should be adapted to compensate. For example, teams that are forced to work in a distributed way should compensate by using a non-stop video and audio connection on a big screen so that it almost feels like collocation. Traveling between sites so that the team members know each other better also strengthens collaboration.

If the business is serious about increasing its agility, it won’t stop at organizational practices such as adopting Scrum for all the teams. Changes in other areas are typically required. Let”s look at some of them.

Release Cycle

Reducing the release cycle from one year to one month or less is not possible according to the best knowledge of the industry without changing the technical practices that are being used. Agility at this level requires flexible designs, automated tests, executable specifications, continuous integration and daily refactoring.

The previous article “Agility implies Craftsmanship” explained in more detail why. The article Building Changeability in Design – explores the role of software design when changeability is an important characteristic.

Feedback

The principle of fast feedback tends to permeate other departments as well, most notably HR. If the bi-yearly evaluation was the norm, agile-minded developers will demand faster feedback on their performance. Practices such as monthly one-on-one meetings with direct managers, monthly 360 degrees feedback or continuous feedback between team members can help with this new need.

Management 3.0

The role of management switches towards less direct control and more leadership. Some of the decisions typically made by managers are delegated to the self-organized teams while the manager becomes coach and support for the team members.

This doesn’t happen over night and requires a transition period; visualizing the areas of responsibility and the delegation levels for the teams helps both management and the teams understand their new roles and the road ahead. Once it does happen, it clears the minds and the time of the managers allowing them to focus more on strategy.

Business Agility

Probably the hardest change to accept is on the business side. Agility is measured at this level in terms of how fast the business can enter a new market or change its business model. The lean practices and principles play an important role for this kind of change. The first step is to identify the value stream of the new business model, meaning what people will pay for and what are the steps to create this value. If that’s unknown, it’s time to define some hypothesis and validate them through experiments, in the Lean Startup way. Once the value stream is clear, it’s time to:

  • visualize it
  • measure the cycle time: time from when the new item starts being developed until it”s done
  • measure the lead time: time from when the user asked for something until it”s paid
  • continuously improve the value stream by removing bottlenecks and waste (anything that doesn’t help the development of the valuable item).

Continuous Improvement

The continuous improvement part is the most difficult since it often requires tough business and management decisions. Coaching plays a very important role in maintaining the rhythm of improvements; they are often invisible from inside a team due to familiarity with the process.

Conclusion

Agile or Lean don’t matter by themselves. Agility matters. Agility is the property of a company defined as the speed with which it changes when it has to. Companies typically need to change when the market forces them, when they decide to enter a new market or when they want to grow fast.

To improve agility, the business objectives should first be clearly defined. The set of principles and practices from agile and lean are then adopted in the company while keeping in mind the business objectives. Team-level practices such as those defined by Scrum or XP are only one side of the agility improvement. Managers need to switch from a traditional role to a leadership role and strategic thinking. HR departments should adapt evaluation to allow early and often feedback, even through direct feedback between team members. Business leaders need to start looking at the business in terms of value streams, bottlenecks and removing waste and getting away from the traditional view of compartmentalized departments

Improved agility can be obtained without changing all the levels of organizations. Remember though that you can always do better.

Read more on http://issuu.com/todaysoftmag/docs/tsm_21_2014_en, page 19.

Categorised in: ,

Leave a Reply

Your email address will not be published. Required fields are marked *