Herding project team cats with team foundation server

“Agile development = making it up as you go along”, right? Wrong, agile projects need careful planning and tracking. As a software development project manager, I’ve experienced various ways of controlling Application Lifecycle Management (ALM). The most recent of these is Team Foundation Server (TFS), an end-to-end ALM tool based on Microsoft Visual Studio. In our Engineering department we have a range of legacy and new product developments, and our build and test environment has evolved over a number of years, using a variety of tools, such as TeamCity and Specflow. Because of this, we needed a way to provide consistent control and reporting across our three engineering locations. Our new VP had seen Team Foundation Server used very successfully in other organisations and wanted to give it a try.
Why is this important? Because we want to run our engineering department using evidence based management – a practice taken from the medical field, which is directly applicable to software development management in the following way: “…while not strictly life threatening, the executive leadership of an organisation is making critical decisions based on the information that they get from their subordinates. If these metrics are not the right ones or totally the wrong ones then you could find a company plunged into a critical state.” – Nakedalm.com
Improved speed, improved delivery
Other organisations have achieved significant benefits from introducing a single, consistent ALM tool. A UK police force saw a large reduction in code returned to development from the testing team (from 15% down to 0%), which improved speed and quality of delivery. It also found that the “…transparency which Agile and TFS provides gives the team more confidence that we are working with realistic expectations which we can stand by in conversations with the customer.” (Source: Dunstan Thomas)
An international publisher found that it achieved improved efficiency and delivery of business initiatives and significant cost savings including the total cost of ownership of the development infrastructure implementing TFS with Agile development. The IT organisation became: “ leaner, quicker and far more efficient”.
Microsoft first launched TFS to support ALM in 2005 and it has been through a number of new versions since then. Its primary aim was to “to produce a set of new technologies and techniques that are geared toward optimizing the process of developing software in teams.” It does this through a three tiered architecture comprising a client tier, and application tier and a data tier. The client tier consists of Microsoft Office products and a simplified UI for project managers (simplified, because we are simple folk). Since its first manifestation, the UI has been developed into a fairly flexible interface, which shows activities and progress by team in a way that is simple enough for project managers and other stakeholders to understand. This sits on top of an integrated platform that all parties involved in the software development process can use. Product Owners can record their requirements as Features, development teams can breakdown their work into stories (Product Backlog Items) and further into Tasks. The tests can be recorded as Test Cases by QA. Code can be stored in Git, built and released via TFS by the Release team. This allows complete end to end traceability and automatically shows teams how fast they are delivering (velocity) and how much they have left to do (burndown rate). So the engineering department can demonstrate to the business how it’s really doing, rather than progress being based on opinion and rumour.
So far, so good, but how easy was it to implement? I managed to start using TFS pretty quickly for setting up the team spaces and backlogs. Training the project teams on how to use the project tracking element was straightforward too. Convincing the project teams that TFS was a step forward was less easy. We already had a number of specialised tools to assist the development process, such as TargetProcess – another product with “boards” showing team activity and progress – which is more flexible when it comes to allocating and moving tasks around. Our build process used TeamCity, had been customised to suit the way of working at the time, with loads of scripts which were not easy to replicate. Our automated testing framework (Specflow) didn’t immediately seem to integrate with the TFS environment and we had a multitude of regression tests which no one felt like rebuilding in another tool.
It was clear that we could not simply switch from the legacy platform to TFS, without disrupting the development teams and giving them a lot of extra infrastructural work, so we decided to learn how to use TFS fully on small, new products which had no legacy to transfer. This plan is working well so far and each new product has a full TFS pipeline. For the legacy products, we initially moved the backlog and progress management to TFS, so every team’s activity is measurable in the same way, and are migrating the build process at a sensible time for each team. We are now at a stage where we can see much better what all the teams are supposed to be working on and how close they are to delivering what is requested. We have evidence of progress, rather than just opinion and rumour.