Guidelines to choose your ALM pilot project and pitfalls to avoid

Some Agile and/or ALM adoption efforts are canceled midstream because of lack of understanding of the basics of finding a suitable candidate development project. I have seen in more than a single situation that the chosen project is cutting edge in all three aspects of technology, process and people:

  • The technology is brand new, or new to the team, sometimes in even more than a single tier (for instance, new database software coupled with new UI development tools and a new programming language)
  • The development process is being changed (say from waterfall to Agile)
  • New people are being added to the team just after receiving their first training in the new technology

But the biggest mistake with Pilot efforts is to to use a strategic, high profile brand new project as the proofing ground for all these aspects, all at the same time. This is more common than expected. It starts as something like this:

  1. Business has some urgent need for strategic functionality that allows them to challenge the existing technical architecture
  2. However, the effort still has to abide by the usual existing waterfall processes that dictate that all must be done in a single pass
  3. So the project is approved, but no cycle is allowed to try out the new tools and processes in a smaller context , and multiple changes to the environment are bundled together in an insurmountable ticking bomb that will later explode as a "death march" project.

To add insult to injury, sometimes on top of all this no proof-of-concept is ever tried with the new technology and processes (Proof-of-concept differs from pilot in that it is done in a lab environment, with no impact on business). Pilot projects do have business justification, but usually one chooses a minor project instead of betting the "jewels of the crown" on risk upon risk.

The mistake on all these lies usually in the governance management tier(PMO, office of the CIO, etc). It is usually associated with just enforcing the status quo, and it takes some brand new business need to act as a catalyst to challenge it. This governance tier should be the one to understand how to evolve their environment through carefully taken steps, and to know how to spread the risk underlying the business need into preparatory small projects (using proof of concepts and pilots) that will pave the ground for more ambitious ones.

If a governance tier is not active in doing this, the new project decays into a rogue that just reinforces the "didn't tell you so" attitude of those who see governance only as keeping IT madness in straightjackets.

Allowing this to happen is like building on moving sand: the construction might be impeccable but will collapse upon itself if it doesn't have firm ground to support the pressure of adding new layers.

The best practices for selection of a Pilot project are widely known, and for quite a long time. Here is an excerpt from a Microsoft Official Curriculum course from 1993. It is part of Course 124 - Managing the Migration to Client-Server Architectures. I modified the text to fit ALM adoption (the text in brackets [] replaces "client-server" and updates the context of other points):

"Start small - with a Pilot Project

We suggest you start your exploration of [new ALM processes and tools] with a pilot project.

  • Maintain excitement:
    • Sponsors will lose enthusiasm
    • Team members will lose enthusiasm
    • Reduce risk of turnover
  • Need strategic answers quickly to be of value.
  • Avoid management problems of large projects:
    • Large projects require more layers of management
    • Coordination of client developers and server developers is critical
    • Coordination will be much easier in a small group that talks to each other

Selection Criteria of Pilot Projects

  • Well defined data requirements
    • Don't want to get bogged down in data analysis
    • Could be existing application
    • Could be part of a new application, where data analysis has been completed
  • Benchmark available
    • If don't have, need to build in-house benchmarking capability
    • Performance criteria
    • Quantify savings and benefits
    • Define ball-park expectation
    • Use to validate tool selection
    • Use for quality control in future projects
  • Decision support application [Business Intelligence in today's jargon] as opposed to data entry application
    • More showy, if that's what's needed
    • Safe place to start - it won't disrupt business operations
    • Usually a simpler system
    • Deliverable flexibility - keep concentration on testing the [ALM processes and tools]
  • Committed and supportive users
    • Might be #1 critical success factor [that includes not only end users of the application in the role of product managers, but also developers, project managers and upper management]
    • Willing to work with the team
    • Willing to allocate the time required for the project
    • Could use internal IT system so "end users" are IT
  • Low Cost
    • Use equipment you already have [for instance, VPCs]
    • Look for idle equipment [for instance, a PC with Windows XP can be a build server for a small project]
  • Low Risk
    • It's better if this might be considered a throw-away project
      • Objective is to evaluate [new ALM processes and tools], not build an application. Concentrate on tools and platform rather than application development"
    • If you need to choose a project that is mission critical, at least let it not be time-critical

As you can see, those best practices are nothing more than codified common sense, and I highly recommend you have those in mind when scoping your next ALM project.

Technorati Tags:

Busy with VSTS and TFS

It has been a busy year, and as any Agilista will tell you, it is time for a retrospective. Here is a picture of what my mind has been over the last year - all nice and fun, but very busy:


Well, that's not actually the picture - my mind is more organized than that J. So here is what I have been up to (BTW thanks Steven Borg for the photo).

Last November I presented at TechEd Brazil on MSF CMMI, and wrote a chapter on MSF Agile (in Portuguese) for a VSTS book led by Brazilian MVP Fábio Câmara, plus several other authors.

Besides consulting engagements, I worked with the creator of MSF Agile, Randy Miller (now with MCS) on a MSF Agile training course, and helped my team create an "ALM Assessment", a version of which is now online at

Then in January I presented at TechReady (an internal Microsoft conference) with Sam Guckenheimer on "Fundamentals of ALM", and learned about the latest and greatest in upcoming Microsoft technologies in sessions raging from VSTS Orcas and Rosario, to WCF and others.

Soon after that I embarked on a 8-month stint with the MSF Team (now called "VSTS Process" team) as one of their product planners, while we were waiting to get Andrew Delin on board.

In February I had fun at SEPG 2007 in Austin (where I live - it's nice to have a major conference in your city once in a while). I was at the Microsoft booth talking about MSF CMMI and TFS, and also had interesting conversations with other booth presenters: Osellus (on the future of process enactment and authoring), Fujitsu (on how Macroscope for VSTS uses VSTS/TFS/Project), and Personify Design (with the new products to manage work items from Outlook, and requirements from Word).

At the conference I had the opportunity to talk a lot with David Anderson, the Architect of the MSF CMMI process template (now at Corbis), as well as Mike Konrad and Paul Nielsen from SEI on the past, present and future of MSF CMMI. I also met Hillel Glazer, one of the few fully certified assessors who also works with Agile development in depth.

In March I was at the SxSW Music and Media conference. I helped at the Microsoft booth for the Happy Hour sponsored by Microsoft Expression Studio where I had the opportunity of again talking to the Usability guru Chris Bernard about creating a UX whitepaper for MSF Agile (which is the only Agile methodology AFAIK to explicitly adopt Personas and Scenarios for User Experience).

While with the MSF product team my focus was especially on getting customer feedback. I helped to coordinate a workshop on Reporting in March, monthly calls to the MSF Council members, and hundreds of discussions on how to enact process in VSTS. I have also been in the MSF Forum a lot. After all this and two SDRs (Software Design Reviews) we got great feedback on how we can create better process templates for VSTS.

Then in June I presented at TechEd 2007 on MSF CMMI, helped at the Patterns and Practices booth, and rubbed shoulders with Ivar Jacobson from IJC, Sam Guckenheimer and Ajoy Krishnamoorthy while talking on the cool ESSup implementation for VSTS, Mike Azocar (creator of a lightweight Scrum process template), Colin Bird from Conchango (one of the authors of the first and most widely used Scrum process template), and a host of other VSTS MVPs, among them Chris Menegay, Steven Borg, Will Stott, Martin Donnell, Joel Semeniuk, Richard Hundhausen, Jeff Levinson, Jean-Luc David, Juan Perez, and customers from the MSF Council such as Brian Hinton and Wayne Miller.

Then at the end of the June/early July I worked from London for a week and a half on the process templates redesign with Ian Spence from IJC, and Alan Wills. We also worked on the CMMI 1.2 update and SOX for the next version of TFS (Rosario time frame). A second session on this work was done in September, this time with Andrew Delin as well. I couldn't travel for this latter one, so I worked with the London team from 2:00 AM to 11:00 AM CST every day - an interesting experience of remote work using Live Meeting.

In August I followed the "Scaling Agile" topic at Agile 2007 in Washington DC - an interesting topic which I am still working on with a few other attendees and customers. The best presentation was from Sanjiv Augustine on "Transitioning to Agile Project Management" as he showed how to avoid the friction between PMs using traditional techniques, and the new agile thinking as a company scales Agile from small teams to reach the whole enterprise.

Then I switched gears back to the ALM business - this time with a nation-wide ALM Business team. Last September I did a talk to the VSTS Inner Circle, again on "ALM Fundamentals" (recording started too early - you will have to wait 5 minutes for it to begin. I might post a trimmed version later).

October was the "bug month", not of the software kind, but of the "being sick" kind, which put me out of work for two weeks (one of them with a continuous migraine that now makes me see with even more sympathy those that have this condition).

Finally, in early November I participated of the Alt.Net conference in Austin - a great forum for users who want to use OSS tools for .NET development.

So what is the latest?  I will be doing the keynote in São Paulo on the 4th of December on "Delivering Value Through Application Lifecycle Management" at the Simpros (International Symposium of Process Improvement for Software)  event, meet a few customers and then if I still have time, pass by TechEd Brazil.

I am now working on a couple of workshops on MSF Agile and MSF CMMI Project Management, and a webcast on "Using KPIs to Streamline Development" with VSTS on the 13th of December, all that while engaged on a few VSTS ALM Projects. I can't complain of not having work to do J....

All in all, in retrospective it has been a very productive year, and hopefully I will repeat the dosage as I delve even more on implementing Software Engineering best practices with Visual Studio Team System.

McCarthy's video on "23 and a half Rules of Thumb for Software Development"

"23 and a half Rules of Thumb for Software Development" is a classic video of a speech that Jim McCarthy made to Microsoft Consulting Services. It has been shown worldwide to anyone taking MSF training, as part of the "Principles of Application Development" course.

McCarthy also recently released it as podcasts at

This video is a great companion to McCarthy's "Dynamics of Software Development" book, one of the cornerstones of MSF 2.0, software engineering classic (note that the book has 54 rules, not just 23), and that the video is included with the latest edition.

Agile 2006

The weather in Minneapolis was warm this year, and so was figuratively speaking the Agile 2006 Conference, which had all sorts of interesting discussions going on anywhere - lobbies, dining rooms, sessions. I felt at home for its informality, and definitely will come back next year.

While being a newbie to the gathering, I have been working with agile software development since 1999 when I was first introduced to the topic by Bill Addington, whose last job at Compaq was as a software development quality and methodologies guru.

Aside from MSF (which to me was inexplicably absent from the manifesto meeting in 2000), my first book on agile was Adaptive Software Development by Jim Highsmith, then eXtreme Programming Explained (first edition) by Kent Beck,  followed by Java Modelling in Color, a beautiful book by Coad, Lefebvre and DeLuca, which introduced FDD.

So while at the conference it was a pleasure to meet in person several luminaries who have been the backbone of the Agile movement.

The first one was Alistair Cockburn [pronounced 'co-burn']. We had a chance of chatting for a few minutes after his introductory presentation on Agile Software Development in general, and Crystal Clear in detail. My favorite book of his though is Writing Effective Use Cases.

We talked about the origin of the name "Agile"  for the manifesto, with a few interesting points I will bring back later.


The last 6 months

Andrew Delin was asking me the other day what I had been doing since January, so here is a quick summary:

Without going into details, I still kept very active in the MSF and TFS world:

  • Participated of the SEPG 2006 conference with the Microsoft booth (I will come back to that later), with Randy Miller and David Anderson (who coordinated the MSF for CMMI Process Improvement Appraiser's workshop)
  • Worked (and I am still working!) with Randy Miller on an 3-day Agile Software Development course
  • Moved to another Microsoft team focused on ALM (Application Lifecycle Management)
  • Worked on site at several customers helping them with adopting/migrating to VSTS, TFS and MSF

There could be no better event to blog about other than the Agile 2006 Conference. I will come back to it over the next few days as I collect my ideas on some of the sessions I attended.

Comparative study on RUP vs MSF

Johan Traa has just published a comparative study on RUP vs MSF for Agile Software Development: "MSF Documentation: RUP vs. MSF - A comparative study". Check the post at the MSF Forum.

It is really worth the reading. He adds new material to help you understand MSF for Agile Software Development, specially a nice graphical representation on page 132.

Who says software development has to be without fun?

If you are not interested in the not so subtle Dilbert comics, you might want to start reading David Anderson's blog for subtle Scottish wit in between some serious postings that are among the best in the industry.

MSF oldies

I was talking to my good friend Andrew Delin about how the original MSF 1.0 had several concepts which today are associated with Agile methodologies. One such concept was the polemic "Why No Requirements Document?" one. The main point in this doc is:

·         Users/customers generally don't know what they want or need until they gain some familiarity with what they can have; 

The solution presented at the time resonates with what has become common today:

   The SDD process model does not ignore customer requirements.  They are accommodated through: 

·         early identification of driving requirements and constraints as a part of defining the project scope [i.e, Vision Scope document]; 

·         establishing traceability through analysis techniques like activity-based analysis, in which all features specified in the Functional Specification are traceable to specific user activities or tasks identified in the analysis activities [i.e. Personas and a list of Scenarios]; 

·         controlled revision of project scope and Functional Specification documents to reflect changing or better-understood requirements [i.e. Functional Spec as a collection of Scenarios which can be modified or postponed to a later iteration ("versioned releases" at the time)].

These and other gold nuggets are in MSF 1.0 RC1.

Hello World

As a new blogger (out of hundreds of thousands already out there), and as a developer, my first post had to be "Hello World". I fondly remember my first experiences with Turbo Pascal 5.0, at the time the best development tool available.

You can get Turbo Pascal 5.5 even today: check this article by DavidI, who I had the pleasure to meet last June at the UML & Design World Conference (thanks Randy Miller for introducing me to DavidI).


<<  June 2017  >>

View posts in large calendar

Month List