There are so many books written on agile methodologies, each attempting to depict the realities of software development projects. There are many truths considered in them, though they seem to blend in a complex texture in which the writer takes usually the position of a preacher in which the sins of the traditional technologies are contrasted with the agile principles. In extremis everything done in the past seems to be wrong, while the agile methods seem to be a panacea, which is seldom the case.
There are already 20 years since the agile manifesto was published
and the methodologies adhering to the respective principles don’t seem to provide
the expected success, suffering from the same chronical symptoms of their predecessors
- they are poorly understood and implemented, tend to function after hammer’s principle,
respectively the software development projects still deliver poor results. Moreover,
there are more and more professionals who raise their voice against agile practices.
Frankly, the principles behind the agile manifesto make sense.
A project should by definition satisfy stakeholders’ requirements, ideally through
regular deliveries that incorporate the needed functionality while gradually seeking
to get early feedback from customers, respectively involve the customer through
all project’s duration, working together to deliver a feasible product. Moreover,
self-organizing teams, face-to-face meetings, constant pace, technical excellence
should allow minimizing the waste, respectively maximizing the efficiency in the
project. Further aspects like simplicity, good design and architecture should establish
a basis for success.
Re-reading the agile manifesto, even if each read pulls from
experience more and more pro and cons, the manifesto continues to look like a Christmas
wish-list. Even if the represented ideas make sense and satisfy a specific need,
they are difficult to achieve in a project’s context and setup. Each wish introduces
a constraint that brings with it its own limitations. Unfortunately, each policy
introduced by a methodology follows the same pattern, no matter of the methodology
considered. Moreover, the wishes cover only a small subset from a project’s texture,
are general and let lot of space for interpretation and implementation, though the
same can be said about any principles that don’t provide a coherent worldview or
a conceptual model.
The software development industry needs a coherent worldview
that reflects its assumptions, models, characteristics, laws and challenges. Software Engineering (SE) attempts providing such a worldview though unfortunately is too
complex for many and there seem to be a big divide when considered in respect to
the worldviews introduced by the various Project Management (PM) methodologies.
Studying one or two PM methodologies, learning a few programming languages and even
the hand on experience on a few projects won’t fill the gaps in knowledge associated
with the SE worldview.
Organizations don’t seem to see the need for professionals of
having a formal education in SE. On the other side is expected from employees to
have by default some of the skillset required, which is not the case. Besides understanding
and implementing a technology there are a set of knowledge areas in which the IT
professional must have at least a high-level knowledge if it’s expected from him/her
to think critically about the respective areas. Unfortunately, the lack of such
knowledge leads sometimes to situations which can impact negatively projects.
Almost each important word from the agile manifesto pulls with it a set of concepts from a SE’ worldview – customer satisfaction, software delivery, working software, requirements management, change management, cooperation, teamwork, trust, motivation, communication, metrics, stakeholders’ management, good design, good architecture, lessons learned, performance management, etc. The manifesto needs to be regarded from a SE’s eyeglasses if one expects value from it.
