I have been wrestling with how the concepts of “agile development” work in smaller software projects. Agile refers to a range of newer methodologies for planning, designing and implementing new web and data systems that include themes like these:
- Designing and working in short phases, or iterations, of the desired end system.
- Getting one set of new software features into full use and then moving on to the next
- Not overreaching your budget or schedule in what you seek to accomplish at any given moment
- Working in small self-organizing teams that include a client rep as well as developers and that meet regularly and work in person to the extent possible.
- Focusing on getting software working and in use rather than on extensive documentation and planning.
We have been working through our own adaption of agile for Drupal projects where we see factors that favor it:
- The client generally can’t predict exactly what they are going to need until they start using the software. Requirements change as new web and data systems get used.
- Except in large businesses or organizations, the client team may be weighted toward folks with little experience in serious software design and who need time and training to work effectively.
If these problems sound familiar, you might do some more reading. Here are some good starting points:
The original “Agile Manifesto”:
http://www.agilemanifesto.org Wikipedia article Extreme programming flavor of agile
http://martinfowler.com/articles/newMethodology.html You can find a lot more starting here, including lots of books by the Agile Manifesto authors. A lot of what is written out there is kind of abstract and geared toward software professionals already familiar with the issues. In fact, we see two types of problems in trying to adapt and stick with agile methodologies.
- The frameworks often seem too rigid to use in smaller projects where the client-consultant team is new to working with each other. After reading a bunch of books and web articles about it, I sometimes think that agile advocates need to become a bit more agile in their advocacy. It should be easier to implement agile itself in short agile phases or iterations and easier to adapt to small teams and small budgets.
- The other problem arises in grant-funded technology projects or similar situations. Organizations (and businesses, for that matter) may have a modest annual budget for software support and enhancement and then have to wait a long time for funding to do something new and strategic. When that happens, it may be an all or nothing situation: get everything pre-approved and documented in detail in advanced and done and in use in one cycle. You wait and you get one pass at the funding. This framework also runs smack into the agile point of view.
What can one do about these things?
First, if you are beginning a new software selection and implementation cycle, bring “agile” into the evaluation criteria for software or consultants you are considering. Ask how whichever of the ideas that sound useful apply, and learn from the process.
Second, there is a lot of room and need for educating funders, whether internal or external, on these matters. It would be great to have an extended dialog about how more agile-aware grant-funding could better support technology-infused projects.
Third, developers need to find more popular ways to discuss these concepts. I’ll end with one neat coincidence I have been thinking about. Agile software development is a lot like what we call the 70% rule in the style of Tai Chi I do.
If you have ever done Tai Chi, you may have experienced guidelines that say never aim to learn everything you can or to progress at your full capacity. In the school I go to, this is expressed as the "70% Rule." Make an estimate of your 100% goal level, and then shoot for 70% of that. If you are just getting started or recovering from an injury, reduce to 60%, 50% or less. You aim to achieve what you can comfortably achieve, get used to that. You soon find that your 100% mark has moved up, and therefore you have a new 70% level to work at.
Tai Chi’s Taoist classics have perspectives from which this rule emerges. For example, the Tao de Ching has a passage that says,
Everyone in the world knows that when the beautiful strives to be beautiful, it is repulsive.Everyone knows that when the good strives to be good, it is no good.(See more like this on
the Energy Arts web site. )
Clients and developers alike frequently have trouble wrapping their minds around such a perspective in software. The pursuit of perfection, of not just 100% of capacity, but 110 or more, is common, whether it’s in the desired features, data conversion or other factors. From trying to satisfy everyone and everything, things get messy and problematic on the fringes.
If you go to 100% to make sure the organization gets everything it hoped for, instead of reducing stress, you may increase stress. Instead of building capacity, you may do damage to staff and developer patience and commitment. Instead of adding resources, you scatter attention.
I’ve been thinking that the 70% rule could offer kind of a corollary to agile development. I’m planning to try it as a more accessible way to get at the same concepts. Keep the long term goals of perfect organizational growth, improved workflow, strenuous contact and program management. Then figure out what the organization can truly absorb right now, and back off to what it would mean to achieve 70% of that in smooth, effortless adoption. Implement that much, get used to it, evaluate it, then set a new higher set of goals, and plan to achieve 70% of that new mark.
Maybe you have experienced some other way to introduce these concepts you'd like to share.
[1]
[2]