Impediments to Agile Adoption

We help our customers implement software using Agile methods and a DevOps approach. These notes have been growing as we’ve worked with more and more customers. I expect to have more in the future as well, but these several items are recurring issues I see time and time again. Hopefully, even if you are not one of our customers, you’ll glean some insight that will help you with your own organization’s adoption.
Culture eats process for lunch
There are many tools out there that can help you adopt DevOps processes. These tools all center around common concepts that may be very foreign to your organization, and in some cases may be hard to accept. It is important to level-set and acclimate your organization to new concepts and vocabulary, and where needed differentiate new meanings of common words.
For example, a “unit test” in the DevOps world is a piece of software code that is written by a developer to test another piece of software code. In the IT organizations of some large companies, the term “unit test” might mean that a group of developers manually review the functionality of a service, then type up a MS Word document or author an email to confirm the activity has completed.
Another example might be the concept of requirements management. In an Agile or DevOps sense, requirements management is a constant activity, allowing, accepting, and encouraging change throughout the development lifecycle. A typical waterfall approach mandates big up front design, that spends hundreds of man hours on abstract design before any code is written.
Addressing these common ideas early, means higher adoption rate of the tools that you will use to implement a DevOps approach.
Remember, culture will eat process for lunch any day of the week.
Train your Dragons
Would you fly in an aircraft with an untrained pilot? Would you let your teenager drive a car without training? Would you send your kids to a day camp with untrained counselors? No? Then why would you expect your teams to adopt a very complex tool without training? Training is more than just a 1 week heads down session. You should have a full education plan. This means not just training the early adopters, but handling continuing education for existing employees, and on-ramp eduction for new hires. Your training plan can be supplemented by videos, lunch-and-learns, knowledge centers (aka Wiki, Sharepoint, Confluence etc), as well as in-house mentoring. If you think you can train and forget, you’re sadly mistaken. This applies to nearly any new technology. In other industries, such as Real Estate and Nursing, continuing eduction is a requirement for continued professional licensing. Think about that!
Don’t keep the C-suite in the dark, or you’ll be the compost
Speaking of training, you should ensure your executive team understands the benefits of moving towards a DevOps approach. Understand their needs and motivations, and how DevOps can address those needs. You will have better buy in if the executive committee not only mandates the change, but actively participates in it. This means they need to learn the lingo, and be the vanguard in changing the culture of the organization.
Don’t think that its not all or nothing
As they say, you can’t boil the ocean all at once. While it does help to address things in a certain order, you don’t have to address it all at the same time. For example, you can begin by addressing the culture with new requirements management tactics (User Story driven requirements vs. complex use cases), and automated unit testing by the development team. Don’t expect it all to start at once. Certain activities can be independent of others. Some need to come at the tail end (such as updating reporting). Find the area that will provide the most ROI, adopt it, then move on to the next concept that is best facilitated by the first. If you begin with automated deployment you may run into the issue of having to manage source code changes in flight that the release engineer has to cherry pick out to get a good build. In those situations, one must address the task and requirements management using timeboxing techniques (which is one of the harder concepts to grasp). Find what works best based on the culture of your organization. We recommend weighting your initiatives and features using empirical approaches such as Weighted Shortest Job First (WSJF). This helps the team focus their energies on the current challenges that will bring the most ROI.
Focus too much on tools, and not enough on culture and process
The very first stanza of the Agile Manifesto is “Individuals and interactions over processes and tools”. You must put the focus on individuals and their interactions if you want to affect the culture. Throwing them new, expensive tools, and assuming they will grasp the underlying concepts is a recipe for failure. You’re better off using whiteboards with swim lanes (Kanban), paper index cards for User Stories, and sticky notes (for placement in the Kanban). I’ve seen shops that use the simple techniques be more successful than than shops with matching tools. The reason? It puts the focus on the change in interactions and culture, rather than products and tools. Don’t get me wrong: tools can vastly improve the productivity. Those same shops are the ones that I implemented some IBM tools and open source techniques, and it was wildly successful. That success happened because the teams already understood the fundamentals, and they were subsequently much more productive afterwards.
Failure to account for additions to architectural runway.
The bigger the plane the more runway it needs to take off and land. Your architectural runway means your programming frameworks, development languages, servers, DR systems, and API’s. Think of it like this: how much architectural runway do you have if you have a Windows NT 4.0 server farm and running Java 1.3? Think you can do some fancy REST API’s with that? Right. You need to constantly account for these changes in each iteration. These should not be though of as a “once in a while, if we have budget issue”. Your runway is cryptically to success, and you should incrementally, and continually update and extend it.
Failure to keep stakeholders engaged throughout the process.
This is part of changing the culture.  Your stakeholders should be able to see the value as its being delivered with each incremental release. That requires constant collaboration and feedback. This helps keep the development team abreast of changes and needs from the customer. Think of it like this: does a businesses’ needs stay constant throughout the year? Of course not! It changes as the marketplace changes, and as your competitors adapt. The faster you can adapt, the better equipped you are to maintain or gain market share. Thus don’t think of your IT as a separate silo from your marketing department. The marketing team is the eyes and ears of the organization. Just like you would not fly an airplane with blinders and headphones, you should constantly get feedback from your customers so you can adapt and adjust, and so they can provide you with that much needed feedback!

Comments are closed.