Cross Functional Tooling for Cross Functional Teams

Talking with an old colleague about software project measurements and software project management dashboards, I was reminded strongly of my very first professional software development project almost twenty years ago.

It seems that if you work in the software development industry for any length of time, you find yourself solving the same sort of problem over and over again. In fact, the whole premise behind the idea of analysis and design patterns requires that you do. A key skill is the ability to abstract lessons learnt solving a problem in one context and apply them to a similar problem in a different context.

My very first project was a management system for an oil-fired, electricity generation station in the UK. Each of three servers was connected to a massive turbine by hundreds of i/o devices. These devices monitored all sorts of temperatures, pressures, revolutions per second, switch positions and indicator levels. Each server collected, processed and presented this raw ‘real-time’ information in different forms on workstation screens in an operations room. The three turbine servers also pumped information into a database on another central server for post-event analysis, maintenance and operations planning, efficiency level monitoring, cost predictions, and all sorts of other engineering and business analysis.

In comparison, most software development projects will have ‘management’ servers such as a:

1. Configuration management server with version-controlled files, requirements, tasks and change requests
2. Requirement Management server with hierarchies of different types of requirements
3. Test Management server with its own view of requirements plus test definitions, schedules and results.
4. Other repositories in addition or instead of those above

These servers are constantly collecting, updating, retrieving and deleting data about software development projects. Like the power station monitoring system, each software development server presents both ‘raw’ and processed information to users interested in what is happening in one project or across a set of projects at the current time. Also, like the power station monitoring system, there is a often some sort of management server collecting data from these various operational servers for more sophisticated management reporting, dashboarding, and time and event based analysis.

We could go on and on about the similarities between the software management servers and the power station system, comparing things like:

1. deciding the appropriate sample rate for an input,
2. the use of color-coded displays to communicate exceptions and grab the attention of users,
3. deciding on push or pull data collection/extraction,
4. examining rate of change as well as the current value of an input
5. etc, etc

However, the initial thing that grabbed my attention was the obvious big conceptual difference between the two architectures. The difference is the cross-functional nature of the servers in the power station system in comparison to the generally single function nature of the software development servers. The servers in power station system collected data about all aspects of one and only one turbine. There was not one server for temperatures in all three turbines, another for pressures, another for speed, etc. In other words, the servers in the power station system were cross-functional. The servers in a typical software development enviornment are typically dedicted to a single function. 

The obvious benefits of cross-functional servers are:

1. Localized impact of failure:If one of the turbine servers fail, two turbines can continue operating but if a key software development server fails numerous projects are likely to be negatively impacted. Imagine the impact on the active development projects across an enterprise if the central enterprise-wide configuration management service goes down for a few hours, or a centralised requiremetns management service grinds to a halt.
   
   
2. Better scalability:If we need to add another turbine to the power station, all we need to do is simply add another server to monitor it. Adding another project to our software development servers requires creating a new ‘project’ in each server and linking those new projects together through various integration points. There is often a practical limit to the number of projects a single server can service and therefore a finite limit to the scalability of a so-called enterprise server. Where servers support a single project, additional projects are supported by the straight-forward addition of additional servers.
   
   
3. Better encapsulation of items being monitored:In some ways, the power station servers were very object-oriented. Each server presented an encapsulated view of the turbine it was monitor to the operators and the engineering database server. It took a number of years to install the turbine servers because it required each turbine to arrive at its scheduled refurbishment. As a result, we installed slightly different versions of the server for each turbine but this did not cause a problem because the interface between them and the users and the engineering database server was the still the same.
   
   
4. Better easier security:Each team of turbine operators accesses its own server and has no need to access the others. Members of a software development project need user accounts on all the software development servers. Each server requires the appropriate user roles to be added for the project team and this is often compounded by different security models for each server. Since the servers are centralised and used by many different types and scale of project, the security roles and privileges can become complex, or, as is often the case, over-simplistic and restrictive because the centralised admin team does not have the bandwidth to manage a more complex environment.
   
   

The idea of cross-functional software development servers appeals to me because we want to encourage collaboration across disciplines in agile, cross-functional teams. In my opinion, each discipline using a different user interface to access their data in a different server discourages this. This is probably why during my five years at Borland, StarTeam was my personal favorite server-based product because it does span more than one discipline. More recently, Microsoft's Team Foundation System (TFS) also seems to be a move in this direction.

An old colleague, Phil Bradley, used to talk about cross-functional servers as a ‘Project in a Box’. As I understood it, his vision was of a project manager walking into a new project area with a Unix server containing all the software he/she needed to run that software development project. Power it up, enter details of the team, their roles, configure the key characteristics of the project, and you were up and running. Even better if, once running, the server could also automatically locate the project management ‘warehouse’ server and start to communicating measurements to it for higher-level analysis and project portfolio management.

Obviously, there would be certain logistic problems caused by the use of physical servers but with server virtualization most of the problems with physical boxes no longer exist  … and maybe the idea of cross-functional servers for software development projects is not as difficult as it might once have sounded.