HMRC
The UK government's HM Customs & Excise (now HM Revenue & Customs) has been engaged in developing a set of web-based applications to enable so-called "e-Government". Not only did they change from a silo-based development to a resource-pool based development, they also changed platform from VB/Cobol to the brave new world of J2EE.
Part and parcel of this initiative was a move to using UML as the means of documenting specifications (use cases et al), with TogetherJ as the chosen UML modelling tool.
During 2003/2004 Haywood Associates Ltd. provided advice on the effective use of TogetherJ within the department, and to build up a centre of excellence of its use.
Buying TogetherJ Doesn't Create Agility
It might be prudent to leave the story here ... but we think the experience is worth sharing. As already mentioned, HMCE at the time was organized into 5 separate resource pools, the purpose of which was to build centres of excellence for Business Analysis, Technical Analysis, Technical Design, Programming and Testing. This in itself is not a bad idea; obviously in IT people have different skills and specialisms. The idea then was that individuals would be leased from resource pools into projects, contribute their expertise, and bring back their project learnings to their resource pool to improve the capabilities of the pool in general.
However, unfortunately the department didn't colocate project teams. Technical Analysts were in one building, Technical Design in another, Programming in the same building as Technical Design but a different floor - you get the idea. Instead, the project team members stayed located with their resource pools.
The consequence of this setup then was that it wasn't feasible to get team members to work on a single model. Instead, the BAs would create a model, this would then be shipped down to TAs who would copy it and then build their own model adding in additional information, then down to TD who would copy it again and elaborate their version a little further, then down to the programming team who - because they started work on the project at the same time as the BAs - would have already made many architectural and implementation decisions such that the models when they finally arrived from TD would be next to irrelevant.
To mitigate some of this, we introduced wikis to the department, to allow different team members to create useful material together and to allow "best practice" for use of TogetherJ to be at least captured. Over the course of the year we went from a first pilot wiki to ultimately one wiki per resource pool plus some additional project-specific wikis, all of which being contributed to.
While TogetherJ is a useful tool, it's also very clear that it absolutely cannot be bent into a waterfall style development approach as operated by this department and the larger developmental strategy mandated by the overall government. Or, if it is bent into such a development approach, it becomes little more than a very expensive diagramming tool. Like any tool, TogetherJ must be used correctly, but it is no silver bullet.