What Can We Learn from Agile Software Development Projects?
A couple of years ago I was exposed to “agile” software development processes. My interest was heightened when I read an article comparing something I was familiar with, i.e., lean maufacturing, to agile methods. Agile methods include focusing on value (vs. cost), frequent testing that drives innovation, and extreme collaboration between the customer and developer.
What is fascinating about agile methods is that they appear to be a recipe for disaster and cost overruns due to their focus on innovation. Done correctly they often pave the way for extremely valuable innovations that were never considered in the original specification. The process enables innovation as long as it is valuable. I admit to being a novice about agile software development but know enough to see the fantastic potential of these approaches due to my exposure to lean and theory of constraints. Remarkably, neither lean, theory of constraints or agile approaches are intuitive; in other words, they require education, proof and actual experience to overcome the barriers to adoption.
Recent comment trading with the blog ActiveEngine reawakened my interest in agile and how it applies to processes other than software development. Anyone who wants to completely change how they think about software development and other business processes should subscribe to this blog.
Tags: Agile Software Development, collaboration, execute-strategy, executive, governance-board, innovation, investment, lean, PMO, portfolio-management, project, project-management, project-management-office, project-portfolio-management, selling-projects, software-development, strategy, theory-of-constraints, value, value-sellingRelated Stories
POSTED IN: Best of the Best Practices
1 opinion for What Can We Learn from Agile Software Development Projects?
ActiveEngine Sensei
Nov 21, 2007 at 5:58 pm
Thanks for link. I look forward to funneling traffic, comments, and links your way as well.
As I have mentioned earlier, I am on the quest to shorten communication cycles between business units. As you have gathered from my tone in my posts, I am not a fan of how software developers have isolated themselves from the business community. Developers need to unlearn all their quirky - and snarky - vocabulary and learn the language of the problem domain that their customers use.
Have an opinion? Leave a comment: