The important ingredients to successful solutions … or in fact, what is a successful solution?

I completed the brownbag session as outlined in Introducing Visual Studio Team System (VSTS) & VSTS Rangers today and some interesting questions were raised, which in conjunction with recent threads on the South-African blogging community server https://dotnet.org.za, made me think. Well, while continuing the virtualisation thread last night to meet a morning milestone, I thought it may be an idea to keep me busy while waiting for the installations to complete … well, this post is the resultant slate of my personal 2 cents worth … take it with a bucket of salt, because after another all-nighter, my brain is not firing on all cylinders.

What is a successful solution?

There are many factors that define a successful solution … if I had to sum them up in 3 points, I would probably select the following criteria, listed from most important:

1. Happy end-user … in other words the user of the solution is getting value from the solution and “happily” uses the solution, which implements all expected requirements.
2. Happy sponsors … solution was delivered within budget.
3. Happy stakeholders … team members are happy with the quality of the solution and are not crossing their fingers.

Why bother with Application Lifecycle Management (ALM) solutions?

The key objective of an ALM solution, as discussed today, is to ensure that we can deliver quality early and often. It is all about quality, because quality means that bugs are kept at bay, that defects which are immensely expensive, both money and time wise, are avoided and most importantly that the maintenance is kept to a bare minimum. Every cent we have to pile into maintenance is lost investment in new features … and new features are what makes a solution competitive and valuable to the consumer.

An ALM solution is not only geared at consolidating an IT solution development environment, empowering all the stakeholders and allowing them to focus on the core business, be it development or testing or other, but more importantly to give us transparency, traceability and visibility of the true state of the nation of a solution. Not only is it easier to address a solution issue (business requirement, feasibility, …) if identified early on in the product lifecycle, but it also allows the stakeholders to terminate a solution if necessary, early on … it is much easier to abort a doomed solution in the beginning, than at later stage when huge investments have been made and promises have created expectations. A good ALM solution will empower the stakeholders to have the ability to monitor the “real” status at any given time and to identify and address any bad solution smells, before they turn into disasters.

When should I not consider a new ALM solution?

It is probably easier to list some of the scenarios in which I would not recommend anyone to implement a new ALM solution … whatever make or brand:

• Your solution lifecycle has already started, i.e. the developers are already pounding out feature after feature. Introducing an ALM solution into an operational solution team working towards defined milestones, will cause destabilisation, delays and unnecessary and counterproductive frustration.
• Your solution lifecycle is already based on a sound ALM solution, which is adding value to your environment. Unless the new solution is going to add additional value to your environment, I would question the quest for a new ALM solution.
• You have not thought about the impact of the ALM solution or invested in any pro-active planning. Installing and configuring an ALM solution is potentially the easiest part. Planning a successful implementation in a team environment, i.e. adoption, awareness, training, capacity management, hardware and software requirement and most importantly maintenance, is probably the biggest investment you have to make to get a rapid adoption and acceptance of the ALM solution by the team, a quick return on investment and a low maintenance environment. Planning is so, so important! If your have not done any planning, your should place the media back in its box, find a clean whiteboard, gather the stakeholders and start the discussions.
• You do not have the budget for the analysis and planning phase for the ALM solution. Planning is crucial and if you cannot commit to it, then as with the point before, you should place the media back in its box.
• Your solution team is very small … implementing an ALM solution for a small solution team may introduce more overhead and cost, than value add … reducing productivity, raising frustrations and cost, and imploding the solution in the process. Building a paper aeroplane does not need the same level of planning, testing, quality control and management, than the construction of a 200 passenger aircraft or a spacecraft … the same concept can be applied to any solution team, including IT.

Will automation of build and test solve all my problems?

A lot of people I speak to believe that automating the solution build and especially automating the testing will solve all their problems. It really depends … I, for one, am a promoter of the daily build as a bare minimum, with incremental and/or gated check-in validation builds being even better. In essence it is the pulse of the solution … but, as with the heart, a pulse does not mean that the host or the environment is healthy, merely that it is still alive. The tests give a better indication on the health of the solution, if and only if the tests give us a view on the overall solution and are tied to the actual business requirements of the solution. Running gazillion unit tests that test 100% of the code base could give us the false sense of euphoria, because we could have a 100% pass rate and a near 100% code coverage for code that implements 1% of the actual business requirements … in other words, the developer would be happy :) and the consumer very unhappy :(

The short answer is therefore, “it depends” and unfortunately in most cases “no”.

Are there any ALM silver bullet?

No … in fact, I have yet to find any IT solution that is a silver bullet and I have been in this game for 25+ years now. Maybe one day, we will have the real answer, not just 42.

What are the really cool enhancements in TFS|VSTS 2010, which could assist us with quality?

There is a long list, but I will try and summarise as follows:

• VSTS 2010 Team Architect: The complete facelift, support for UML 2.0 and especially the Architecture Explorer. The latter allows us to reverse engineer any solution and assists in the visualisation of old and new code.
• VSTS 2010 Developer Edition: Support for non-SQL databases in terms of the Datadude will allow may teams working with DB2 or Oracle to consider the VSTS product in future. Test Impact Analysis, historical debugging and many other features will allow the developers to be more productive and more quality focused.
• VSTS 2010 Test Edition: Requirements and Test Cases are slowly becoming first class citizens and the ability to tie requirements back to implementations and tests, will allow us to better track requirements and avoid the “Butterfly Effects or Legacy Fear” and “Missed Requirements” fears of the past. The ability for the tester to record evidence, i.e. screen dumps, video, test scripts and manual test step documentation not only improve evidence gathering, but assists the developers and testers in terms of defect resolution and therefore drives overall quality.

There are many, many more features, but as Sam says, VSTS 2010 is all about happiness, pursuing the dream of no more of the following: Planning Black Box, Late Surprises, Stakeholder Surprises, Parallel Development Pain, Bewildering Admin, No Repro, Build Breaks, Butterfly Effects or Legacy Fear, UI Regressions, Missed Requirements or Changes, Waiting for Build Setup, Performance Regressions, …

Are the VSTS Rangers projects supporting the forthcoming 2010 release and quality in general?

The main objective of the current VSTS Rangers projects is “to deliver guidance for the 2010 release, before the technology ships”. This is an important objective, because we wish to empower the potential users of VSTS 2010 to not only be aware of the features, but also to be able to plan the implementation pro-actively. The current, forthcoming VSTS Rangers projects, directly focused on 2010 guidance include:

• TFS 2010 Requirements Management Guidance
• TFS 2010 Upgrade Guidance
• TFS 2010 Branching Guidance
• Virtualized Deployment of TFS | VSTS 2010
• VSTS 2010 “101” Guidance Sheets

There are many others and I recommend you have a peek at VSTS Rangers Projects – summary of projects covered on this blog, which lists some existing projects and all of the forthcoming attractions. As the projects are focused on 2010 the answer is “yes, they are supporting 2010” and “yes, they ate focused on overall quality”.

Well, the virtual machines are done. What remains is to RAR them, which I guess can happen while I salvage some of the available hours for some sleep, before my laptop alarm starts pounding again :)

See you next time…