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.”

The SCRUM Blog: Your Scrum team's velocity and how to misuse it.

The SCRUM Blog: Your Scrum team's velocity and how to misuse it.: Your team has a velocity, whether you choose to measure it or not is irrelevant. On an average day, your team decreases the amount of work t...

Steps and Techniques for the Scrum Implementation

      from my learning i came to understand that if you want to evaluate at which level Team or Project is in Scrum check the list of Steps and Techniques implemented in your Team and Project.

• Relative estimation
• Test driven development (TDD)
• Acceptance test driven development (ATDD)
• Automated Unit Testing
• Automated System Testing
• Automated Acceptance Testing
• Automated Regression Testing
• Explicit Definition of Done for Stories
• Explicit Definition of Done for Iterations
• Explicit Definition of Done for Releases
• Definition of Done includes quality goals
• Pair programming
• Peer code reviews
• Product Backlog Grooming
• Social contract/working agreements
• Continuous integration
• User stories
• Up front architecture

The Case Against Agile: Ten Perennial Management Objections

Steve Denning, Contributor from RADICAL MANAGEMENT: Rethinking leadership and innovation


If at first an idea is not absurd, there is no hope for it.

–Albert Einstein

The general reaction within the Agile world was naturally strongly positive. Finally, mainstream management is getting it. “Next step -> Rule the World!”

There was somewhat less enthusiasm from the traditional management camp to having the world ruled by Agile. The most complete—and revealing—response from the traditional management camp came from a link submitted by PM Hut and written by Bruno Collet: The Limitations of Agile Software Development. The defenders of traditional management claim to be unafraid of being tagged as “behind”, “old school” or “just plain stupid”: traditional IT professionals know that “Agile has limitations.”

1. “Agile is only for stars”

“Agile was designed for experienced, smart, and high-achieving people like its creators, i.e. stars. You could give them any project, with any method, and they would succeed. Not every group can be motivated, experienced, and skilled enough to self-organize into an efficient team. We have to work with the staff we have. They need close supervision. So Agile is not for us.”

In other words, make do with mediocrity. Learn to live with the people who are either not experienced or smart or high-achieving. Hierarchical bureaucracy makes an assumption of incompetence and expects mediocre performance. It learns to live with mediocrity on a permanent basis, in the process creating—not surprisingly—the need for the layers middle managers to provide the “close supervision”.

Agile makes the opposite assumption: competence. It expects performance and forces action if it doesn’t occur. It assumes a workforce who know what they are doing and provides a transparent framework for them to show what they can do. If the group doesn’t deliver at the end of each short cycle, then that is painfully apparent to everyone—immediately, not years later when the project runs out of money and the software doesn’t work. Agile is a way of forcing either high performance or change.

Agile squeezes out mediocrity and requires high-performance. Hierarchical bureaucracy breeds incompetence and feeds off mediocrity: the organization performs accordingly. Faced with the choice between high-performance and the mediocrity, traditional management opts for mediocrity.

2. “Agile doesn’t fit our organizational culture”

“Agile is fine for startups run by kids with earrings, tattoos and blue hair. But in our firm, respecting the chain of command and job responsibility are keys to survival. It takes a couple of days just to go through the company’s policy manual. The narrow responsibilities, and rigid policies, processes, and one-size-fits-all methodologies of our firm don’t fit the free-wheeling ways of Agile. Agile isn’t going to work here.”

Precisely. What’s wrong here is the corporate culture, not Agile. Surviving in today’s marketplace requires individual and team freedom. It translates into cross-functional work that is constantly adapting, with roles switching as needed. It also mewans adjusting processes continuously to reflect the current situation.

In Agile, processes are secondary to the requirements of the work. Bureaucracy is the opposite: the requirements of the work—and the customer—are secondary to the bureaucracy. Not surprisingly, firms in this mode do a poor job of meeting customers’ needs.

When the culture doesn’t fit Agile, the solution is not to reject Agile. The solution is to change the organizational culture. One doesn’t even have to look at the business results of firms using hierarchical bureaucracy to know that they are fatally ill. In today’s marketplace, they will need to change their culture or they will die. They need to become Agile.

3. “Agile only works for small projects and our projects are big”

“Teams larger than eight are too big to be Agile. We are a large organization with large projects so Agile won’t work for us.”

It’s true that Agile requires small teams. The reality as Richard Hackman pointed out in his classic book, Leading Teams: Setting the Stage for Great Performances, is that all effective teams should be small. A big effective team is an oxymoron.

In any event, there are obvious solutions to coping with large projects by dividing the work into a number of relatively independent smaller subprojects then each part can be implemented by an agile team. As explained by Craig Larman and Bas Vodde in their book, Practices for Scaling Lean & Agile Development: Large, Multisite, and Offshore Product Development with Large-Scale Scrum (2010).

4. “Agile requires co-location and our staff are geographically dispersed”

“Agile emphasizes that face-to-face, spontaneous conversation is the best form of communication. In some organizations, this isn’t possible. Moreover, work extends beyond the development team since other stakeholders such as business analysts also require interaction. Hence this limits the applicability of Agile.”

While it’s true that co-location is obviously ideal for Agile teams, where staff are dispersed, teams can use technology maintain open and continuous communication.

The reality is that distributed software development using Agile can be highly productive, as firms like Xebia have shown. See also the Larman/Vodde book for more discussion of distributed Agile teams.

5. “Agile lacks project management processes”

“Most agile methodologies do not define any project management processes. Whether we’re agile or not, we need to manage project scope, planning, budgets, strategies, and reporting. So Agile can’t be the answer.”

It’s true that Agile doesn’t solve all management issues. Agile solves a specific management issue, namely, how to combine disciplined execution with creativity and innovation.

As Bruno Collet helpfully points out, “Unless you choose an agile methodology that encompasses all needed processes, you should combine it with a methodology that define these processes and rely on agile for day-to-day team management.”

6. “Our firm’s individual accountability systems don’t fit Agile”


“Agile development stresses the importance of team ownership in order to improve teamwork and therefore overall results. But how can we implement team ownership when our organization’s performance-reward system assesses individual performance and rewards individuals, not teams?”

The answer is pretty simple: change the organization’s reward system. They are the problem, not Agile.

7. “Agile is just a fad”

“Here we go again. Another silver bullet! Another panacea! Another management fad!”

Again, let’s be clear. The article didn’t say that Agile was “the” solution to everything. It’s not a panacea. It’s not a silver bullet. What the article said was that Agile is the solution to a particular problem, namely, reconciling disciplined execution with creativity and innovation.

There are other management problems that the Agile Manifesto didn’t address. Some of those other management problems are discussed in Kent Beck’s talk discussed in Applying ‘inspect and adapt’ to the Agile Manifesto.

One important aspect concerns the goal of the organization. Agile teams that work in organizations where the goal is maximizing shareholder value are ultimately just as doomed as teams practicing waterfall. Sooner or later, the money-driven culture will crush even the successful Agile teams. Genuine Agile involves re-thinking the goal of the entire organization in terms of adding value to customers sooner.

8. “There are better ideas than Agile”

One critic said, “Introducing these ideas to management via the path of Agile software development doesn’t make sense. Much more interesting would be to introduce these ideas via things that make sense to non-software managers, such as beyond budgeting, complexity thinking, lean management and rightshifting.”

Ignoring the management experience of thousands of software development teams around the world is what doesn’t make sense. A better idea is a better idea, even if it comes from the “wrong” people.

The approaches of beyond budgeting, complexity thinking, lean management and rightshifting are helpful and obviously related to Agile software development, but it’s not obvious that they are having any more real success in changing the basic command-and-control paradigm of traditional management.

Rather than fighting internecine battles (e.g. Lean is better than Agile or Kanban is superior to Scrum), it would be more useful to see the commonalities in these various movements and join forces to get real transformation of traditional management.

9. “Nothing new here”

All of the individual components of Agile have been around for quite a long time. What is new is to put those elements together in a coherent and integrated fashion as in radical management.

10. “Not a fair comparison?”

“How can you possibly compare Agile to the discovery of longitude?” was one agitated answer to the first article which cited the historical examples where path-breaking ideas were rejected by the experts for decades, such as the sad experience of John Harrison who despite the scientists discovered a way to measure longitude.

Let’s be clear, first, that John Harrison, the Yorkshire carpenter, didn’t “discover longitude”. The British scientists of the 18th Century knew all about longitude. What they didn’t know was how ships’ captains could measure longitude in the middle of the oceans. They could measure latitude from the stars, but they couldn’t seem to find a way to read the stars so as to get a handle on longitude. So the scientists spent decades studying the stars trying to find the secret that “must be there”.

What John Harrison figured out was that the answer didn’t lie in the stars: the solution lay in having an accurate clock. With an accurate clock, you could take a reading from the sun at noon and figure out your longitude. The problem was that there weren’t any clocks accurate throughout a long voyage. So Harrison set out to invent one. When he had done it and shown that it worked on the long voyage from London to Jamaica, the scientists went apoplectic. They were upset that the solution to the problem didn’t lie in the fancy astronomy of the heavens that they had been studying for decades: it lay right under their noises with a simple clock. Very annoying!

In their frustration, the scientists refused to concede that they had been wrong and give John Harrison his well-deserved prize. It took an act of parliament—in effect, ordinary citizens—to give him his recompense: equivalent to over a million pounds in today’s money.

Something similar seems to be happening with Agile. The solutions that the experts have offered to the problem of reconciling disciplined execution with innovation have all tended to be various ways of increasing or modifying control over an increasing number of ideas—chief innovation officers (Debra Amidon), innovation “factories” (P&G), the innovation marketplace (Alpheus Bingham and Dwayne Spradlin), separate business units (Clayton Christensen), open source innovation (Henry Chesbrough) and shared value (Michael Porter and Mark Kramer).

What’s annoying about Agile to control-minded management practitioners and theorists is that it recognizes that the problem lies is control itself. The solution to reconciling disciplined execution and innovation lies in giving greater freedom to those people doing the work to exercise their talents and creativity, but doing so within short cycles so that those doing the work can themselves see whether they are making progress or not.

Even worse for hierarchical bureaucracy, Agile thrives on transparency. One of the dirty not-so-little secrets of traditional management is that control thrives on non-transparency. So introducing (real) Agile means exposing all of the non-transparent tricks that hierarchical managers play on their subordinates to maintain power. Is it any wonder that Agile isn’t naturally popular with the command-and-control gang?

How to Do Better Daily Standup Meeting

Best example of dis-functional Daily Scrum Stand up meeting with best Tips to improve it.
http://youtu.be/q_R9wQY4G5I