As a consultant, I get to travel around the country and see many companies in action. Almost every company I visit is practicing what they call an agile methodology, with varying degrees of success. The companies that are good at agile tend to have happy customers and high morale. Unfortunately, many companies I visit are still struggling with delivery. There are some common patterns that emerge when agile fails. Here is a short list.
The “IT Only” pattern
In many cases, only the IT department is an active participant in the agile methodology. Sure, there is a “product manager” involved, but not with the full support of the business. This pattern often emerges when agile is a grassroots initiative from IT development teams that has garnered little support from the rest of the organization. The end result is that the business does not understand and buy into the MVP (minimum viable product) concept, and important tasks like creating roadmaps and grooming wind up looking like large, time-consuming meetings because the business is not educated on how to participate in an agile environment.
Waterfall hand-offs pattern – “Wagile”
This is the most common pattern for agile failures. In most cases, the company is transitioning from a waterfall methodology to agile and just can’t break old habits. They use the agile terms like grooming, scrum, and daily stand-ups, but they still produce work in sequential order. First the business creates requirements (they call them user stories), then development writes code and throws it over the wall to QA. QA is rushed to certify the release because they are getting the build late in the “sprint”, and then they throw it over the wall to operations who has to deploy the build in the final hours. Other than the terminology, there is nothing agile about this approach.
The unplanned work pattern
Another challenge companies face is that key resources are often pulled off sprints to fix production issues, answer questions, or perform other tasks that cause them to miss their dates. To accommodate this, either the scrum master reduces the number of hours they can allocate the critical resource or the critical resources start padding their estimates to account for lost time. The end result is that projects always take longer than they should because it is hard to predict how much time these critical resources can dedicate to each sprint.
No time for architecture pattern
This one is my biggest pet peeve of them all. Some teams think agile means “start coding”. They believe that architecture evolves over a series of sprints. Nothing could be further from the truth. When building something new, there needs to be a sprint “zero” which allocates enough time for architects to perform their due diligence and create the user stories for non-functional requirements that deal with things like performance, scalability, security, reuse, and more. Skipping sprint zero almost always results in high maintenance costs and unreliable systems down the road. Without architecture, the only thing that evolves from a series of sprints is fragile systems.
Measuring all the wrong things pattern
This pattern is annoying to those of us that believe that the goal of agile is to deliver reliable software quickly. A common fail pattern I see is management focusing too much on metrics like velocity, defect counts, and story points and not enough on delivery and customer satisfaction. Don’t get me wrong; tracking velocity, defects, and story points can provide useful information, but they don’t tell us whether we are being successful or not. In addition, those metrics are unique to each team. I like to compare these metrics to blood pressure. My blood pressure and my wife’s blood pressure will always be different. Mine runs a little high and hers runs a little low. The fact that our numbers are different has no bearing on our health because our numbers are unique to our bodies. What is important is comparing my blood pressure to my previous numbers over time. That is exactly what velocity, defect rates, and story points should be used for. I have seen teams get beat up by management because Team A does not have the same numbers as Team B. That is a waste of time. The best way to compare teams is to measure how happy their customers are and how successful they are at actually meeting their commitments.
Delusional management pattern
Nod your head if you have seen this scenario. Someone in management reads a story about how company XYZ implemented agile, which resulted in their IT team delivering new features left and right. So management declares that the company is moving to agile, puts someone in charge who has little authority to make organizational changes, and tears down the cubes in favor of an open collaborative space. The executive kicks his or her feet up on the desk and declares, “I did my part, now do agile”. “Doing” agile requires an entire organization to change their business processes. Sales people need to stop promising products and features that are not on a roadmap, product managers need to minimize changes to the current sprints and be accountable for the delivery of the product, IT needs to stop working in silos and in a sequential manner, and everyone needs training and new incentives to enforce the proper behaviors. Simply declaring “agile” is not enough.
The “Teflon Roadmap” pattern
Companies that excel at agile do so because they break work down into small manageable chunks and are allowed to stay focused on that work. I often see companies struggle to keep sprints intact because priorities are forever changing and the business has no discipline. Whoever yells the loudest gets their item on the list and the list changes daily. Sprints are interrupted and even completely stopped. Developers and architects are pulled into countless meetings to discuss the next “high priority” item of the day. All of this noise leads to countless distractions that keep teams from focusing on the task at hand.
If we are failing at agile, how will we get DevOps right?
All of these agile fail patterns have me worried because now everyone is looking at the DevOps movement as the savior. DevOps is similar to agile but injects lean thinking into the equation. In a DevOps culture, the team is not only focusing on agility, but also on reliability through eliminating waste, identifying repeatable steps, and automating those steps. Companies that have embraced the DevOps culture have broken down the organizational silos, and everyone shares the accountability for delivery. If we can’t get agile right, how can we take it to the next level required to foster a DevOps culture?
Don’t get me wrong; I have nothing against agile methodologies and I am a huge fan of the DevOps movement. I am simply worried for the large organizations who are struggling with their agile methodologies, and I wonder if they will repeat the same mistakes the next time someone in management reads about how awesome DevOps is.
What organizations need to understand is that to transform an organization, they cannot forget about organizational impacts. Change does not happen by accident. Leaders need to foster that change from top to bottom. People throughout the organization need to be empowered to make the necessary changes to create the desired outcomes. Old habits should not be rewarded, and new habits should be encouraged.
For more research on driving change within an organization, read change guru John Kotter’s 8 step change process here.
Very good eye opener Mike – but it will be good if you can share some of your experience(s) in getting the above said bad practices resolved – it will be helpful for folks in those organization who are facing these business and technical challenges of getting their Agile Practices right across the organization.
Thanks
So what’s the answer to the “unplanned work” anti-pattern? Leave existing system unsupported / less supported?
Saikiran and Christopher,
Thanks for your comments. I will write a post that discusses solutions for each pattern. It should be out by the end of the week. Stay tuned.
Some good points.
One overlooked aspect is quality and testing. They seem to be assumed in many articles but not always included adequately in the real world – leading to inefficiencies, rework, “late cycle or production defects” and “unplanned work”.
As for the “unplanned work” anti-pattern, there are steps we can take to make it all work.
First, stop feeding the beast. Unplanned work is often brought about due to forces outside of the development department. For instance, let’s prevent sales from promising work we can’t deliver without suspending other priorities.
Second, kill the beast through discipline. We all have systems that require support. But, who is giving that support, the developers? Let’s organize ourselves such that products are developed by a first-line engineering team. Once the product or service is delivered and critical features are implemented, move that product to a maintenance team. Proper testing, documentation, and a knowledge transfer process will ensure that the product is handed off successfully. Never build anything that requires ONLY you to maintain. That’s bad business.
Erik, great feedback.