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?"
managers, including software managers, can learn from theatre, and in Computers as Theatre
Brenda Laurel discusses what interaction designers can learn from theatre.
3 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.
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.
Lets Hang!