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!
Let's get this Agile Version Control (AVC) series started with a little discussion...
It is important right off the bat to look at the definition of Agile versus the definition of Scrum. We'll talk about Agile and Scrum (and even more things) later on, so it's worth looking at these in more detail.
Agile itself is not a specific way of working, it is generic set of principles or priorities which are outlined in the Agile Manifesto. These are listed as:
- Individual interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
In brief, this is Agile. There are a dozen or so additional principles you can add on that are important, like self-organizing teams, sustainable working pace, but these are also covered in the individual Agile flavors so not as important to list here as I can get into those details later.
Scrum is a specific flavor of Agile, specifically it is referred to as an agile project management framework. It draws on the principles of the Agile Manifesto but goes into detail to define day-to-day activities and how to manage a project in a specific way.
Agile is not about just having daily standup meetings or deciding to swap one feature for another during a development cycle based on customer demands. These actions do exist in Scrum but you are not scrumming if you just have daily standup meetings, there is a lot more to Scrum and perhaps the most important aspect is how teams are managed and organized, in short they manage and organize themselves, there is no project or product manager anymore and teams are empowered to make decisions and solve problems on their own as opposed to being micromanaged. It is the first thing I noticed about Scrum.
..but why is this important?
Because in the design and construction of PureCM there are facets of the product which will mesh with principles of Agile and will therefore be applicable to many different flavors of Agile, but because my flavor of choice is Scrum that is where I will go into details (though I will try to mention others here and there).
There is a vast multitude of SCM and version control systems available today. Many of them will claim to be Agile. Many of these will cite specific features or points of interest like code reviews and continuous integration. Often these are features the tools had before claiming to be agile but are now being marketed as 'Agile' capabilities retroactively. With PureCM what we will show is how you can follow the principles of the Agile Manifesto first and then second how nicely PureCM adapts to Scrum and how this is a ground up effort that makes PureCM truly Agile and Scrum compatible and not just offering rebranded legacy features here and there and calling it agile.
So we've properly started the series - I look forward to continuing our journey!