Overview
Back in 2001 when a group of 17 CTO’s came together to discuss an alternative to documentation driven, heavyweight software development processes, Agile was born. Agile is a software development technique based on iterative and incremental development, in which requirements and their solutions continuously evolve via collaboration amongst self-organizing, cross-functional teams. The Agile Manifesto, introduced in 2001, places more emphasis on individuals and interactions rather than processes and tools.
As it happens with any new concept, Agile was misinterpreted as not requiring any tools at all, or as focused only on inclusive modeling using simple tools such as whiteboards and paper. Yes, both whiteboard and paper would constitute one of the most basic tools in Agile and if used correctly, can be very effective for a small Agile team in a location. However, in today’s connected world, “Remote-Team” is, but a mere term. Agile or not, today teams/projects are connected to their counterparts in various parts of the world and it becomes mana-de-rigueur to use sophisticated tools to increase collaboration and transparency.
I had the experience of working in a Distributed Scrum team spread across the US and India, and our team extensively used efficient Agile tools to run the day to day activities of the project. However, this was not always the case. One major advantage we had on our side was that the stakeholders were Scrum evangelists and were focused on breaking the traditional waterfall mould. In this blog, I plan to discuss these phases and a couple of tools which kept our project ticking.
Prior to using tools for Scrum
When a new tool comes aboard a project, it does make life easier for all stakeholders, especially in a distributed Scrum. In the early days, it used to be quite cumbersome for both the US and Indian team members. The project was driven primarily from the US where a majority of the stakeholders, including the ScrumMaster, were present. The Indian team would then go for a “Sprint Planning Meeting” and break down the user stories which the ScrumMaster would then put up on the Scrum Board. The Indian team then picked up the stories and the ScrumMaster would move the cards around the board.
After the Daily Scrum Meeting, team members would inform the ScrumMaster of the remaining hours and he would update the burn down charts. Naturally, this couldn’t go on for long without people getting burned out in the process and eventually diving back head-on into the waterfall. So the ScrumMaster decided to introduce Scrum tools to help the sprints gallop at a good pace.
Enter ScrumWorks , CruiseControl and Perforce . Notably, it was also decided to follow Scrum during integration of these tools. A separate infrastructure team was set up with their own sprints to integrate these tools into the mainstream project.
ScrumWorks
ScrumWorks Pro is used for all day to day activities in a project. The tool is hosted on a server and hence, is accessible over the Internet. The PO defines the product backlog as per the priority and during the sprint planning meeting, the team picks up the stories and moves them to the sprint backlog.
A screenshot of the backlog window in ScrumWorks Pro is shown below.
If you observe the above figure, the Product Backlog window fills the main screen once a Product has been opened or created. It allows you to edit, prioritize, and schedule your work.
Higher priority work appears higher on the list than lower priority work. You can reprioritize and schedule your work by dragging and dropping backlog items, tasks, and releases.
The left pane represents Sprints (typically 4-week iterations) in chronological order. The right pane represents “uncommitted” (unscheduled) work, optionally organized into “releases”. You can also use the “release” feature to group related backlog items.
The tabs on the left pane display the teams that are working on the open product. Once the sprint is planned, the team updates the remaining hours on the stories after the daily scrum meeting. This lets the stakeholders see the progress on the burn down chart during every sprint.
A sample screenshot of a sprint chart is shown below.
Sprint chart
To highlight any impediments during the sprint, we used the Impediments window (shown below) to report all issues. The ScrumMaster tracks the impediments from this window.
ScrumWorks - Impediments
Complete Setup
We had various dedicated environments for our project – development, integration, QA, staging and finally production. Our Enterprise version product was related to the Supply Chain Management domain with a wide user base. With teams distributed across the US and India, we required a Software Configuration Management System which could support this work model. Perforce supported our iterative model and fit into our system. To start with, it had an easy GUI, was very flexible and allowed us to create private branches from the main trunk when required. We could also run automated tests against a specific branch. The merging was handled by Perforce with color coded indication of the changes. It also seamlessly integrated with our Visual Studio IDE which made check-in/check-out very easy.
With Perforce in place as the Change Management System, we hooked up CruiseControl as our big melting pot Integration Server. CruiseControl for .Net, or CCNet as it is popularly known, is an automated integration server. The server automates the integration process by monitoring the Perforce source control repository directly. Once developers check-in any code in Perforce, CruiseControl picks up the newly modified files and its associated components and creates a new build on the Integration server. When the build is complete, the server notifies the developer whether the changes that they committed integrated successfully or not. Using automated integration guarantees that the integration build will be completed.
The quality team would then deploy the successful builds on their environments and run a full set of functional and regression tests before certifying it for Staging and Production.
These tools helped both the US and Indian team members to effectively manage themselves. Once the team started using ScrumWorks, they did not have to depend on their US counterparts to access the sprint backlog as well as update the progress during the sprints. The stakeholders could also review the project progress any time.
The combination of following Scrum and using compatible tools has made this project a great success!
