Agile has been "the new way" for many years, with many organizations deciding to go agile because of compelling evidence of shorter project lead times, more efficient teams, less stress, happier customers, and shorter time-to-market. What business wouldn't want that?
But what does "go agile" mean in your context, and what goals do you want to achieve by making this transformation? These are the questions that you should be able to answer before you even start.
Often decision-makers jump into new agile waters with their eyes closed, and without knowing how to maneuver. They may have read reports from experts and seen the trends and statistics, but that's not enough. Reports don't give you any information about how to carry out your agile transformation in practice.
When they have too little real-world knowledge about agile principles and practices, managers risk disrupting their organizations, and they may implement new team and project structures without fully understanding the implications. After a while they become surprised and frustrated to see that the improvements they were expecting did not emerge. They may even see some of their best people leave, because the new organization becomes too messy, or because staffers could not see how they would fit in.
Agile initiatives sometimes start bottom-up, from the team level. One or more teams want to work agile and just start. They may have permission to work with Scrum or Kanban, but are left to themselves to implement the method, assuming that they know enough and understand what the method or framework implies.
No matter if your approach is top-down or bottom-up, achieving organizational agility requires behavioral change at all levels in the organization. Agile is often considered a team thing. But if teams are not supported by managers that embrace the agile mindset and principles, and give up conventional silo thinking and command-and-control behaviors, you will only see minor improvements.
Only when your entire organization speaks the same language and plays by the same rules will you see full-scale improvements. Here's how to make that happen.
The 3 black holes to avoid
You usually hear all the good agile stories. Spotify is often mentioned, but most organizations are not comparable to Spotify. It's far more difficult to transform organizations that have worked in traditional ways for decades than startups with no old habits to break.
Reality paints a less positive picture. These three black holes can make agile improvement opportunities disappear, and make agile transformations fail or become only partly successful.
1. The 'how-difficult-can-it-be' trap
On the surface, agile methods look deceivingly simple. But when you dig a bit deeper, you will notice that there are many prerequisites to making agile processes work. Different roles with specific sets of responsibilities must be filled. These are quite different from those specified in conventional methods. If each role does not play its part, the agile chain will break.
Managers often believe that they can continue interacting with agile teams as they always did. But if managers do not understand how they fit into the new agile system, they risk becoming bottlenecks, inhibiting agility and efficiency.
Team members are required to take on more responsibility than most are used to. Agile is neither easy nor intuitive.
The solution: When you decide to go agile, plan for sufficient training for everyone involved—including managers. A few well-trained people cannot carry through an agile transformation. It requires understanding and active participation from everyone involved, at all levels.
2. Choosing the wrong method for the wrong reasons
Many development teams that decide to make the shift to agile choose Scrum because everybody else did. But to work as designed, Scrum requires new organizational structures and roles, stronger business involvement, new ways to handle demand management, and so on. Each of these aspects introduces significant change. In fact, it requires a cultural change.
Company culture can't be changed overnight. And since Scrum also implies a change in power structures, and much decision-making power is delegated, many mid-level managers won't support this change. Their resistance may run under the surface, but it will be there.
Development team members might also object to assuming new responsibilities. Some prefer to have somebody else lead them. Thus, Scrum will work well only if the organization is ready for it and the necessary prerequisites met.
If this is not the case, you would be better off choosing a less-intrusive agile method, such as Kanban, since it does not require changes to the organization. In other words, your choice of method should be context-based.
The solution: Analyze what the different agile methods truly require and which would be the best fit in your organizational context. Often a combination of methods works best.
Also analyze your organization's agile readiness and organizational maturity. Highly mature organizations are typically more ready for change, while change it typically more difficult in less mature organizations.
If you can articulate what's in it for you, you will find it easier to get your organization, including the business and mid-level managers, on board. If they can't see the advantages agile brings, why should they change?
3. No plans or metrics to measure your agile investments
You can't plan an agile transformation as you would a classic project. Nobody can predict how long it will take to make a cultural or mindset change, or to make new agile principles the natural way for everyone to work. Besides, continuous improvement never stops.
But you can plan what you want to achieve from your agile transformation. Is it shorter project lead times? Higher throughput? Happier customers? Increased sales? Happier employees? Less stress? Depending on your goals, you must steer your agile teams in a certain direction, and you must set your metrics accordingly.
If you don't plan and measure, you'll get random results and teams that are working in different directions. If you plan and measure, and you realize that you are not getting the benefits that you were looking for, you can adjust the direction.
The solution: Set concrete goals for your agile journey and make them transparent. Set up metrics that can show you whether you are reaching the goals or not. Everything can be measured.
Agile maturity assessments will also provide concrete, objective information about how your agile teams are doing. Repeating the assessment regularly will give you a clear picture of team progress. Measuring team performance creates transparency and makes invisible issues visible. It gives you a basis for focused actions.
Agility is not free of charge, and does not come automatically
There are several agile methods to choose among, but no matter which you choose, it is absolutely vital for your success that you understand the new method in sufficient detail. Otherwise, you will not be able to apply it efficiently to your context.
IT projects or development are by definition complex, and complexity does not magically disappear just because you decide to work agile. However, the agile principles of transparency, balance, structured demand management, and close collaboration between business and IT people will take away some of the complexity. You can now see what is going on, and proactivity becomes easier when you have agreed how collaboration, demand management, etc. should take place.
However, applying agile principles requires awareness, active decision making, agreement, determination, and perseverance. It's hard work, because old habits are hard to break. Agile principles will neither be natural nor desirable to everyone, and you will meet resistance.
Why? Because you are influencing power structures, you are asking people to change their ways of working, and people who were considered experts in the old ways are now at the same level as everybody else. So you are changing organizational hierarchies as well.
Agile is a shift that requires courage and willingness to change. Not everyone possesses that willingness, but the shift is still worth doing.
Do not underestimate the effort needed
Working agile is neither easy nor intuitive, and it's usually applied in complex contexts. So don't underestimate the effort and time it takes to get the full effect of your agile initiatives, don't be surprised if team productivity falls initially, and don't be impatient.
Given a bit of time, productivity will rise above the current state. Ultimately, the results will speak for themselves.
Keep learning
Take a deep dive into the state of quality with TechBeacon's Guide. Plus: Download the free World Quality Report 2022-23.
Put performance engineering into practice with these top 10 performance engineering techniques that work.
Find to tools you need with TechBeacon's Buyer's Guide for Selecting Software Test Automation Tools.
Discover best practices for reducing software defects with TechBeacon's Guide.
- Take your testing career to the next level. TechBeacon's Careers Topic Center provides expert advice to prepare you for your next move.
