5 Reasons indiviusals Fail to achive Goals

Why do some people achieve their goals while others fail? I believe it's because successful people manage to overcome five barriers that, in many cases, guarantee failure. Here are those barriers and how to overcome them:
1. Uninspiring Goals

When most people set goals, they envision a "thing," such as a particular amount of money, an object (like a new car), or a specific achievement (like writing a book). Unfortunately, these "things I'm gonna get or do" goals don't appeal to the core of what motivates you, because they miss the point that what you're actually seeking in life and work is the POSITIVE EMOTIONS that you believe those things will produce.

Fix: Rather than envisioning a "thing" as your goal, envision--with all the strength in your imagination--how you will feel when you achieve the goal. That way, you'll be inspired to do whatever it takes (within legal and ethical bounds) to achieve that goal.
2. Fear of Failure

If you're afraid of failing, you won't take the necessary risks required to achieve your goal. For example, you won't make that important phone call, because you're afraid that you'll be rebuffed. Or you won't quit your dead-end job and start your own business because you're afraid that you might end up without any money.

Fix: Decide--right now!--that failure, for you, is a strictly temporary condition. If things don't go the way you'd like, it's only a setback that, at most, delays your eventual success. In other words, accept the fact that you'll sometimes fail, but treat that failure as an unavoidable (yet vital) component in your quest.
3. Fear of Success

In many ways, this fear is even more debilitating than the fear of failure. Suppose you achieved something spectacular, like enormous wealth. What if it didn't make you happy? What then? What if you ended up losing all of it? What then? Would your friends start acting weird? Would your family be envious? Such thoughts (and they're common) can cause even a highly motivated person to self-sabotage.

Fix: Decide that you're going to be happy and grateful today and happy and grateful in the future, no matter what happens. Rather than focus on possible problems, envision how wonderful it would be to be able to help your friends and family achieve THEIR goals. (Hint: Watch the last season of the TV series Entourage!)
4. An Unrealistic Timetable

Most people vastly overestimate what they can do in a week and vastly underestimate what they can do in a year. Because of this, most people try to cram too many action items into the short term rather than spacing out activities over the long term. The inability to get all the short-term steps accomplished creates discouragement and the impression that the final goal is slipping away.

Fix: As you list the activities and steps required to achieve a goal, schedule only the 20% of the activities that will produce 80% of your results. (I explain more about this in the post The Secret of Time Management.) Beyond that, set ambitious long-term timetables, but always leave some "wiggle room" when you plan short term.
5. Worrying About "Dry Spots"

It's easy to get discouraged when you reach a point at which nothing you do seems to advance you toward your goal. For example, suppose you're trying to master a certain skill. You make swift progress at first but then, after a while, it seems as if you're not doing any better, or maybe a little worse. Some people use these "plateaus" or "dry spots" as an excuse to give up and therefore fail.

Fix: Whenever you reach a plateau or dry spot, it's time to celebrate rather than give up. A plateau is almost always a sign that you're on the brink of a major breakthrough, if you just have the patience to stick with it and trust that you'll eventually achieve your goal.

Do not try to Agile Scrum When you don't know what is Agile Scrum

Agile is not a playbook. It’s not a set of directions. It’s not a checklist. It’s a mindset and a culture – and it needs buy-in across an entire organization in order to succeed. 


i need to share some Few Reasons why Scrum Fails from an Article by Mike Brown on utest Blog as below:

Old Habits Die Hard

Based on my observations and those of several noted experts, Agile seems to “fail” whenever it’s forced on a team or organization that is accustomed to other methods. After years of developing and testing in a certain manner, one cannot expect an entirely smooth transition. Want proof? Here are a few results of a recent survey that interviewed 200 companies that had recently transitioned to Agile:

Out of over 200 participants, 64 percent said that switching to Agile Development was harder than it initially seemed. Forty percent of respondents did not identify an obvious benefit to the practice. Out of those who did, 14 percent thought it resulted in faster releases, and 13 percent – that it created more feedback. Seven percent of participants noted that Agile developers were happier due to reduced future planning and documentation.

According to Voke, since the global financial crisis of 2008, the average cost of software projects has seen a sharp rise, even though developer teams have become smaller and the deadlines tighter. Meanwhile, the risk of software failures associated with Agile Development has remained high.

“While many people assume that Agile is faster, better, and cheaper, actual results vary greatly. Many organizations are diving into the Agile movement without a clear understanding of what it is, and what the consequences of adoption may be. They may not realize that today’s solutions are tomorrow’s problems,” said Theresa Lanowitz, lead analyst at Voke. (link)

I think it’s fair to say that the process of “going Agile” must be clearly explained and outlined (more on this shortly), otherwise your development practices will change, but in name only.


“I don’t think most people need convincing about agile principles, even if they’re just attracted to the idea of frequent delivery,” said Nate Oster, an Agile Player-Coach and Founder of CodeSquads LLC. “In practice, however, a lot of waterfall behaviors survive by hiding behind the new agile jargon. If we want different results, it’s not enough to change our jargon, we have to actually change the way we collaborate!”

He continued: “I think the deep-down objection to agile is that it challenges our hidden assumptions. A lot of our cherished ‘best practices’ from waterfall are actually optimizations of ‘our job’ – they make us ‘efficient’ but actually undermine the agile goal of frequently delivering high quality software as a whole team.”

In terms of waterfall legacies, Nate gave me the example of how some test teams still request that a feature be 100% complete before it’s ready to be tested.

“That’s a verification mentality, a holdout from waterfall when it was the tester’s job to efficiently find all the bugs,” he explained. “On agile teams, we prevent those bugs by specifying the feature as a team using testable examples, then we build those behaviors in small slices. When we work in small increments like this, we test continuously instead of at the end. That’s how we prevent ‘mini-waterfall testing.”

So is making an Agile transition impossible? Not at all. Is it difficult? Yes. Is it necessary? Here’s what Agile expert Scott Barber once had to say on the matter:

I believe that the trend to “go Agile” is misguided. If a company is developing good software, the people involved in developing that software are happy working there, the software development is sustainable, and the business is being adequately served by that software, there’s really no need for them to try to be more or less Agile. Agile has challenges like any other culture, but the single biggest challenge I find is companies trying to solve development, process, management, and/or schedule problems by “going Agile.” Teams who have grown up in a culture that is fundamentally different than Agile simply will not find it easy to “go Agile.”

Unrealistic Expectations

Another reason why Agile sometimes fails has to do with unrealistic expectations of the Agile actually is and what it can help you achieve. Agile is commonly believed to be a set a practices, processes and tools, when in fact, Agile is really more of a mind-set and culture.

Processes vary depending on the company, the product and the personnel, so it’s no surprise that they sometimes fail when they are misapplied. A mind-set and culture, on the other hand, can transcend those factors. Here’s a good analogy of this problem from Scott Ambler (emphasis added):

Would you take the same approach to create a web page describing your family and the embedded software for a NASA space probe? Of course you wouldn’t. What about a business application and a NASA space probe? Likely not. Would you take the same approach with a team of six people that you would with a team of sixty people? Or six hundred people? Once again, likely not. Different situations obviously call for different approaches.

It’s easy to see that you need to take a different approach developing a web page as compared to developing a space probe. Your company likely doesn’t develop both web pages and space probes, so it’s easy to stand back and recognize that there’s a difference. It would be clearly foolish to follow similar approaches on these projects – a very simple process is sufficient for the web page development effort whereas a complex and rigorous process could be appropriate for the space probe. You would put the space probe project at serious risk following the web page process and you would incur significant costs following the space probe software process to develop your web page. Clearly it is important to follow the right process.

Basically, if you expect Agile to perform miracles or instantly transform your software development process, then you’re likely to view the method as a major failure.

Department Fragmentation

What happens when a development and product team adheres to the principles of Agile, but the QA team does not? Conversely, what happens when a QA team wants to be involved early in the dev process, but the engineering and product teams resist? What happens when executives want everything to be Agile even if they don’t really understand what it means?

“When I hear ‘we have an agile test team,’ I think that’s a contradiction in terms,” said Oster. “If all they do is test, then they’re not really an agile team. Agile teams frequently deliver high quality software, and that includes testing. An agile ‘feature team’ needs all the skills it takes to deliver software, and that includes programming, analysis, and testing skills, regardless of who performs these tasks. I love it when new agile team members start cross-training outside the role on their business card. Mature agile teams know there isn’t a sharp line between ‘my job’ and ‘your job.’ There are just tasks we need to complete, and everyone brings different skills to the table, so that we can complete them as a whole team.”

As mentioned previously, Agile is not a playbook. It’s not a set of directions. It’s not a checklist. As Scott Barber said, it’s a mindset and a culture – and it needs buy-in across an entire organization in order to succeed . Here’s a great presentation by Agile coach Mike Cottmeyer that explains the importance of agile being adopted by multiple departments

Giving Up Too Easily

As we’ve covered, the transition to Agile isn’t easy. I’m sure every department thinks they have the steepest climb, but since this is a testing blog, we’re going to focus on the QA department and its ability (or lack thereof) to move to an agile process. As Nate Oster points out, the problems of the agile transition have less to do with Agile and more to do with existing practices.

“In my experience the biggest challenge with adopting agile is how it just relentlessly exposes what we’re not very good at yet, and in a lot of organizations, that includes testing,” he said. “When the goal is frequently completing new features, that forces teams to work in small batches with short timeframes, so agile exposes how traditional testing is optimized for ‘throwing a big pile of code over the wall.’ Traditional testing is really a broken system, because these huge piles of work arrive late in the game.”

When trying to adopt Agile practices, there will be a ton of excuses as why it won’t work. Those who understand the real benefits of the approach – and genuinely want to make the transition – will likely have success. Those who are searching for reasons why it will fail – well, they will likely find them and either abandon the effort entirely or end up practicing what i calls “fake agile.”