In the last 14 years, I had seen myself moving from waterfall methodology of software development to Iterative and then to Scrum and finally to Scrum-ban. I will explain a bit about the different methodologies and then move to Scrum Process. Below is the pictorial representation of the Waterfall, Iterative and Scrum software development process. More info about Kanban and Scrum-ban will be posted in my upcoming blogs. In this article, i would like to demo on how to use the Microsoft Visual Studio Scrum 1.0, process template built specifically for Scrum teams
Picture 1: Pictorial representation of Waterfall, Iterative and Scrum Software Development methodologies.
The waterfall approach is highly risky, often more costly and generally less efficient than more Agile approaches. It requires the creation of up-front documentation before any real business value is created. i.e. You don’t realize any value until the end of the project. This is confounded by the fact that product development is started downstream, or much later in the project’s expected timeframe. This has the obvious disadvantage of delaying the point at which business value can be realized.
Remember the 80-20 rule, 80% of a product’s value comes from 20% of its features. With this in mind, can we conceivably build a software product that provides 20% of the feature set? Yes, We can deliver "version 1" with 20% of the features, then, a little later, "version 2" with a further collection of features and later "version 3". The beauty of this approach is that development of 20% of the features should not take 100% of the project’s expected schedule and budget: we can realize business value much earlier in the cycle.
Iterative Waterfall Development focuses on delivering a sprint of work as opposed to a series of valuable/shippable features. In my experience, The most commonly occurring issue in this type of process is you deliver loads of code and leave it until the last minute to test everything. One issue takes longer than expected to resolve, you miss your sprint deadline and you deliver nothing. Another common symptom of this type of approach is over-commitment. It’s really difficult to estimate the total effort associated with a particular User Story/Feature when approaching delivery in this phased way. You’re more or less forced to estimate each phase separately (e.g. estimate development separately to testing in this instance) – this doesn’t work as the phases are not separate, they’re totally intertwined. For example, if you find an issue with the test, you must return to development. The whole team must remain focused on delivering the end goal, not the separate phases. It’s also worth noting that velocity and burn downs are far less (if at all) useful in this type of environment – you don’t benefit from early-warning-signs as you don’t find out whether you’re on track until the end of the sprint.
Scrum Development focuses on delivering fully-tested, independent, valuable, small features. As such, we diversify our risk – if one feature goes wrong, it should not impact another feature. With that said, we still plan our work in iterations and we will still release at the end of each iteration.
For Example, if we run two projects for identical requirements, same time period (For ex: say 1 year) with same team, but one in waterfall Software development process and another in scrum. Assuming you know how scrum and waterfall both work, if you look at the project delivery after 6 months, it would be very interesting output. In the 6 months, the waterfall project might have reached a stage where the requirement analysis is fully complete, design is complete, programming has started and half way through. If I am a customer, how much business value this stage would give me, think about it? At the same time, the scrum project team would have against prioritized product backlog and started delivering shippable product after every sprint (say of 4 scrum cycles every 2 month). Scrum focuses on shippable product in small iterations, and that not only gives the best business value at certain moment in project life cycle but also allows change during the development process that can be taken up in future sprints.
Microsoft Visual Studio Scrum 1.0 Process Template
Last week, Microsoft announced Microsoft Visual Studio Scrum 1.0, a process template built from the ground up specifically for Scrum teams. Below is the step by step guide to Downloading, Installing and setting up the Scrum process for the Project Teams.
Step 1: Downloading the Microsoft Visual Studio Scrum 1.0 Process Template:
There are two ways to download the template.
Option 1: Download from the link Microsoft Visual Studio Scrum 1.0 from the Visual Studio Gallery
Option 2: Download Microsoft Visual Studio Scrum 1.0 using Visual Studio 2010 using the following steps.
Open VS 2010
On the Tools menu, click Extension Manager.
In Extension Manager, in the left pane, click Online Gallery.
In Online Gallery, click on Tools and select Process Templates
- In the right pane, Select Microsoft Visual Studio Scrum 1.0 and click on the Download button.
- This will download the Microsoft_Visual_Studio_Scrum_1.0.MSI to the location you select in the download dialog.
- Click on the Microsoft_Visual_Studio_Scrum_1.0.MSI file to start the installation.
- The MSI installs the required files to the location (default) C:\Program Files (x86)\Microsoft\Microsoft Visual Studio Scrum 1.0. (I am running Windows 7, 64 bit OS)
Step 2: Launch the Process Template Explorer in Visual Studio 2010
If you already have a connection to the Team Foundation Server, please ignore the Steps A to D and go to Step 1.
Prerequisite: The following process requires a connection to a Team Foundation Server. In my scenario, i Installed Microsoft Team Foundation Server 2010 locally on Windows 7 PC. Below are the steps to connect to a Team Foundation Server (team project collection).
Step A. In Visual Studio, on the Tools menu, click Connect to Team Foundation Server.
If you do not see this option, you have not installed Team Explorer. You must install Team Explorer before you will have the option to connect to Team Foundation Server.
Step B. In the Connect to Team Project dialog box, in the Select a Team Foundation Server drop-down list, click the server that contains the team project collection to which you want to add your team project.
If the drop-down list is empty, click the Servers button to manually enter the server connection settings. Contact your Team Foundation administrator or team project administrator to obtain the connection settings.
Step C. Click the name of the project collection to which you want to add your team project from the Directory list
- In VS 2010, Click on Team menu
- Select Team Project Collection Settings → Process Template Manager. OR in Team Explorer window, right click on the collection, select Team Project Collection Settings → Process Template Manager.
- Click Upload button and select the folder where the Microsoft Visual Studio Scrum 1.0 process template is installed (Default: C:\Program Files (x86)\Microsoft\Microsoft Visual Studio Scrum 1.0\Process Template). Click on Select Folder button.
- Once installed, Click on Make Default button to make it the default process template. The Microsoft Visual Studio Scrum 1.0 should be listed in the Process Template Manager as follows:
Create a Team Project
- In Team Explorer, right-click the project collection, and then click New Team Project. OR open the File menu, point to New, and then click Team Project.
The following tasks are performed automatically:
A SharePoint site for your team project is created.
An empty version-control folder for your team project is created.
To start using the Scrum process, refer to the site http://msdn.microsoft.com/en-us/library/ff731587.aspx