It was logical that my first post on the Hexacta blog would be on methodology issues, since
It was logical that my first post on the Hexacta blog would be on methodology issues, since this is what I’ve been doing for so many years. And one particular issue that remains very relevant these days is the evolution of Agile methods and their contrast with the methods that result from applying models such as CMMI.
On Monday March 18th I was invited to participate in a debate titled “CMMI versus Agile methods?” Before the debate, there will be a lecture by Jorge Boria with a very interesting title: “Waterfalls versus Agile and other nonsense”. I don’t know exactly what Jorge is going to say, but the title is very true: sometimes there are false dichotomies that end up being nonsense.
My first comment about any new thing that appears in the software engineering landscape to put some order to the frequently chaotic software development projects is to remember Brooks and his “No Silver Bullet” landmark paper. This skeptical perspective always reminds us that quality and productivity improvements will be slow and complicated.
The reality is that Agile methods, even when very little in them is really new, have the great advantage of being a good “package” of several of the most effective software engineering practices.
They are effective and, besides, there are only a few of them, and this is critical. Some of them include: the use of iterative and incremental life cycle models, requirements prioritization, acceptance cases definition based on requirements and effective monitoring and detection of deviations from plans.
One of the problems that historically complicated development methodologies is that these methodologies were always huge, overwhelming, and too “heavy” for anyone who wanted to start using them. The approach of Humphrey and CMM brought some relief to this old problem, since proposing a model with levels pointed where to start and how to continue. RUP also helped with the concept of “Methodology Framework” that can be adapted to a project’s needs with the “Development Case”.
Now, returning to the issue of whether Agile and CMMI are compatible or not, I will give my opinion that almost seems a joke. The answer is “yes and no.”
Why are they compatible?
Because Agile methods propose a set of practices that represent a fairly significant coverage of the practices requested by levels 2 and 3 of CMMI. Scrum in particular covers very well the the planning, monitoring and control, and requirements management process areas, among others. Some Extreme Programming practices such as continuous integration cover very well some Level 3 engineering process areas, such as Product Integration.
Why are they incompatible?
Because what the Agile methods propose is not enough to be a Level 3 organization. Therefore, it is necessary to add some additional practices. The problem is that many of these practices are things that Agile advocates do not recommend, or in some cases even hate, like everything related with most of the documentation often required by CMMI practices or that is sometimes needed as evidence to pass a SCAMPI.
Another comment I want to do, which is closely related to the above, is something that surprises me: the lack of flexibility shown by some Agile advocates on their methods. In particular, there is a paragraph from the book “Scrum and the Enterprise” by Ken Schwaber that calls my attention. He says: “Do not change Scrum. Scrum isn’t a process that you can modify to fit your enterprise. Instead, it exposes every dysfunction in your enterprise while you build products. It is your canary in a coal mine. Whenever people change Scrum, it’s because they’ve run into a problem, dysfunction, or conflict that they do not want to face and fix. Instead, they change Scrum so that the problem remains invisible and remains deadly to the enterprise. If you allow this to happen, you will have lost Scrum’s primary benefit.”
I just can’t understand this position, unless it is an exaggeration to avoid the appearance of “pseudo Scrums”. Flexibility is key in developing software. The best software engineer is the one who knows more methods, techniques and tools, and knows which to use and when to use them, and even how to adapt each method, technique and tool to a particular project and context.
You cannot be inflexible with “soft” things like Scrum. This is not an exact science. There are critical mission projects, there are product development projects, there are 5 people and 35 people projects. The variety is endless. My recommendation for all is: “Do not remove fundamental practices to hide weaknesses, like Schwaber says, but adapt the methods to the projects’ and organization’s needs.” Presenting inflexible methods with the “either this or chaos” statement has already done a lot of harm in Software Engineering history.
Comments? Contact us for more information. We’ll quickly get back to you with the information you need.
