Friday, 29 February 2008 2:34 PM
Carl Rogers
TFS Adoption within EMEA – A Process Perspective
During our recent visit to TechEd EMEA Developers 2007, we again took the opportunity to conduct a 'process survey' at our booth – with the lure of winning an Xbox 360 (which was won by Christian Rysgaard from Simcorp in Denmark).
Our goal with the survey was to try and understand:
- the level of adoption of TFS within the EMEA (Europe, Middle East and Africa) market, and
- how ‘process’ is viewed within the EMEA/Microsoft software development community.
After a hectic couple of months (summer holidays, Christmas, New Year, moving house, etc.) I have finally found the time to have a closer look at the survey results from the 198 entries and gleaned some interesting insights...
(Note: Results of a similar survey that we undertook at the Australian TechEd event in July 2007 are published here)
Challenges faced on Software Projects
We asked the respondents to select from a list the top 3 challenges their organisation typically faces on software projects.
Graph #1 shows the raw scores that we received:
(Note: some respondents voted for more than 3 challenges, and some identified less than 3)

Graph #2 shows the raw data from Graph#1 broken down into the votes for each challenge as a percentage of the total number of votes:

This raw information becomes much more interesting when we look at it from the perspective of the percentage of respondents (voters) that voted for each of the challenges – as shown in Graph #3:

The results show that overall:
- Poor Requirements continues to be a major challenge for software projects.
- Organisations continue to suffer from delayed delivery from software projects.
- Software project particpants believe that their projects suffer from a lack of focus on testing and the absence of a formal methodology.
- Choosing the right technology is seldom the problem.
I was interested to see if there are different perceptions between ‘small’ and ‘large’ organisations – Graph #4 shows the key areas of difference when we seperate the data based on the size of the respondent’s organisation:

I find these points of divergence to be quite interesting:
Respondents from larger organisations:
- Perceive a ‘lack of testing’ and the ‘lack of a formal methodology’ to be less challenging than those respondents from smaller organisations. Probably indicating that larger organisations are typically more focussed on formalising the SDLC and include some degree of testing within the SDLC.
- Struggle more with ‘poor communication’, ‘unclear/imprecise business objectives’ and the ‘lack of executive support’ than those respondents from smaller organisations. I find these results to be typical of the challenges faced by many larger organisations.
Respondents from smaller organisations:
- Encounter real problems around the ‘lack of testing’ and the ‘lack of a formal methodology’ – but do not perceive ‘poor communication’ to be a problem. I have found these team dynamic issues to be relatively common in small organisations – particularly as they encounter the growing pains on the road to becoming a ‘large’ organisation.
I was also interested to see if there were any significant differences between ‘small’ and ‘large’ project teams – Graph #5 shows the key areas of difference when we seperate the data based on the typical size of the respondent’s project team:

Again, I find the following points of divergence quite interesting:
- Lager project teams have a real challenge with ‘unclear/imprecise business objectives’ – which, I surmise, probably also contributes to the challenges of ‘poor project management’, ‘poor architecture’ and ‘bad choice of technology’.
- Despite the significant challenge of ‘unclear/imprecise business objectives’ - ‘delayed delivery’ does not rate particularly high for larger project teams. I found this a little bit surprising as a lack of clarity around what the business really wants on large projects often translates directly into ‘poor requirements’, which ultimately leads to ‘delayed delivery’.
Adoption of Team Foundation Server (TFS)
As Process MeNtOR TeamGuide leverages and extends the process capabilities of Microsoft’s Team Foundation Server (TFS), we were interested to know how the adoption of TFS was progressing within the EMEA market.
Graph #6 shows that about 1 in 3 of respondents had adopted TFS:

Breaking down the TFS users by project size (Graph #7) reveals that TFS is predominantly being used within smaller teams (less than 10):

Slicing the TFS user data by Organisational Type (Graph #8) shows that, predictably, TFS adoption is more prominent within larger organisations:

We introduced a new question in this survey to try and determine which features of Team Foundation Server are being used – the overall results of this question are shown in Graph #9:

These results agree with our experience in working with many customers:
- The initial point of adoption of TFS is around Source Control.
- The more advanced features of TFS (particularly those around team collaboration, project reporting and management) are progressively adopted as the organisation grows in experience with TFS.
Drilling into these results, reveals that there are substantial differences in adoption of TFS features – based on the size of the organisation – as shown in Graph #10:

Although it is unwise to try and extrapolate too much from these results (based on the small number of TFS users within the survey respondents), I put forward the following hypothesis (based largely on personal experience):
- Larger organisations typically have some existing approach to software process (which is not based on MSF) and struggle to get value from the ‘out of the box’ process templates provided by Microsoft in TFS - preferring to rely on ‘harder’ measures to enforce procedures such as ‘check in policies’.
- Smaller organisations typically have little in the way of existing process assets and are therefore more willing to embrace the process templates provided with TFS – or to adopt other process templates available within broader the TFS community. Adopting such process templates enables these smaller organisations to derive more value in the reporting services enable via the process templates.
Software Development Processes
Graph #11 shows that within the respondents who have adopted TFS, there is a healthy regard for the value of software development processes:

We asked all of the respondents to identify what software development process they typically use. Graph #12 shows the diversity of process used within the Microsoft/EMEA development community – and the prevalence of ‘in-house’ methodologies:

Graph #13 shows that, when we look at the software development processes used within the TFS community, adoption of SCRUM and MSF is much more prevalent – probably due to the free availability of process templates and active user communities:

Finally, Graph #14 shows the diversity of roles using TFS who were present at TechED EMEA Developers:

Market Insights
The survey results are encouraging for us:
- The major challenges faced by software delivery projects can be addressed by the successful adoption of our methodology, Process MeNtOR.
- There is a solid base of Team Foundation Server (TFS) usage within the EMEA market– that we expect to grow significantly over the next few years. This represents a great market for our Process MeNtOR TeamGuide product which integrates our methodology into VSTS/TFS.
The challenge for us is encouraging organisations to move beyond ‘in-house’ methodologies and to leverage commercially available, best practice methodologies, like Process MeNtOR.
Cheers,
Carl