| Main Entry: | agile [aj-uhl, -ahyl] |
| Part of Speech: | adjective |
| Definition: | physically or mentally nimble, deft |
| Synonyms: | active, acute, alert, athletic, brisk, buoyant, bustling, clever, dexterous, easy-moving, energetic, fleet, frisky, limber, lithe, lively, mercurial, prompt, quick, quick on the draw, quick on the trigger, quick-witted, rapid, ready, sharp, spirited, sportive, spright, sprightly, spry, stirring, supple, swift, twinkle toes, vigorous, vivacious, winged, zippy |
| Antonyms: | brittle, clumsy, stiff |
(entry provided by http://thesaurus.com)
Essentially, if you are considered agile, you are active, clever, sharp & quick. But Agile development isn’t something you can wrap your brain around & master quickly, as the definition of agile clearly implies. It takes time to master. Nor is Agile a collection of methods that have worked for many groups successfully. However, Agile should be treated as a set of tools, not necessarily a set of rules. One needs to be confident using the appropriate Agile tools without leaving out vital and core aspects that make Agile work efficiently. This is where Agile issues begin, end, and ultimately fail.
Agile was born from the concepts of Extreme Programming (XP), which defined a set of specific practices to be followed as a discrete ‘system‘ for tackling the unavoidable change that is inherent to any development endeavor. Many organizations were either unable to swallow such a massive pill, or failed drastically attempting to pull it off. Making certain every single rule is followed exactly can be time-consuming and frustrating. But if you educate yourself and fully understand your options, agile engineering practices can actually pay for themselves long-term. Rebranding XP as Agile, including some refinement of the underlying goals, has made Agile more palatable. Although, there still exists significant fear from developers and management that Agile is still a huge paradigm shift.
Atomic has helped several companies make tremendous strides away from the Waterfall Model of development into a more Agile-ish system. The key to most of the success stories is not necessarily Agile itself, but application of the Scientific Method (restated for fun)
- Identify a problematic area
- Devise a plan to address it
- Give it a shot
- Analyze the results (what worked, what didn’t)
- Do it again! And again… rinse, repeat…
Being agile doesn’t earn you a badge or certificate.
Being agile is about continuously taking the best guess at what to do, learning and building from it. Being agile means you have to recognize, accept and learn from the failures.
Don’t toss anything aside because it ‘didn’t work.‘
Failures, when used wisely, often lead to our greatest successes.
Should developers give up on Agile because it contains a challenging set of standards that can’t be mastered overnight? Since everyone is looking for the quick-and-easy-fix these days, developers may find Agile too difficult and run back to Scrum with their tail between their legs. I find that disheartening. If we give up on challenges, such as mastering Agile, how can one advance within this fast-paced world of software development?
Agile needs to be seen beyond a set of tools, instead of a discrete way of doing things. There is never a silver bullet, but there are infinite opportunities. The quest for excellence is never over, and hopefully that is what keeps us going…
Although the tech-side of this post is mostly pops & buzzers to me… I think everyone can relate to attempting to be agile in some way, shape or form. Great concept, and nice post, Greg!
[…] Practicing ‘Agile’ Doesn’t Necessarily Make You ‘agile’ […]