If your organization is adopting agile delivery, you are going through an agile transformation. In this blog we’ll examine the 5 components of agile transformation that can’t be ignored. An organization often begins agile transformation because it is a small company that grew up without much official process and structure and things are too chaotic or it is a larger company looking to replace Waterfall style delivery. In this post, I will explain key components of agile transformation: process agility, technical agility, business agility, cultural agility, and change management agility.
The most obvious thing that needs to change during agile transformation is the process by which you develop products and services. This change often starts with learning Scrum because it is the most popular agile delivery framework (see the latest VersionOne State of Agile Report to learn more). Whatever agile delivery frameworks and process you use; your delivery organization will have to become proficient with them. You can go to classes, watch YouTube videos, go to conferences, or read about them. Agile delivery frameworks such as Scrum will be disruptive to your organization. For small companies with little structure, this new structure for delivering faster with less risk can feel overwhelming. For large companies with a lot of structure, policies
When organizations adopt the process side of agile delivery, teams begin delivering small pieces of functionality much faster. Organizations quickly find their existing tooling and development practices can’t keep up. Requirements can’t be gathered fast enough. Teams use branching strategies that cause constant code conflicts. Testing environments don’t accurately simulate production environments. Manual testing is too slow for agile delivery, but there isn’t an automated test suite robust enough to test new functionality quickly.
Requirements gathering tools designed for waterfall development are a common place people start improving. There are many digital tools that support agile delivery to choose from. However, getting started can be as simple as using whiteboards and sticky notes for teams that are co-located.
Coding and testing practices commonly change as well. Multi-week manual regression test cycles become an obvious bottleneck when aiming to delivery small batches quickly. Holding delivery teams accountable for quality and bringing the testing responsibility back to the people who built the systems usually leads to higher quality. Engineers will naturally start automating much of the testing if they’re truly responsible for quality. Building up more automated testing means that teams will get quick feedback when there are errors or flaws on each change that is made to the product. Finding these errors sooner makes them cheaper to fix because the developers who made it know where to find the problem. Automated unit testing, acceptance testing, and UI testing are some options for improving testing practices, but they must be learned. Time, budget, and effort must be provided so that delivery teams can make the technical improvements necessary to enable technical agility.
More advanced team will improve the deployment of products and services. With waterfall development, taking five days to ship a release didn’t matter much. When teams begin to deliver usable features in a week or two, waiting five days for a production release is just too long. Automating development with environments that better mimic production helps mitigate deployment risks. Who hasn’t stayed up late on a Sunday deploying a new version of software? Practices like continuous integration and continuous delivery require improving tooling and deployment practices. When done well, improving deployment allows delivery teams to release any time any day of the week and not break a sweat.
After your delivery team is cranking out winning features and amazing products faster than ever, the business side of your organization will need to re-learn how to drive. They’ll need to learn new ways of working with the delivery teams on defining smaller problems that can be solved faster. The business side will need to work regularly with delivery teams to give clarity, see working versions of the products and services to give honest feedback to ensure they are getting the products and services they need. Applying a “first things first” mentality is also important to speed development of high value features by spending less time on lower value things.
How many things change in your organization over the life of a large project? If you’re like many companies, the top of that list would include priorities, budget, customer needs, members of leadership, technology, competition… shall I go on? If so many things change so often, why would anyone sign off on a two-year project with fixed scope? Your business cannot continue to expect large project plans and fixed dates for fixed scope releases when so many things change quickly.
Getting your business to understand the value of agility isn’t hard, but it does take time. Your business will have to transform away from expecting predictable outcomes and toward growing emergent solutions. An effective way to start business agility transformation is to build awareness around the need for agility and the benefits of delivering small batches of value. They’ll need to speak the same language as the development teams to understand what role they play in the process and to maximize the overall effort to improve.
An often-overlooked aspect of agile transformation is the people. People develop products and people really do all of the changing during agile transformation. If you roll out an agile transformation like a waterfall style Microsoft Windows® 10 upgrade, expect a backlash. It may be direct and obvious, or it may be passive and quiet. Make no mistake, there will be resistance pushing against every change you try to make.
A common area of concern is around reporting structures because they can be a sign of status and or of importance in many organizations. The way teams work is usually reflective of your organizational structure. If you structure by silos, it makes sense for teams to work in silos. It seems efficient at first, but you lose adaptability and speed as a result.
When you move to team-based delivery but have a siloed organizational structure, you create a layer of friction and competing goals. The people who will resist changes to organizational structure are often middle management. If managers don’t see how they fit into the new version of the organization, they will resist and have the power to do so. Special care needs to be given to ensure all levels of management understand the ‘why’ behind the changes as well as how they can more effectively support teams in the new structure.
Since transparency is fundamental to agile delivery, it should be fundamental to any agile roll-out. Why is your organization making the change? What is a desired end-state for the organization? What will the roles of managers be in the new structure? If you can’t ease the anxieties of those affected, you’re asking for problems. Trust me, I’ve seen large public companies handle this quite well, with a little will and effort I’m sure any company can.
Offices and cubicles can also be seen as a status symbol or a sign of power. If you are encouraging collaboration through your agile transformation and push any kind of open floor plan on your teams before they have truly adopted a collaborative mindset, you will quickly find your team is unhappy with the new layout. When open floor plans are adopted before people are comfortable having open conversations and working closely together, people become reluctant to have conversations where others can easily over hear and collaboration will decrease.
The best floor-plans enable collaboration but also support working productively for people with varied preferences for how they focus best. People should have the option to work with their teams in team-focused floor plan but can easily find quiet places for concentration and recharging. Over time, people will begin to work more and more in team spaces as team collaboration increases.
Change Management Agility
Agile transformation is agile change management. Due to the wild number of variables with agile transformations, the only option you have for success is to start with a vision and strategy and begin implementing it through incremental changes to your organization while getting constant feedback about what is and is not working.
It’s common for organizations to follow a waterfall plan for agile transformations and push changes down from senior management. This type of plan might work with a company-wide PC upgrade. However, a ‘people upgrade’ like this will fall apart. Every person is different. Every company is different. Every reason for changing is different. Your current state is different. A common trap in agile transformations is for a manager to join an organization and begin to implement agile delivery exactly as they saw it done at their last organization. It never works (see One Shocking Thing Agile Coaches Get Wrong to learn why).
Successful agile transformations require agile change leadership, not just agile change management. Start with small changes and adapt your plan as you learn more. Think holistically about your organization. Get regular and timely feedback from the people at all levels of the organization. Use that feedback to adapt your plan and approach. True leadership means you have followership. Are people following because you have great ideas or because they are forced to? Are you setting and communicating goals and a vision people want to follow?
Agile transformation is critical for organizations struggling with
The most effective agile transformations are approached holistically. There is a focus on process agility, technical agility, business agility, cultural agility, and change management agility.
Like technology development, organizations are complex. Just because your last organization used agile delivery one way doesn’t mean it will work the same way at your new organization. Agile transformations must be approached with an empirical mindset. If you want to learn more please check out our comprehensive guide to Agile Transformation. We would be honored to help you on the journey to agility. Contact us to start the conversation to learn more.
Discover the top challenges with Agile Transformations
Want to avoid the most common challenges companies face during agile transformations? Enter your email below to hear the founder of Responsive Advisors, Robb Pieper, give a talk about how to solve these top challenges.