This post is from the CollabNet VersionOne blog and has not been updated since the original publish date.
agile Adoption in the Enterprise
In a recent article in Visual Studio Magazine, agile reporter John K. Waters corroborates the growing influence of agile project management practices, citing a keynote presentation from Forrester analyst Dave West at the HP Virtual Conference 2009. According to Waters, West had this to say about the current state of agile:
The movement to Agile is fundamentally changing the way in which organizations build software. In situations where the requirements and the technology are far from understood — where there’s a lack of clarity — processes become more and more complicated. So a traditional approach, which requires planning, can’t possibly work.
This is good news, right? Just more evidence that the industry’s adoption of agile methods has grown because they actually work. However, West went on to explain the trends Forrester in greater detail, which likely worried Scrum purists:
When you ask them in a little bit more detail what that really means—when you pull back the covers—you find that there’s no one particular approach… It might mean Agile-driven approach, but it’s actually a combination or hybrid… This is great news… It shows that developers pick the appropriate tools to solve the right problem, which means that we’re moving away from this rigorous, sequential, defined, documented process to something that’s a little bit more fluid, in direct response to business need.
In West’s mind, organizations mixing and matching techniques and methodologies can be great: It simply means that companies are being very selective about which processes they adopt and making sure that they address the particular business challenges they face.
But for those of us who practice by-the-book Scrum, we know that the key to unlocking Scrum’s myriad benefits is a direct result of operating within the boundaries the framework sketches out. That is, Scrum only includes a handful of roles, meetings, and artifacts. When one is neglected or removed, it impacts the framework’s ability to deliver the benefits it advertises. Additionally, intentionally leaving out the ‘hard stuff’ probably undermines the goal of most Scrum transformations – remember – Scrum is hard and disruptive on purpose.
Additional Reading: Interested in doing research on a Scrum transformation – Danube’s whitepapers can help!
What do you think? If your organization utilizes Scrum, is it combined with other processes or is it used by-the-book? Is this by choice (because you want to) or by force (because of some external dependency)?