Agility (and Learning Opportunities) Everywhere

[article]
Summary:

People often ask, "Can I apply agile methods to something other than software development?" Since the basic appeal of agile methods is to acknowledge uncertainty by planning in increments, evaluating where you are relative to the plan and other forces, and planning the next increment, it seems like there should be no obstacle to following an agile approach for any project. The lurking question many have is, "Can my type of project really be structured in an incremental way?"

 
 

People often ask, "Can I apply agile methods to something other than software development?" Since the basic appeal of agile methods is to acknowledge uncertainty by planning in increments, evaluating where you are relative to the plan and other forces, and planning the next increment, it seems like there should be no obstacle to following an agile approach for any project. The lurking question many have is, "Can my type of project really be structured in an incremental way?"

 
While in general, I tend to believe that the answer is "yes," it's always good to have examples. So I was intrigued to head a segment on the radio show Living On Earth, where the rapper Baba Brinkmann described his approach to developing The Rap Guide to Evolution as "Performance, Feedback, Revision," which is a very concise way to describe an agile approach. This meta-aspect of this also intrigued me, as Brinkman used the performance, feedback, revision theme in the evolution rap as well.
 
This is also another reminder of how software developers can learn much from many seemingly unrelated domains. As Rob Austin and Lee Devin explore in Artful Making: What Managers Need to Know About How Artists Work managers, including software managers, can learn from theatre, and in Computers as Theatre Brenda Laurel discusses what interaction designers can learn from theatre.

So, yes, you can be agile if you are doing something other than software, and if you are developing software you can learn how to build software better by looking at other disciplines.

User Comments

4 comments
Anonymous's picture
Anonymous

Interesting that the examples from outside of software are from the arts. Nothing wrong with that, but it does highlight that software has not yet moved beyond (at best) craft level. Perhaps we tried to get to engineering too fast with BDUF and waterfall, and this is a necessary stage to go through.

January 20, 2012 - 7:12am
Steve Berczuk's picture

Whether people who build software are practicing engineering or art/craft seems situational to me. Similarly, what "Computer Science" is and whether you want someone with a CS degree building software as opposed to someone with a traditional engineering background who can program. Dick Gabriel, Computer Scientist, Poet, and author of good software has advocated for an MFA program in computer science.

I think that the more interesting to acknowledge that building things for people (whether is software or hardware) might be more art and social activity than people acknowledge.

Whether we are at "engineering" is a good question. But I think that there is a spectrum. Electrical Engineers can work at the craft level too. For example, when my friend builds a sensor for measuring temps in his home heating system, is he practicing engineering? or Craft? He's using the same tools as he does at work. But I think that you are on to something when you say what I think you are saying: that trying to impose formal, complicated processes in an attempt to get to "engineering" might have downsides.

January 20, 2012 - 9:10am
Anonymous's picture
Anonymous

I wasn't sure whether to reply here or in your later post, but this seems closer. Yes, you summarized my thoughts quite well in your last sentence.
There is a tendency to look at successful people, disciplines, organizations, etc. and assume that what they do is how they became successful, whereas it may be a consequence of what they need to do having become successful - or actually completely irrelevant. So many people forget that correlation is not causation.
In your other post, you mentioned your friend saying something about engineers measuring. Perhaps more important, they have something to measure. I sometimes say that software doesn't have anything like the concept of strength that occurs in all engineering disciplines in varying forms (fairly obvious for mechanical engineering, for electrical it could be current carrying capacity, breakdown voltage, etc.).
Art and craft tell you what to do and how to do it, with some idea of why, science primarily gives you a better idea of the why. Engineering combines all of these, which often leads to changes in the what and how.

January 27, 2012 - 4:29am
Johnny Hermann's picture

"Performance, Feedback, Revision"

That just seems like the basic behaviour of what I would call a "professional".  And, it really is not much more than the Shewhart/Deming Plan-Do-Check-Act cycle, which itself is effectively the Scientific Method.  I would hope that software developers worth their salt would not need any coaching in this area.

September 5, 2014 - 2:43am

About the author

CMCrossroads is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.