The Affixed List of Agile Principles
The Agile Manifesto lays out four values and twelve principles that guide the pragmatic approach to software development. Through my experience as an agile consultant, I have found that applying these values and principles leads to successful projects . . . mostly. I say "mostly" because like anything else in life, the blind application or religious fervor surrounding any philosophy can lead to the path of senselessness.
In addition to the conventional Agile Manifesto, I find that a few additional principles evolved from the agile mindset. I chose to call these The Affixed List of Agile Principles.
Value Pragmatism Over Consistency
Consistency has its merit in our technical field, but taken to an extreme it has diminishing returns. If for the sake of consistency you are sacrificing common sense, it's time to take a step back and abandon the compulsive need to have everything be consistent.
Practice Listening First
Listening is a not just an agile skill but a life skill. Hearing is different then listening. When listening you don't just hear the sounds and prepare for a rebuttal with your own perception on the issue. Listening indicates that you momentarily pause your own agenda, absorb the external perspective, and seek to understand the background and underpinnings of the alternate view. We should do this even if we are the expert on the subject or the authority in place. This practice increases patience, gains respect, and ultimately leads to inclusion of out of the box ideas which manifest into better overall solutions.
Lead by Ideas, not Authority
As a leader on the team, the effective path to leadership is through the currency of ideas. It is more effective to influence others through the dissemination of persuasion, demonstrations, and example. Demanding something be done without truly convincing another party will yield shallow results. Accept that as a leader, you need to sell, then demonstrate your ideas, not enforce them.
Play the long game
Being Agile is about adapting to complex situations and having the ability to change. Often in a project, all members do not have the will or capacity to change, even if the situation demands it. You can still influence change by playing the long game. Develop a vision for the future and plot out a timeline for influence. Attempt to drive change in pieces. Fortitude and gentle persistence is necessary, while pushiness and derogatory obnoxiousness will only make your goals elusive.
Admit your faulty decisions
Retrospectives play an important part in improving a team's chemistry. On a personal level, admitting you were wrong can provide tangible benefits, whether it be a technical decision or a strategy, Firstly, it shows humility which translates in to respect gained from other team members. Secondly, it clarifies your position on the issue and avoids the perception of flip flopping. Thirdly, admitting to a faulty decision allows you to learn from your mistakes because explicitly you have recognized the action as a mistake.
Think in Tradeoffs, Not Absolutes
Software design can never be perfect. This is the reason for the existence of agile principles such as Good Enough, No BDUF (Big Design Upfront), and JIT (Just in Time) decision making. Instead of chasing unicorns and having the desire to manifest greatness, approach problems by thinking in tradeoffs, not absolutes. Every decision made has positives areas and defective areas. Recognize the deficiencies as tradeoffs and make conscious decisions to mitigate them, or categorize them as technical debt. The tradeoff mentality keeps the project goals in sight and avoids the path to the black hole fantasies.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)