Agile doesn't fail; people do.
At its core, agile is a collective mindset, the culture thing. “Agile” as a mindset can't fail - because it is essentially a philosophy defined by a very short manifesto. And it's a principle to run today's business. If being agile is an ultimate goal you are going to achieve, it shouldn't fail; and then doing agile is the intermediate steps for continuous delivery, it is sometimes failing, but how to learn from it?
At its core, agile is a collective mindset, the culture thing. “Agile” as a mindset can't fail - because it is essentially a philosophy defined by a very short manifesto. And it's a principle to run today's business. If being agile is an ultimate goal you are going to achieve, it shouldn't fail; and then doing agile is the intermediate steps for continuous delivery, it is sometimes failing, but how to learn from it?Agile is not a process you can implement but rather a change of culture. It sometimes fails because this is really difficult to nurture, and companies don't realize benefits quickly enough. It can also fail when a process such as Scrum is implemented without an understanding of the Agile values. In the context of moving from traditional (waterfall-like) to agile, failure always happens due to poor management: middle managers resisting to change and a serious lack of commitment from top management. This results in a bad implementation of agility and epic fails. Regardless of the process, agile or not, to succeed in Agile, the entire organization has to be aligned. Agile is not a cure-all, and nothing in life is ever guaranteed. Agile is a way of delivery, it's not meant for solving problems and is not a shortcut to delivery either. Failure happens on any delivery model. At the end, the right set of team's skills and the right collaboration and alignment of talent professionals with team increases the possibility of success.
Agile doesn't fail; people do. They do so for all sorts of reasons. Nobody is perfect. As a result, there is no perfect score when it comes to project success. What is important is that the chances of scoring high are improved with agile if the people are trained, properly led, directed, motivated and marshaled towards achievable goals. Lots of meaning in a few words. One more reason for Agile to fail can be team members taking advantage of the process. Few interested people at the engineering level tend to try to implement, but don't really master things. They keep the old process and add some agility flavor, because you know: "we need to change everything but not too much...", and they soon messed up. At the end, nobody at the top management level wants to hear about agility anymore. Since Agile believes in trust, transparency and team commitment, exploitation of any of the three facets can and will bring a project to failure. The continuous improvement which means, changing your process and even making up new stuff to address observed problems is, so fundamental to agility. But rigidly following a set process (like Scrum) is a recipe for failure. So, the problem is neither people who think their process is "better" or deviation from a "set" of the process. The problem is not knowing enough to assess what is actually better, and having a rigid process that's developed by people outside the team. Only the team can decide what's "better" for it, and the team's decision should be over any rigid process created by outsiders.
Risk awareness and risk management: Software Development work inherently has "Unknown unknowns." There's always a risk that in among these will be something that causes the project to 'fail.' Even if you do everything right, there's still a risk of failure. And some of the teams who think they are "Agile" will not know how to do everything right. For them, the risk is greater, proportional to their level of ignorance. So there are two things you can do; 1) choose the level of risk that you want to work with; tame low-risk projects that are not much more than construction; challenging development projects where there is a real risk of failure; research projects where "success" in the conventional meaning for development work is very unlikely, but the chance of finding something really valuable is worth the risk. And 2) understand, in depth, the business, the mindset and the practices of modern software development.
Fail fast and fail forward. Agile approaches can't guarantee you project will succeed either - however it can help you to "fail early" and minimize the cost, effort and waste involved. It's not Agile that is failing the business, just the people in the business failing to be Agile. So whether the project success or failure there will be transformational benefits to the team and those benefits can be stepping stones to build an agile organization. So instead calling failure, you can claim improvements needed, and will happen over the time, and this will boost up team energy to move on and scale up. As a team, however, you might fail if:
- you fail to produce valuable software for the clients
- you obsess about processes and tools while ignoring individuals and interactions
- you resent change and want to stick to the (beautiful) plan
- you ignore the "business people" in the organization
- you fail to communicate effectively and become stressed and angry as a result
- you focus on what you want to do, not what the client needs
- you work at a pace or with too much intensity
- you ignore simple solutions in favor of more technically interesting complex ones
-you can fail to be honest when we reflect on what we need to do to improve
"Agile is a silver mirror, not a silver bullet," you can use it to identify behaviors you need to change, but making those changes, and making them stick is up to you. Being Agile is about continuous improvement. And this implies continuous changes.
0 comments:
Post a Comment