This year has been such a continuous wave that I am still catching my breath. How do I start?
I had a brief stint with the MSF Team (now called VSTS Process Team) that finished in October 2007. I wanted but couldn’t stay – my family is not yet ready to move from sunny Austin to cloudy Seattle. Maybe in the future. I joined the ALM team in MCS in early December 2007, as it was a natural follow up to the work I was already doing.
With ALM team my first work was on I presenting the talk “Using Key Performance Indicators (KPIs) to streamline development” in December and January of 2008. I also helped in the internal review of the SOX whitepaper.
In January and February I went a lot to the West Coast, both North and South, and was able to meet with a several development teams newly adopting TFS. I couple of them were still getting out of the woods in using waterfall SDLCs. In one of the cases, it was not because they didn’t know about Agile or iterative/incremental software development, but instead the platform and tools they were using imposed a waterfall structure, and not just at a governance level, but at the day to day development activities. What if took you a month and a half to create new build because your product consisted of a 4GL that generated 15K+ (that’s 15 thousand!) DLLs? Unsuitable technology trumps Agility. (For more on that, take a look at Kent Beck’s paper on “Tools for Agility”.)
I also had the opportunity to review and help recover a couple of projects with issues. One of those issues was a lack of understanding that the adoption of better practices in ALM has a cycle of its own. Tie it to a major development project with a different objective, and it will be run over. Choosing a proper pilot for ALM adoption is a major decision that if left to whimsical decisions taken in a tactical mode will derail both projects, the major application development and the ALM process improvement one. This has been by far the biggest cause for failure in adopting newer ALM practices.
In February, right after our internal TechReady event I went to the Netherlands to teach a workshop in MSF Agile and MSF CMMI to Europol. I was impressed by the quality of their development expertise. It doesn’t seem an isolated case but rather similar to other areas of Europe. MSF CMMI adoption seems higher in Europe than in the US. The message that it is possible to apply CMMI to an Agile process has been understood at heart over there.
Meanwhile back in the US I was at a customer helping them develop a customized version of FDD for TFS. FDD was well suited for their process as they were creating a major application framework to be reused by hundreds of other applications. An architectural design cycle fit it like a glove. It also reminded me that given the diversity of the original Agile methodologies, that there is no clear cut answer to process adoption. You make the process work for you. On that I subscribe to Alistair Cockburn’s philosophy of “a process per project team”. It’s the same as in life - living things are not exact copies. They exhibit variances here and there. There is enough to see that they share a common inheritance, but the uniqueness of time, location, team and project makes them individuals with their own identity.
Then in mid-March Ajoy Krishnamurthy called me back to help represent Microsoft at SEPG 2008. For the first time I saw a reversal in a trend I had been observing since 2005: there were many more young faces at the conference. For 3 years while I was covering both the Agile and SEPG conferences I had the following experiences: I would feel old in the Agile one, and young at SEPG (the cynics will say I just got 3 years older, so now everyone seemed younger).
It seems that the renewal approach from SEI has been paying off, and its support to out of the box thinking in connecting Agile and CMMI is also bringing new faces to the table. Among others we had Microsoft’s input with David Anderson’s revolutionary approach in MSF CMMI. At SEPG 2008 I met [again] David Anderson and Hillel Glazer, who would by November last release with other SEPG members a widely circulated paper on Agile and CMMI.
I delved deep for the next 10 months in the deliveries of the ALM team:
It’s been a nice mixture of consulting, training and coaching. A common trend has surfaced from talking to so many different customers in so many different situations:
- Public or semi-public companies currently have their sweet spot for ALM process improvement in adopting TFS as a source control tool, and look forward to implement some sort of Release Management discipline.
- Private companies have implemented TFS as a SCM tool a while ago, and are now moving into adopting TFS to manage their Application Project Portfolio. Aside from the occasional new project, they have a standard set of developed applications that are mostly in maintenance, and need a place to track change requests and bugs. They are almost Agile, but are held back by siloed requirements/change request “phases”. On top of that, there is rarely the concept of a multidisciplinary Agile team, with the same team member fulfilling all conflicting quality goals which leads to a tactical prioritization of customer needs.
- ISVs have a firm grasp of their process, and are primarily concerned about using TFS to achieve more productivity by establishing a Metrics program as part of a wider ALM optimization effort.
This is of course based on just my experience with a few dozen customers, and I can name several exceptions already. This induced perception however has led me to realize that I have had the privilege of getting first hand experience in improving over ALM baselines, at several adoption phases and at different levels of maturity. Having been part in implementing those steps has definitely helped me in assisting other customers as it is now easier to weave them into a continuous path for improvement.
So the “fire hose” is in reality this incessant learning experience with customers all over the place to enact improved ALM processes using Team Foundation Server. More than that: I feel like I have been watching, from the first row, the dawn of a new way of working with software development using the Microsoft platform. It reminds me the old days in 1996 when VSS was a novelty. “So you don’t use source control? Here’s VSS. It will double your productivity”. And it made a difference. After a couple of years, you couldn’t call yourself a professional developer if you didn’t use some kind of source control.
And today the same is happening with ALM 2.0: a few years from now, you won’t be called a professional developer unless you have a set of integrated tools that will finally make the overhead of capturing project management metrics a thing of the past. Better and more transparent tools such as TFS will fade in the background leading to the enactment of that Agile pillar principle: Individuals and interactions over processes and tools.