MSF for Agile Software Development
While there are many different types of Agile implementations I think using MSF for Agile or Scrum is ideal. Before going to deep into both of those methodologies let’s start with what is “conventional software development” (CSD). CSD typically freezes the requirements before design, forbids coding prior to a detailed design review, plans everything early with high fidelity and controls the source code baselines rigorously. While on the surface this appears to be a good approach, companies have learned to depart from the typical “waterfall” method of developing software and become more agile. Yes, the former methodology is still used and I will concede with success but clearly improvements have been made since its introduction.
Challenges in Conventional Software Development
The benefits for using these (and other) types of software methodologies are easily visible once you look at the problems seen while using in CSD. Some of these are misinterpreted or incomplete requirements, defects found by customers, late delivery/delays, subpar application quality/broken builds and the focus being on the existence of documentation rather than its content or quality. These are but a few of the challenges that are faced when using CSD.
Agile Development
This is where Agile development comes in. The Agile Manifesto outlines better ways of developing software by doing it and helping others do it. Instead of placing the value on processes, tools and documentation (though important), using the Agile methodology places value on individuals, interactions and working software. While the former is most certainly needed, the way in which it’s prioritized in the latter is the difference.
Getting Started with Agile
Most IT professionals who try to sell the business or their senior leadership team on the idea of adopting this type of methodology fail not because they don't understand what Agile is (although that’s entirely possible) but rather they start with a project that has a complex architecture as well as spanning business domains. Instead of going this route my suggestion is to carefully select the right project as a pilot and choose the right team. The "right team" should encompass experienced developers/testers and if need be a project manager (PM) and a business analyst (BA). Leveraging these skillsets will help in the implementation and enforcemenet of the usage of automation for testing purposes and will lead to the incorporation of lessons learned from past successful and failed projects. The key take away here is to start small, eliminate any roadblocks and not only deliver a value-add to the business but also show that it was done under budget and in a shorter timeframe.
Scrum
Agile in and of itself is not an all-inclusive system to develop software but rather provides a generic framework which can be extended. One such implementation is Scrum. This methodology offers good governance, controls and organization for mitigating risk. It’s well-documented, popular and simple to use which is great for those new to iterative development practices. Not to mention that there is no shortage of industry guidance readily available.
Summary
Traditional software development has its issues and limitations which is why companies are embracing Agile development. Agile development solves the traditional development problems and can be scaled accordingly. Using technology makes agility even better and that helps bridge the gap from developers to project managers. Transparency is at the core and that means everyone on the team is aware of what has been completed and what lies ahead.
In my next blog post I’ll discuss “things to avoid” and “things to accomplish” along with the technology to support Agile development using Visual Studio (VS) and Team Foundation Server (TFS).