Wednesday, October 03, 2007

Some other kanban activity

Scott Miller has been blogging about using kanban board in software development and how he went about designing his board.

Meanwhile, Business Lean blog has some advice on the trade off between an electronic kanban system versus a manual system. As many of you know I addressed these issues myself with the Sticky Buddy scheme and the Digital White Board. Technorati tag: Agile, Software+Engineering, David+Anderson, Lean, Kanban

Team Frustration Server

I thought I’d continue my short series on first year job frustrations, with my thoughts on Team Foundation Server and MSF. [At the severe risk of upsetting a bunch of my buddies across the lake in Redmond. ]

TFS has been an agent of change for me. But implementing it was painful. It comes with so much inertia that the team struggled for 5 months prior to my arrival and got nowhere. When I arrived I put some management weight behind it and supported the rollout with resources and political capital. In addition, I focused the efforts of my own direct line management team, by announcing that our first operations review would be held in December and therefore, we needed TFS in place by November 1st in order to have data to present. That gave us three months to complete the rollout. Using a date as a forcing factor really focused folks attention and the work got done. But, think about it - 3 months to roll out version control, work item tracking and reporting! That’s a long time and major management investment. For me it was one of my major “First 90 Days” initiatives.

Since then TFS has become an essential part of how we do our day-to-day work. We also use the TeamLook plug-in for Outlook and the former TeamPlain web client access now available from Microsoft directly. We have well over 100 users on the system. In fact so many non-technology folks now have access that I’d don’t actually know precise numbers. We have vendors using the system and storing their work items and test cases on our servers. We’ve developed a replacement user interface that simulates our kanban white boards. And that user interface has become the client of choice for many of the technology folks working on projects. I hear people refer to “Digital White Board” far more often than I hear “TFS” when I attend stand-up meetings. TFS has become part of the fabric of how we engineer software. [And now… here it is… drum roll please…] But…

Maintaining and supporting TFS has proven hugely expensive for us. We’ve had to invest heavily. While we value the investment - the team lives and breaths on the utility it provides - for an IT shop of our size the investment is non-trivial. We’ve had to invest in supporting work item type definition and process template customization, and in configuration management and Team Build expertise, but most of all we’ve had to invest in report authoring. Currently we have probably 3 headcount dedicated to TFS - one on reports, one on process templates and one on build and config management. Each of those folks but especially the process template and report guys have a long backlog of work.

TFS just isn’t a very agile tool and it doesn’t support so well, the kind of agile/Lean environment and culture, that I’ve built at Corbis. We find that our highly empowered teams are making process changes weekly. Kaizen events that change a process happen too often for a middle-manager like me to keep up with them all. Each time a process change is implemented, there is a work order generated for TFS changes - any change to a work item type definition creates a knock-on change to reports. It can be 4 to 6 weeks later before the electronic system catches up with the manually maintained system. This can lead to incorrect reporting and other funky side-effects in reporting.

We are also not using the out-of-the-box MSF process templates - though we do tend to customize from the MSF CMMI template by default. We like the CMMI template because it comes with an Issue work item type and a “proposed” state in many of the WIT definitions that easily enables our triage process. We almost always customize the work item type definitions and consequently break all the out-of-the-box reports. This causes inertia getting new projects spun up and tracked electronically.

We’ve also found that we have to abandon the MDX authored reports as we are unable to maintain them. We can’t afford to train a developer on MDX. This is a pity because some of the more valuable out-of-the-box reports (read some of the more powerful and complex) are authored in MDX.

We’ve also found TFS to be a lousy tool for continuous integration and we’ve had to abandon it and go with Cruise Control.

We’ve also abandoned the use of the MSF process guidance templates and we use our own custom developed Sharepoint wiki for process guidance. While some tooling has appeared from Microsoft as unsupported Power Toy releases allowing editing of process guidance after a Team Project is deployed, it came too late for us. We’d already committed to Sharepoint. The editing and support experience is nicer too. We’ve been able to open our process guidance up as a wiki where everyone on the team can provide edits. This means we can keep guidance up-to-date with process changes as kaizen events happen. If we were stuck with the XML of MSF then we’d probably have dedicated technical writing resources who’d have a 6 to 8 week backlog of process guidance changes to update.

While TFS continues to be a drain on our resources, and a ball that we drag on a chain slowing our progress, we really couldn’t live without it. It’s power and flexibility is unchallenged in the .Net space and possibly in the entire market. We’ve been able to develop innovative agile/Lean process solutions and put in place innovative reporting methods to provide feedback and management reporting. Powerful but niche products such as Rally, VersionOne, or FDD Tracker might be easier to use, require less resources, provide better and more powerful out-of-the-box reports but they don’t offer the flexibility and programmability and integration with version control, build and test that TFS can offer. TFS truly has been the enabler of our Lean solution, our Kaizen culture and our Kanban process for development scheduling and prioritization.

So we will continue to invest in TFS and it will continue to be mission critical for us. We have some advantages that we have very close links with Microsoft and we can use that influence to provide feedback and target the future direction of the product. However, as many of you will be aware the release cycle remains painfully slow. The interim Orcas release is delayed until next year and it remains to be seen when we get Rosario. Unfortunately the fix for many of the flexibility issues we have with WITDs, reports, process guidance and process definition probably won’t appear until the one after that, if at all. So I know I need to continue to budget for three people to maintain TFS for at least the next 4 years. This cost is justified as long as we continue to get the productivity gains we’ve seen. But my conclusion is that a full-blown TFS implementation like ours is not for the faint of heart. Go there at your peril!

Related posts: First Year Frustrations, One Year Anniversary, My Approach at Corbis, Digital White Board Technorati tag: TFS, VSTS, MSF, Team+Foundation+Server, Visual+Studio, Microsoft, Lean, TeamLook, Personify+Design, Software+Engineering