The "Success Well" idea is based on two main underlying principles, both of which are essential for leadership & management and explain why Agile has become such a powerful idea.
Agile as an idea and Scrum as a framework have several built-in techniques that “fill” in the “success well” of the team and of each team member. This is where the productivity really comes from, not fr om sticks and carrots, but fr om the “well of success.”
The Success Well approach initially came fr om the martial arts, wh ere it is defined that each person has his own well of success. Failure empties your success well, success fills it. If success is large, the well fills up, if it is a small win – only a few drops are added.
The first main principle is that “you are only willing to attempt a task that is in size equal to the amount of success in your well.” Trying and failing a task larger than your current amount of success will lead to a major blow to one’s self-esteem and result in possible resistance to trying again. Therefore, if we want to try something large (or want to work with the people who are able to try new things) we should build on earlier large-scale success or on lots of small successes. The number of successes creates a sort of resilience to failure, greater self-esteem and ability to work with new technologies and uncertain environments. On the contrary, a set of failures (when success well is emptied) leads to paralysis. Social sciences has studied this paralysis and calls it the “learned helplessness” when people stop believing that their actions can change the situation and give up trying.
The second idea behind the Success Well is how we can predict our future.
Studies show that if people can anticipate success and changes for the better, then they are willing to apply more effort today and feel much better about current activities. Predicting success is not as straightforward as one may imagine. It is not enough just to make a decision or say out loud: “I will do that.” There should be a concrete basement for that future success prediction. This basis is defined by the history of our actions and successes of 90 days period. Our brain makes sort of extrapolation “what you have been doing for the past 3 months, so I can expect you to proceed in this manner and soundly estimate wh ere you can end up in 3 months, 1 year, 5 years.” If you did nothing, the brain (its deeper layers, limbic system and deeper) will just not pay attention to your affirmations about unrealistic future and on the physical level you may expect procrastination, inability to concentrate on the strategic goals and other problems related to willpower.
As you might have realized, the easiest and most manageable way to boost the ability to start ambitious goals and enjoy significant success is to fill your success well by constantly experiencing small but clear and pleasant successes.
Agile as an idea and Scrum as a framework have several built-in techniques that “fill” in the “success well” of the team and of each team member. First is the set of practices that focus on defining the result. Before the result was achieved, we can't tell whether it was a success or a failure. Definition of Done (on Story, Sprint, Release level), Sprint Goal and Story tests all help us to clearly set the result bar.
Automated test frameworks and Continuous integration give the immediate and independent feedback about the result – red or green, failure or success. The smart secret here is that most of the Agile rules prohibit leaving code in the red state. Therefore it may take more or less effort, but i the end the result would be a 100% success (adding a few drops to your success well).
During Sprint Planning when the Tasks that will lead to User story completion are identified, general recommendation is to keep them small enough. I completely support this recommendation and emphasize that if we make tasks equal or smaller than a one person day (4-5 perfect hours), then every day, each team member will experience task completion. That is success. Therefore, by using only properly sized tasks we constantly fill the “wells” of our colleagues and our own too.
Demo with acceptance stories and user Story Tests is the larger success on the Sprint Level. If the large success was not fully achieved (Demo failed), we still can separate the successful stories (that add the velocity to the progress calculation) from those that need more work and thus reduce the level of success well drainage.
Retrospectives that emphasize the actions that we plan and perform toward better processes and more probable success use the “90 days base” approach. Paying attention to what was done and how the team improved during last sprint boosts the self-esteem and predictions of overall project success, therefore the team morale is better, work is easier and moods are brighter.
But the real genius of Agile is the overall Backlog concept. Backlog is not the set of features that must fit in the project; it is the set of possible features and ideas. Therefore if a Product Owner has to cut some features from the release, this is not a failure, no one ever started working on them, and they have lower priority. Projects are not cancelled; they are stopped and can be used with current set of functionality. Practically there is no risk of emptying the success well because of a major failure.
In conclusion, there is no surprise that using Agile principles and frameworks, development teams are constantly receiving rewards, filling their success wells and literally get addicted to doing a better and better job and enjoying more and more success. This is wh ere the productivity really comes from, not from sticks and carrots, but from the Well of Success.
According to Theory of Needs by David McClelland, there are three main motivation drives: need for achievement, need for affiliation and need for power. Let’s see what are these needs about and how to deal with it.
Need for achievement.
Need for achievement.
Once upon a time I had to work with a project team that was supposed to use Scrum. The very first thing I discovered was their motivation, or rather their lack of it. Some developers left the project team upon my arrival, and a few others were gettin...
For some time now I’ve been a part of the scrum.org organization, which provides high-quality Scrum education and helps development teams and customers to maximize value by using the Scrum framework. As a part of the Professional Scrum Trainers commu...