James McGovern in his blog, “Why do projects fail in large enterprises?”, makes a number of important statements
The key messages here are “open source communities tend to prefer competence over process and hence can develop higher quality software” and “with experience and a desire to participate in a community comes quality”.
I agree and disagree with James!
I agree that the balance between project manager and architect is often wrong – this is a well known problem summarised by the eternal triangle of project management. The project manager is responsible for the tangible dimensions of cost and time to benefit. A motley array of solution engineers including architects, configuration manages, release managers, quality champions, requirements managers, etc are responsible for fitness for purpose. While this area operates in this way, quality will never get on the steering group agenda.
I agree that many of the techniques of open source and agile can be deployed to improve large scale solution delivery. Test first, pair programming, frequent builds and smoke tests, prototyping and a range of “non-traditional” techniques can be applied to projects of any scale and geographic distribution with positive productivity and quality effects. We need to stop dressing these up as some great agile revolution – it dilutes the message, it puts people off, it sounds like a risk. These are just good practices that have been out there for a long time – I used all them at least 20 years ago.
I disagree that with the view that only experienced teams can deliver successfully. I have taken teams of trainees and delivered high quality complex software rapidly. We need to find a way of growing people. We need to find a way of delivering the less interesting parts of a solution. We need senior people who are interested and creative in growing junior people. Delivery teams must contain inexperienced staff for solution delivery to be sustainable.
Process is never a substitute for competence. Correctly applied process teaches, supports, and grows people. Process needs to be applied in a balanced pragmatic manner with a view of the competence of people, the technology risks, and the time and cost constraints. This way it improves productivity, minimises bureaucracy and improves quality. Poorly applied process does the opposite. To apply process correctly – you need managers who have a balance of delivery and software engineering skills.
There is an implicit and sometimes explicit view that software delivery is the most important aspect of a project – this is 100% wrong. It is the deployment of a new business capability and the consequent delivery of business benefit and sometimes “crap code” in production achieves more for a business than good code later. It may deliver more business benefit to have 100 staff fixing data errors on overtime than to wait a month for the code to do it. Benefits delivery is the measure not quality.
A great thing about the open source community is the sense of purpose and commitment to delivery. High performance teams share this high level of motivation. A commitment to developing high performance teams and a commitment to developing leaders is essential to improving delivery. The leader needs to have a mix of skills – project management, enterprise architecture, software engineering, teacher, and politician.
One area I do disagree with James is that Indian outsourcing teams think process is a substitute for experience. If you use an outsourcer then challenge them to show you how CMMi benefits your business. Challenge them to increase the benefits both in terms of quality and productivity. Get them to show how they have already done this. Ask them what you need to do to allow you to maximise benefits. Work collaboratively with your outsourcer – you made them part of your business.
What do we need to do?