Sun, Mar 14, 2010 1:28 PM
In my last post I mentioned "agile processes".
Being something of a late bloomer, I've begun adopting more the agile practices in recent months, and have been seeing good results: team members are more well coordinated, managers are happy with more visible results, customers are pleased to have features in their hands faster.
In some ways "agile" is simply a cool-sounding label applied to what us old-timers used to call "best practices". But there are some specifics to agile methods that are notable, perhaps chiefly by articulating a common set of principles from which all of our team members can derive specific practices on the fly as ever-changing requirements dictate.
I've worked in companies that were very practice-driven, attempting to reduce the dynamic complexities of development workflows into formulas and flowcharts because some best-selling business book told the owners that it would help them sell their company more easily if they could emphasize processes over people, making the company's value somehow independent of the people who comprise it.
But such process-worship often has the opposite result: it demotivates people, bogging them down with forms and procedures that too often don't reflect the ever-changing needs of the work.
And besides, it doesn't take a psychology doctorate to appreciate the people don't take well to attempts to make them replaceable. It doesn't inspire performance, encourages programmers to keep innovations to themselves, and this key irony isn't lost on them: all those flowcharts and documented Standard Operating Procedures somehow miss defining the owner, the one making the flowcharts, as a process-driven entity no less replaceable. ;)
In contrast, agile methods recognize that work is done by people, that people are the source from which an organization's true value is derived, and attempt to define common principles which inspire individuals to find their own specific practices on the fly as the dynamics of the work at hand require.
Such methods acknowledge that change is the only constant, and embrace change as the itegral driving force it is behind so much of the work people do.
The Agile Manifesto puts this succinctly, and is worth sharing here:
Manifesto for Agile Software Development
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.
Blog Home Filed under: agile best practices
|
Richard Gaskin
Ambassador, Fourth World
Netbook market on the rise
RunRev Complies with Jobs' Request, Moves Toward Android
Apple Snubs OS X at WWDC
Moment of Zen
Apple's new SDK license locks iPhone out of the HLL revolution
Scripting Style Guide Updated
Agile Manifesto
Bugs in Rev: a little perspective
New Rev-centric Linux Distro
Crystal ball time
Too tall to live, too weird to die
Oracle, Sun, and the future of MySQL
RevWeb security warnings: use sparingly
Installers making a comeback on Mac?
"Rev Message Path" article updated
Your Windows 7 Launch Party
Smartphone competition - at last
Benchmarking performance
New Interviews at revJournal: Jerry and Andre
Windows 7 HIG: time to say goodbye to XP?
agile (1)
Apple weirdness (2)
best practices (2)
community (1)
databases (1)
fluff (2)
games (2)
HyperCard (1)
iPad (3)
iPhone (1)
irony (1)
linux (1)
marketing (6)
mobile (1)
netbooks (1)
performance (1)
predictions (1)
rant (2)
RevMobile (1)
RunRev FAQ (5)
scripting style (1)
server (1)
UI (1)
usability (6)
RunRev.com
Sarah's Rev Blog
Björnke's Stacks Blog
theWorcesterSource
Releasable Rev Blog
RevEditor (tRev) Blog
Chipp Walters 'Rev Blog
WeCode Planet
|
