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?"
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
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.
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.
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.
"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.