When I first started working with .NET in 2000 the “process tooling” for the platform didn’t exist, heck the platform wasn’t even released. It didn’t take long however and immigrants from other platforms were getting involved building out the tool-chain required for agile software development, including build scripting languages, unit test frameworks and CI build engines.
Having come from other development platforms I was familiar with the alternatives to these tools and was comfortable stringing them together and I adapted my knowledge to work with .NET. From my very first .NET project I made sure that assets were in version control, that builds could occur automatically and that we got a shippable product every time someone checked in. My tools of choice were NAnt, NUnit and Draco.Net, CVS and/or Subversion.
I introduced these tools to many software development teams and they appeared to help the team produce software on a regular basis. This is really when I started to “care about ALM” although the acronym ALM wasn’t really defined back then.
In late 2004 I became aware of a new product that was being developed at Microsoft (code-named Whitehorse from memory). It was set of extensions to Visual Studio which brought team collaboration directly into the IDE. It combined Microsoft interpretations of all of the above tool-types and baked in one of a series of development processes.
Around the same time I had started experimenting with Scrum as a way of focusing development teams that had been under-performing (for various reasons) so the idea of a product that combined a process and tooling appealed to me. Of course Team Foundation Server and Team Explorer shipped with an updated version of Visual Studio and I changed from being an ASP.NET MVP to an ALM MVP.
Fast forward to present day and I am just as interested in ALM as I was back then, the big difference is that the tooling has improved significantly (including cloud support) and now has direct support for Scrum as a methodology in product. With these new capabilities the expectations on teams have increased and we are now talking about DevOps as a way of reducing the length of the feedback cycle.
Agile methods themselves are now finding their way into enterprise organisations (even outside of software development teams). This is creating a demand for training and certification so that businesses can have the confidence that the new methods are embraced and well understood.
Nine years in I still think that ALM tooling, and good agile processes are the key to successful projects (good people helps too!). Looking forward to what the next nine years brings.