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 is doesn"t matter. The only thing that matters is its agility: how 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 team level, but it"s not the full story.
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:
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 less 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:
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.
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.
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 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:
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 is often non-intuitive and seems 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.
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 - http://www.mozaicworks.com/blog/building-changeability-in-design/ - explores the role of software design when changeability is an important characteristic.
The principle of fast feedback tends to permeate other departments as well, most notably HR. If 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.
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.
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. First step is to identify the value stream of the new business model, meaning what will people 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 (see previous article about Lean Startup). Once the value stream is clear, it"s time to:
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.
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.