In our hurry to ‘do Agile’ let us not forget why we are doing it and where we are going.
Quixotic means to be impulsive, often rashly unpredictable and impractical. It also means idealistic and un-realistic. Why does this term matter you may ask? Whereas the energy and perseverance of the romantic, idealistic quixotic mind can give us courage and stamina to try new things, the flip-side of that is the rashly unpredictable and impractical commitment to the wrong things in wasteful ways and disappointing results. If, in their enthusiasm to do Agile, the team skips through Agile planning and principles and goes straight to starting a sprint, then it is like Don Quixote who set out to fight dragons only to find himself jousting with windmills. Thus their quixotic effort; although enthusiastic, will probably fail to deliver.
I have the privilege and opportunity to work with many teams who are striving to implement and improve Agile. I witness the struggles and challenges teams face while adopting this powerful model for team-based development. Many organizations view Agile as a solution, perhaps even a silver-bullet that will enable them to quickly deliver maximum value to their customers. But in a rush to “do” Agile far too many teams end up doing it in a way that is impulsive, unpredictable and even unrealistic – the result is what I call ‘Quixotic Agile’.
What is Quixotic Agile?
‘Quixotic Agile’ is impulsively “doing” Agile (sometimes simply to be able to say we’re doing it) or applying Agile practices in an unpredictable way. During this early romantic period where we fall in love with notion of ‘Agileness’ and pursue some vague definition of Agile based on our intuitive ideal of what the word agile means can be dangerous to the long term transformation to an truly agile organization. Teams without proper instruction and perhaps coaching will take short cuts and pursue the easy path. The consequences of this can be hidden for a while because talented and smart people will tend to get something done regardless of obstacles. Whether that something was worth doing in the first place is questionable. In this circumstance the team’s performance may temporarily seem to improve but will quickly result in lower performance. This is a well-documented phenomenon by Dr. Satir (search the Satir performance improvement curve). We should not rely on our enthusiasm for the process or methodology while forgetting that our goal is not to do Agile but to find better ways of delivering valuable working software to our users. Agile is not a silver bullet and when done carelessly, can actually make teams more chaotic.
Agile has a strong appeal for teams with a quixotic personality. The flexibility, the promise of improved performance and ability to do what you want, how you want, when you want is alluring. A typical Quixotic agile scenario plays out when leadership has mandated a move to agile this year without the budget or support to re-organize or to get a coach. The result is an Agile project managed using waterfall tools, inheriting substantial waterfall process but using agile terminology and conducting a daily status meeting that the team declares as their standup. These teams will skip many agile practices, ignore the principles, and hopscotch straight to planning a sprint. Perhaps these teams have the impression that to simply do Agile means they are Agile or to adopt a few agile practices will result in marked improvement…it’s not that simple.
The reality is that teams will plan and do something – anything – to stay active and busy. Parkinson’s law is that, “work expands so as to fill the time available for its completion” if the business hasn’t defined and prioritized enough valuable work to fill our sprint then teams will fill their sprint with something. A quixotic team will soon find themselves scrambling to assemble enough work for a sprint and possibly filling up the sprint with some work of their own invention simply to fill the time. This creates waste in the process and product while at the same time developing a false sense of productivity. By approaching a product this way they quickly lose sight of fundamental Agile principles such as: technical excellence and good design, delivering valuable software continuously and maximizing the amount of work not done. They will inevitably tend towards a short-term perspective and short-term planning model – only planning sprint-by-sprint, technical excellence is compromised due to a failure to see the larger picture. The compulsion to plan a sprint worth and work fast can result in ad hoc development and gold plating.
Five Levels of Planning: Vision, Roadmap, Release, Sprint, and Daily
How can an organization capitalize on the new energy of becoming agile, transform in to an Agile team, continue to deliver valuable working software to their users and customers and avoid the mistakes of failed agile efforts?
How can a team NOT become quixotic?
The key is simple. Do the basics! Begin at the starting line rather than skipping to the finish line. The team should pay their dues and learn the process. Take a few lumps early but learn from them. Look back to the philosophy and principles for guidance in defining the purpose of the practices and process. Do not rely merely on reading and intuitive understanding of the word agile. Get some training, and if possible, hire an experienced transformation coach early rather then an agile medic later. As a team, start with the Agile planning and collaboration process. There are five levels of Agile planning that make Agile teams successful – not only in their production process – but also in their transformation. A disciplined team (yes agile requires discipline) will begin by following a well proven path and process as they gain their own experience and discover better ways of applying agile principles; whereas, a quixotic team might jump straight to sprint planning while skipping over vision, roadmap, backlog development and release planning.
Turning a team from quixotic agile in to a high-performing team requires focus and attention and regular reinforcement of agile principles and practices rather than simply al-a-cart adoption of a few practices. High performing teams will prepare, execute and improve.
Each team will certainly tailor how they apply agile; Quixotic agile teams will often attempt to be all-inclusive and tolerant of all practices but we should a bit selective and we should not attempt to blend all things together. Trying to please all possible processes will result in a fragile and unsustainable model. A team who does this will rapidly digress to ad hoc or possibly worse, chaos and failure. The successful high performing team will most certainly discover their unique agile formula. Their unique recipe should be designed to take full advantage of Agile practices and principles. Agile teams can implement Scrum with XP or Lean practices very effectively. They can organize around a Feature Driven Development division of the backlog or a DSDM process segregating pre-project planning from development from post-development phases. They could adopt preferred development practices within the Scrum framework. Or organize around a Lean value driven approach. The point is to choose something, practice it, and make it as good as possible.
A final note regarding our teams: There are many reasons for project failure, but lowest among them (less than 5% of the time according to the Standish group research) is due to lack of capability of the team. Remember or realize rather, that these teams are usually comprised of very talented, motivated, educated and experienced people. The reality is that regardless of methodology or practices, these people will usually find a way to get something done.
Regardless of which custom recipe for agile that is used, the successful teams will still follow the pattern of Agile planning and preparation becoming predictable, focused, driven and productive.