Companies undergoing organizational transformation face the dichotomy of standing still on the Iron Triangle when it comes to planning and managing software projects, or moving to an area that in principle resembles the Bermuda Triangle more than the comfort zone they have traveled through over the past few decades.
One of the most valuable things we have learned in software development is that many of the practices and techniques used since that historic meeting of the 1968 NATO Scientific Committee in Garmisch, Germany, which initiated software engineering as a profession, were taken on loan from other areas of engineering and other applied sciences.
Some of these practices directly influenced the way in which we estimate and plan software projects today. But we have also learned that we can't estimate or plan software projects the way they do construction industry projects . . . unless we're going to use Lego®
parts to build cities!
Fortunately, we already know for sure that software engineering has a nature of its own. It is a hallmark that makes it unique and makes its practitioners stand out from other engineering professionals and other bodies of knowledge. For example, in his book Agile Project Management
, Jim Highsmith
suggested that if we apply the Agile approach to the Iron Triangle, we would find the following vertices:
- Value for the user, in terms of a product that can be distributed and whose use generates benefits for the organization
- Quality, to continuously deliver value to the user in terms of a reliable and adaptive product
- Constraints (the traditional scope, time, and cost) such that, if one — usually the first — is moved, the other two should also be moved
As Highsmith says, those constraints are still important parameters of a project, but they are not the goal. In contrast, Value
set the project goal, and the above-mentioned constraints are adjusted as the project increases value for the user. In particular, time could remain a fixed constraint, but then the scope should be adjusted to deliver the highest possible value given the restrictions imposed.
As we like visualization, this other version of Highsmith’s Agile triangle resonates:
But there is more to this Agile planning and project management approach. Those of us who have been traveling through the labyrinths, climbing the cliffs, and walking through the complex valleys of Agile software development know that every single moment is an opportunity to inspect and adapt: to improve as people and as professionals, to improve processes and techniques, to improve the quality of products, and to increase the value that these products deliver to our users. It's continuous improvement
Therefore, continuous improvement, together with value and quality, forms another corner of the triangle, the result
. As agilists we are no longer interested in creating a product the simplest way, even if it is a disruptive one or if it has many benefits for its consumers. We are concerned with what is next, what will take the customer to the next level of optimization, satisfaction, and happiness.
But the most important factor in any project, in any process of innovation or improvement, in any plan that has the design and construction of products (of software) as its purpose, is people
: the face-to-face communication between them, the motivation of all the individuals who are involved in a project, the continuous attention to technical excellence, the team’s self-management, and the confidence that the organization deposits in them. All of these elements build the foundation of any endeavor’s success as we begin to generate new products or services.
With this in mind, we could then meet this new extended version of the Agile triangle, which is part of my Agile mindset:
You can find more of my agile mindset in my Gazafatonario