In this post I would like to explore more of the Agile Manifesto and how it relates to software development and to delve into some of the reasoning behind why PureCM was designed and built the way it is.
Individual interactions over processes and tools. A cynic might look at this and say this means there is no need for software tools, but that's the point at all. Software tools are helpful and in many cases necessary but your tools should not define your process and you shouldn't be overly dependent on tools for communication. In Agile the right process is the one that works and over time teams might be changing, tweaking, rearranging process to find what works.
In order for an SCM system to be effective in this type of environment in needs to be flexible and adapt to the process instead of imposing process. The right tool is the one that works for you. I want to mention a long time complaint I have had with several SCM systems that impose process either intentionally or through lack of capability. For example AccuRev is a system where mainline development as an intentional strategy is not supported and Perforce, VSS, CVS only mainline development as a strategy is supported (generally speaking) due to lack of capability.
PureCM has the ability to do basic mainline or complex branch heavy development strategies with any number of combinations in between due to not having a locked workflow and while also having strong capabilities which allow users to adapt PureCM to their process and not the other way around. Change is continuous in the agile flavors and unless it's not practical to think one could go out and buy a whole new set of tools after each tweak to the process, so having tools that can adapt with the right amount of configurability (built in options) is important.
Working software over comprehensive documentation. This entry in the manifesto is a cross-hairs pointed squarely at the waterfall process where every feature and function is documented in great detail before a project even begins. This approach has many pitfalls but in brief what you end up doing is either wasting a ton of time documenting features that never get built (for whatever reason) or adhere so strictly to the original documentation that you lose all ability to adjust to changing market/customer/technology demands over time.
PureCM has adopted a strategy to manage metadata information at the most minimal levels but I will detail this with when I get into Scrum, in short the PureCM task can be reduced to a one-sentence entry and expanded upon over time, detail increases as priority increases so you only spend time documenting features with a high probability of going into development.
Customer collaboration over contract negotiation. Here is part of the manifesto that puts emphasis on including the customer or the key stake holders in the software development process. This can take on different forms in practice from user acceptance testing by the customer, or demo of new features after increments.
PureCM can be a facilitator to this process but it depends on how collaboration is defined and adapted by the team, I will provide several examples once we are Scrumming.
Responding to change over following a plan. Another pitfall of the waterfall process. A lot of software teams might spend months or years working on a project using the original requirements documentation approved by the customer only to find at the end of it all the customer was not happy with the result or conditions in the market had changed enough to make features obsolete before they were even released. With the Scrum adaptation instead of planning out an entire project and a year's worth of effort in advance you plan out short increments called Sprints and this allows priorities to shift in short time to meet the changing demands of the customer.
With PureCM it is possible to actually manage your software development effort by sprints and I will get into greater detail in forthcoming posts so stay tuned!