This is a brief review of the BCS CMSG Agile SCM event on 24th November 2008.
Please note that the presentations are on line from the link above. Below are some extra notes to go with the presentations.
All in all a very good and informative day!
Michael Azoff (The Butler Group) – The Agile Difference
Michael did a good job of setting the scene and introducing various terms around agile etc.
He talked about the wider context – and how people need to stay engaged in projects. Quoted an example of a US Healthcare provider where management did not get sufficiently involved in the new billing system because it was not “exciting enough”. The company had sufficient problems that it lost 2/3 of its value, and ended up having to pay out $200m to clients etc.
Such things promote the need for a dashboard – simple summary of project status with the ability to drill down. Data is always available.
Regarding SCM he noted nothing in the indexes of various books on Agile methods that relates to SCM – an oversight!
However, came up with a couple of useful links:
- Henrik Kniberg’s Version Control for Multiple Agile Teams
- Also his Scrum and XP from the Trenches
- Henrik’s Blog
Richard Erwin (Microsoft) – SCM and Agile Practices within Microsoft Developer Division
Another excellent talk and the slides well worth reading. Interesting to see Microsoft’s “dog fooding” of their own product and the benefits and improvements of their process between Visual Studio 2005, 2008 and 2010 (already out in previews).
Some points:
- Most companies using adhoc processes, and having problems getting a handle on all the information that is coming in. Showed off some of the dashboards and similar feedback options within VSTS.
- Within Microsoft there are 4 major divisions:
- Windows
- Office
- Developer Tools
- SQL Server
- Their largest instance is 17m source files, 500k items, 3 Tb data
- VSTS 2010 has been “dog fooding” since 2007. Problems don’t go unnoticed as a result – he mentioned the great summer ‘08 outage!
- There is a slide showing usage of VSTS within the various divisions. Developer Tools is completely VSTS. However Windows and Office are still using SourceDepot for version control (although using VSTS being used for Planning and Bug Tracking). Richard responded to one question that the internal tools (SourceDepot) were “not available” outside Microsoft. On further prompting, he admitted that SourceDepot was a rebadged version of Perforce – based on the source code that Microsoft bought in 1999 – one of those “industry secrets” that has leaked out over the years!
- A successful import from the Office division is the concept of “Feature Crews”
- Concept of Bug Debt – carry no debt in feature model. One of the slides shows the burn down chart from 25,000(!) bugs for VS 2005 – they did get it close to zero for release, but life was hellish! The comparable chart for VSTS 2008 is much flatter.
- Not surprisingly the cost of hotfixes or sevice packs is massive – its a major incentive to avoid those – hence major quality gates when teams push code back to the mainline.
Branching Model
It’s a fairly standard Mainline model with large team branches. There’s a huge amount of automated testing. Teams take it in turns to “publish” to the Mainline, and have to pass very significant quality gates to do so.
Andrew Tunnicliffe (London Underground) – Towards Visualizations of Configuration Management
Andrew wanted to leave us with the message – “Configuration Management isn’t just for Christmas!”
Some notes:
- His presentation was a little different in that it looked at the complexities of managing what according to the Royal College of Engineers is the most complex system in the UK.
- Software is very much only one element – in addition to hardware, staff/people are vital. This includes training needs etc – you can’t introduce new stuff without it. Takes 2 years to train 100 drivers. How do you manage change in that time?
- In one morning they went from 4 trains to 5 trains per period – this is a step change of 25% in one go – you can’t introduce 10% of a new train
- S/w control and signalling all changing.
- He called it saftety critical agile.
- Of course in a public project of this size, there are huge political pressures to deliver.
- A lot of the value in visualisation is for people at the edges rather than those in the trenches. Train driver just needs to know that something has changed.
The examples he showed us are a tool based around MS Project with various extra attributes, and a Network diagram tool. It can also publish to the web.
Interesting to see how something relatively simple and straight forward could make a significant difference to acceptance by people – the CM information is much more easily visible.
Finbarr Joy (Upco) – All Things to All Men: Keeping it simple?
Finbarr wanted to avoid any perception of giving a “sales pitch”, inspite of Upco’s sponsorship of the event – paid for a nice lunch!
The main focus of his talk was around build and deployment frameworks – making it easy to setup, customize and manage.
He mentioned the experience of Upco in doing development for their clients and wanting to scratch their own itch and improve their processes. The only drawback for me was the lack of specifics in the talk – it would have been useful to see some before and after figures showing how this approach has worked in practice. A couple of useful nuggets:
- Is your change management really change prevention – or perceived as that?
- Projects change a standard pattern many times which leads to incompatible processes and much rework.
He finished by pointing at the open source project Kundo which is well worth checking out:
Kundo provides a structured, convention based approach for Java builds. Kundo has a pluggable, extensible architecture; it harnesses the power and flexibility of Groovy and Ant to provide a highly configurable Java build framework.
Kundo achieves this flexibility with a plug-in architecture that attaches behaviours (provided by Kundo plug-ins) to build lifecycle phases. Kundo consists of a kernel and a set of foundation plug-ins. The kernel is responsible for the orchestration of the multiple collaborators within the build system.
Conceptually similar to the approach taken by the Apache Maven project, the Kundo implementation is simpler (the kernel library jar file is ~ 60Kb) and, in our humble opinion, offers greater flexibility; if you want to simply wire an Ant into a buildfile and use it, you can. Build lifecycles are defined within a build ‘recipe’. A recipe declares the plug-ins required to perform a build. Each Kundo plug-in, much like a Maven plug-in, encapsulates a discreet set of build management (or deployment, release management etc etc) logic and has its own versioning/release cycle.
Sean Cody (Bank of America) – SCM – the Agile Keystone
Sean’s talk has unfortunately not yet had the slides approved to be released externally. It was an excellent talk and well received.
He talked about some of the background and issues of both SCM (software configuration management) and Agile.
In particular for agile:
- Not always clear what it means
- Is it a project management approach or just technical practices?
- Fragilism?!
- Image problem:
- Hard to manage and control
- Too many cowboys
- An excuse for no documentation
- “Decline and Fall of Agile”
He used the metaphor of the keystone which is vital to arches, domes and other architectural designs. A lack of good SCM renders Agile ineffective.
Key components for Bank of America:
- Story management server
- SCM server
- Continuous Integration server
- Testing server
- Wiki for publishing results
Story management is the most important function for users. The key thing is to track the evolution of a story from inception to release. This means the following are all tied to stories (with no exceptions):
- All SCM check-ins
- Build records
- Testing records
The business can see the details of the stories and indeed click through to view all aspects of development should they so wish. This visibility allows development to prove its value to the business. It also makes for easy traceability – audit is not a problem.
Sean is keen on tools that are easy to integrate, even though customisation comes with the cost of maintenance. For the SCM tool the following are mandatory:
- Atomic check-ins
- Change history
- Performance
- Reliability
- Simple to use
These aren’t new requirements – but they even more important for Agile development. They (together with the framework) help address some of the criticisms of Agile:
- Lack of structure
- Lack of documentation
- Management of scope creep
- Meeting enterprise change requirements
- Meeting audit and regulatory requirements
He left with a word of warning: cultural change is hard to implement – tools can only do so much – your people are important!