ALM Defined
ALM is still evolving in the industry but is typically defined to be application lifecycle management functions that represent a typical software development lifecycle.  These functions include requirements, analysis, development, and testing.  The "M" in ALM is what is key, given that management processes focus on the governance, management, and reporting of progress on the projects.  Given Agile's focus on continuous integration and automation, ALM becomes more critical to scale Agile across a group of projects and at an enterprise level.  Unit testing that is continuous in a Sprint needs to be facilitated as well.  Given that a "Scrum of Scrums" is how many Agile projects achieve scalability, a key tool is needed to coordinate the activities of different Scrum groups.  In the Microsoft toolset, the Microsoft Visual Studio 2005 Team System supports many Agile

 Figure 1: Agile Practices Mapped to a Microsoft Solution

The planning game is a key Agile practice that begins the pipelining process by looking at the backlog of requests.  Typically, Microsoft Project is used to scope the general scheduling and program definition.  From that point, Excel is used to create estimates for tasks.  These tasks then flow into the Work Items within Visual Studio.  Workstreams define the general flows for feature creation.

By definition, Agile focuses on small releases for features that can represent an application.  Backlog graphs used to be represented in Excel but are now represented using the Remaining Work Report in Visual Studio.  The Sprint concept is not built into Visual Studio per se, but is a management concept applied to a project.  The Scrum concept of bringing together a team to discuss status and what is targeted to be worked on is another management concept that is not enforced in Visual Studio but is part of an Agile management set of processes.

Simple designs typically result from good UML modeling of services.  The Application Designer tools built into Visual Studio facilitate the process and integrated into the lower level class diagramming processes.  As a set of system interfaces are defined, the System Designer tool supports these key modeling processes combined with deployment.

Testing and creating test cases upfront before coding is another key aspect of a successful Agile project.  Code coverage is the technique to implement the process.  In the past, nUnit and other open source tools were used but the unit testing of methods is built into the Visual Studio toolset and is typically generated via simple menu items.  The testing processes then integrate nicely with the continuous integration tools supported in the Team Foundation Build tool.  The tool essentially integrates source code control with the build process to run the unit testing scripts on the code base.

Refactoring is more focused on Agile-based XP techniques of redefining code and parameters to improve the code.   Microsoft supports this within the refactor menu and provides starting points for refining the code.  Team Explorer in Visual Studio allows for the collective ownership given that there is complete visibility into what developers are working on.  Policies and security can be set up to focus certain staff and groups on subsystems if desired.

What Works and Does Not Work, Yet
In working with the Microsoft tools in Visual Studio Team System, it is best to think of the tools as a 1.0 attempt at embedding Agile management and development techniques.  The value of the tools comes from the fact that they are part of a single suite and don't need to be assembled.  Some of the key techniques such as Scrum concepts operate outside of any specific tool and are more of a management approach.  Do not go overboard with the Work Items and integration with the Project Server since the management can become cumbersome to sustain.  The Remaining Work Report does help as Sprints are defined and feature sets are imported into the tool to track the feature sets.  Having an integrated bug-tracking system does promote the continuous Scrum testing methodology.  Various velocity charts are available to gauge how the project is progressing as well as the productivity of the processes.

Refactoring is basic in the Visual Studio toolset, but provides a starting point for developers to rename, etc.  Combining this with unit test scripts that can exercise methods and service models provides a good Agile starting point.  As observed on projects, the unit tests that are integrated into the Visual Studio tool fully support test-driven development with scripting languages as well as the compiled languages, C# and VB.NET.  Combine this with extensible, XML-driven build scripts provide a productive environment that supports automation of key testing processes.  Web testing processes can be integrated together with unit-testing of methods and can begin to represent full lifecycle testing.

Traditionally, a "build master" person on the development team would assume the manual build process role and kick off a build process.  Microsoft integrates automated builds into the process and streamlines the process.  From my experience, this is one of the most powerful parts of Visual Studio and is highly productive.  Thus, continuous integration becomes streamlined in a Microsoft project.  Automated builds and the ability to send the messages to developers if the build gets broken are critical Agile processes.

When implementing Agile-based projects with Microsoft tools, one is tempted to leverage entry-level or mid-level developers given the perceived simplicity of the Microsoft environment.  However, please avoid this temptation.  Microsoft Agile developers need to be senior level and be able to leverage the collaboration and productivity tools of the Microsoft environment.  From what we have seen, Agile projects work best with senior developers. A  few projects have not been successful when entry-level and mid-level developers were part of a Scrum.  The Agile experience level becomes critical when performing global, outsourced projects.   The need for senior developers on Agile projects has also been further validated by working with undergraduate computer science students one some industry-sponsored Agile projects.  The students were not able to operate as a Scrum unit and reverted to using more comfortable waterfall or RUP-based iterative processes and techniques.

Conclusion
It's not your father's Microsoft anymore.  Microsoft has embraced Agile processes and techniques and embedded them into the Visual Studio suite.  The suite combines many tools that used to be difficult to find and obtain.  Spending time to set up the environment and using the key testing tools built into the tool will provide excellent productivity returns to the project teams.  From personal experience, it appears that about a lot of projects are leveraging Microsoft technology and having better Agile support makes development life a lot easier.  As Microsoft evolves to the 2.0 version of the Agile tools, things can only get better.  When Microsoft makes it to 3.0, they typically have it right.  As the saying goes, "Third times the charm."  For now, the 1.0 version is "good enough" to do Agile management and development.

About the Author
Steve Mahoney, AVP, Applications at EDMC (Education Management Corporation), has over 17 years experience working in all facets of the IT services, financial services, and education industries. His current leadership focus is on Agile, CMMi, eSCM and CRM initiatives at EDMC, one of the leaders in the education industry. Previously, Steve has held   roles as a CTO, Director of Strategy/Marketing and various other leadership and management positions at CEI and Federated Investors.  He has led strategic technology briefings, workshops and engagements for executives and he is responsible for architecture definition and scoping on professional services engagements and working with field-level strategic consultants. He has managed product and professional service engagements with clients such as NAS, Yes Solutions, Bunge, Alcatel, Nextel, and CMP. Steve holds a Bachelor's degree in Computer Science and Applied Mathematics from Carnegie Mellon University and is PMP-certified. He currently is involved with the industry-leading Agile 2.0 initiative, is working jointly with Carnegie Mellon on the eSCM initiative, and serves on several advisory boards as a director.  He currently is an adjunct instructor at the University of Pittsburgh teaching an advanced technology course in SOA and defining a security certificate program.

Comments (1)

Paul Ellarby: ... Great article, Steve. I am currently working with a large client that has implemented Visual Studio Team System, and has been taking advantage of many of the features you describe, especially on the build side of their work. However, we have found that the tools supplied within Team System were not really up to the task of supporting Agile development, so we started developing our own template for use within it. This is much easier than many of us thought, and in just three weeks we have been able to integrate the entire process, from user stories to builds. I would encourage other Agile teams to use the inherent capabilities of Team System as a basis for defining their own process, and modifying it to better support their work. Incidentally, I am finding more and more tool out there for making the tailoring of Team System much easier - Google it, and I am sure there will be somethin gout there that meets most of your needs! 1 May 01, 2007

Write comment

Name

Comment

Write the displayed characters

Add Comment

Tags:

Click to add your tags...,

or Close