“… merely applying an Agile (or any other) process is not a guarantee of success. As with anything else in life, there are trade-offs, and unintended consequences when applying a tool or process. This talk will explore some common Agile process practices that may work well in some contexts, and have unintended consequences in others.
The intention of this talk is to encourage us all to keep striving to build the best software we can. It's tempting to think we have the formula for success, but in a rapidly changing industry, we must adapt and change accordingly. “
Amen to that, there is no standard recipe for successful projects, instead, as the DOI advises, solutions need to be “context specific”, or as Alistair Cockburn reminds us, a new methodology per project.
This is not to say we should discourage passionate implementation of agile methods. Following my Agile Project Management Assessment Quiz post I was contacted by Simon Baker of Think Box who scored an impressive “Uber Agile” score. You can read an account of his project team practices and successes following the quiz and I commend him and his team on their work.
Rather, the point I want to make, is that our intent should focus on successful stakeholder engagement and better software. If this is achieved via agile methods then great, or if, say, via better communications, then so be it. We run the risk of ignoring the “Individuals and Interactions over processes and tools” value if we focus only on process.
For the last couple of months I have been reviewing draft chapters from Preston Smith’s new book “Flexible Product Development” due to be published later this year. I met Preston through the APLN board and I have learned a lot from reading the draft chapters. A portion that really hit home for me was his description of people over process...
We instinctively know people are more important that process; smart motivated people will be successful with even a poor process, whereas a weak team can fail with even the very best process. Yet, what evidence is there to support this? How can we follow our conviction to focussing on people first and process second?
Preston points us to Barry Boehm’s COCOMO model for answers of how significant people factors are. The COCOMO (COnstructive COst MOdel ) model aims to predict software development effort (and therefore cost) by assessing a number of project factors. From the graph below, it is clear that these factors vary considerably in their impact on the final project cost.
From the graph, “People Factors” are by far the most significant project predictor with a score of 34 that addresses the technical and communication skills employed of the project. Next comes “Product Factors” with a score of 10 that speaks to product characteristics like complexity and reliability. Then comes the “Tool and Process Factors” that have a score of just 3 indicating they are less than 1/10th as significant in determining the overall effort of a project than the people factors involved.
We tend to focus on processes, perhaps it is the left-brained analytical traits in us that aim to find logical improvements rather than having to grapple with fuzzy, emotional aspects of people; yet I believe this is where the high leverage benefits are to be found. I interpret the COCOMO factors as a useful indicator rather than an exact measure of their influence. This order of magnitude difference corresponds with other studies on worker productivity (from best to worst) and feels about right based on my own experience.
Leadership techniques aim to improve the people factors on projects. Agile methods combine good process with a limited set of people oriented practices. Merging the two (Leadership and Agile methods) is where I think the future is for high performance project teams.