James McGovern in his blog, “Why do projects fail in large enterprises?”, makes a number of important statements
- “how come open source projects can deliver high quality on time when folks don't even talk to each other”
- outsourcing is “about taking otherwise junior IT folks and making them usable regardless of their actual individual competencies”
- outsourcing firms “have convinced others that process can become a substitute for competence”
- “think of open source as a methodology for software development”
- “in an open source project, the architect is king and folks follow him”
- “project managers with budgets and deadlines are handcuffed to delivery of perception management at the expense of high quality software”
- “it is still fundamentally easier for me to put crap code into production at work than it is for me to do the same with almost any open source project”
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?
- Develop hybrid solution delivery leaders with a balanced mix of programme management and software engineering skills
- Leverage experience in large teams with a mix of skill levels to create high performance teams
- Create and sustain high performance teams
- Unify the solution engineering team
- Leverage delivery best practice which include techniques and process ruthlessly to drive quality and productivity
- Focus on benefit delivery and make transparent and rational compromises over quality