Agile is about failing your way to success and impact. It is also about doing the right things before doing things right.
More and more organizations are on their journey from doing Agile to being agile, and there are many obstacles on the way, what are the causes of those failures, do they fail to follow the principles, or are they failing to do the best practices? Are they failing forward or backward? Who should take more responsibility -the leadership or fellowship?
The major obstacle to agile transformation is the "WHY" principle. If people don't buy into the need, they will fight change tooth and nail. When they do, change is easier especially if you remove the major obstacle which is the middle where people are comfortable and adverse to change. The root cause of the "copy & fail" concept is an emphasis on "doing Agile" without understanding the people-centric values of "being Agile" are what makes the magic happen. There are other psychological factors that contribute... but the big WHY is the primary root cause leads to a whole mess of different flavors of "failures."
Agile is simply not equipped to have meaningful conversations with executives. If you cannot "sell" Agile to the top, their "What's In It For Me?" question will not resolve positively. To increase the success rate of large "Agile Transformation" programs, Agile needs to evolve and address the needs of executive management, so that they get a reason to believe in Agile. And at the end of the day, it boils down to speaking their language: numbers.
Agile is pushed into an organization, without pulling the necessary resources and the culture of innovation. The only 'thing' forgotten is that people do not want to change without understanding and support. Implementing the Agile method is simple but executing the new way of working with the people is a lot harder. It is not so surprising to see, after 6-12 months, upper management discovers Agile is not working at all. Because they forgot their people to buy in, this happens frequently with any changes.
If an organization sees an attempt at implementation as a failure, they will never be Agile. Agile is about failing your way to success and impact, not about labeling efforts. A successful implementation of Agile can mean many things, ranging from "we were a really cool organization and now we found and implemented a system that supports our values and passion" to "due to xxx circumstance we have had to break down our organization completely and rebuild it with Agility as its ultimate purpose, we are not there yet, but we are working on it." Too many traditional, Waterfall companies think Agile is a plug-and-play process, which it isn't. Agile transformation requires just that - transformation. Most businesses overlook that phrasing entirely. It requires not only buy-in but actual commitment throughout and across the organization.
Lack of strategic change agents: The larger the scope of change, the more people you are likely to have who are not really *bought in* to the change. So the larger transformations are more likely to fail. They would require a very large effort at ensuring a sufficient number of people 1) have really bought into the change and 2) have sufficient assistance to pull the rest along with them as the new ways and thinking bed themselves in. If people haven't *really* bought into a change, then as soon as things become difficult they will revert to what they are familiar with. Where people have really bought into a change, then they will be strongly motivated to find ways of making it work, whenever things get difficult. It's the change agents' obligation - on whichever level they may be - to invest time and effort in educating the whole organization about the change, it's goals, advantages, and disadvantages. If they don't, they've already failed. When the top management just announces that "from tomorrow on we're agile," and the people doing the work don't get the information, support, and room to learn, the implementation will fail. When the development unit decides to go, without explaining to the business why they need to answer questions all the time instead of just sending a list of requirements and getting back to their jobs, the implementation will fail.
Follow other’s footstep without reflection: As with any process improvement initiative, you need to be realistic about agile. It is another tool in the toolbox and not a silver bullet. The key is to understand why you are undertaking an agile process and what you expect to achieve. Don't do agile because the other company is doing it. Assess the challenges specific to your organization. What keeps you up a night? Determine the best tools to address those challenges. Agile may be just one of several improvement initiatives. Assess your team, product, and culture honestly. Agile works best for small cross-functional teams with good interaction with customers or customer proxies (business analysts). Is your team open to an agile mindset? In agile, you have to be able to make progress without having the whole answer and to not gold plate with features that you think will be necessary.
Fail to select the right project to do Agile. To succeed, start small. Get the proper tools and training. Hire a coach. Define your goals ahead of time and understand how agile can help achieve them. Agile can be frustrating if you don't have a comprehensive strategy, principles, or practices, and you are trying to take ivory approach.
1). Improper IT motivation for adopting Agile. It is mostly the development team adopting "Agile" to avoid planning and documentation. This leads to Cowboy coding, which leads to a dissatisfied business. Add on top of this the lack of fully vetting out what done looks like and you have disaster point #1. The best way to conquer this is to start running the meetings off your tracking tool (which hopefully is Agile). This helps you use science to uncover hidden impediments and make sure everyone keeps the boards up to date.
2). Lack of business buy into the culture: While they certainly buy into the "development practices Agile" concept, they don't want the added "overhead" of having to prune the backlog every time they get a new item at a higher priority.
3). Executive/management view of Agile as a silver bullet. You have to get management to understand that Agile does not magically make things faster. That the faster is accomplished more by the following:
A. Pruning out non-priority items. Less work is done in less time.
B. Understanding what is acceptable and what is not. But this only works well when a business gives up the time to give full acceptance criteria, the team asks questions when given the time and the team codes tests to cover the acceptance.
1). Improper IT motivation for adopting Agile. It is mostly the development team adopting "Agile" to avoid planning and documentation. This leads to Cowboy coding, which leads to a dissatisfied business. Add on top of this the lack of fully vetting out what done looks like and you have disaster point #1. The best way to conquer this is to start running the meetings off your tracking tool (which hopefully is Agile). This helps you use science to uncover hidden impediments and make sure everyone keeps the boards up to date.
2). Lack of business buy into the culture: While they certainly buy into the "development practices Agile" concept, they don't want the added "overhead" of having to prune the backlog every time they get a new item at a higher priority.
3). Executive/management view of Agile as a silver bullet. You have to get management to understand that Agile does not magically make things faster. That the faster is accomplished more by the following:
A. Pruning out non-priority items. Less work is done in less time.
B. Understanding what is acceptable and what is not. But this only works well when a business gives up the time to give full acceptance criteria, the team asks questions when given the time and the team codes tests to cover the acceptance.
Agile pioneers try to ensure Agile projects would get better, more consistently successful, results. One of the most important fundamentals of Agile is the emphasis of producing "Learning" Teams - not only learning about the product you are developing but also learning how best to work as a team. The organizational leadership should embrace this philosophy, building Agile Practices iteratively and becoming a "learning" organization; inspecting and adapting, learning from the mistakes and successes of its teams, learning from other organizations and best practices external to the organization. It is a well-prepared journey.
0 comments:
Post a Comment