Customers can realize successful projects thanks to the agile by design technology, to compact and multidisciplinary teams, an incremental approach, an organization by basic work units and a focus on essentials.
Is an agile methodology alone sufficient for creating a software solution?
Or does an agile methodology require an agile development platform?
We have long entered the era of agile methodology. Yet it is still very difficult to tell whether this has really transformed the way we develop software projects, how much this methodology is used, how effective it is, and in what areas. It is therefore pivotal to make certain important considerations on the usefulness of agile methodologies::
- it is necessary to check if and in what cases these methodologies are appropriate, depending on the type of project and solution, organizational model and process, environmental context.
- it is necessary to identify and address some misunderstandings and “false friends” that disregard the methodology, but affect its use.
With the Irion platform we have for years managed projects in different realities and contexts, creating end-to-end solutions in such areas as Enterprise Data Management, data governance systems, data aggregation and reporting engines, data quality solutions, data reconciliation and data migration systems.
This allowed us to learn, analyze and test different more or less formalized methodologies and ways as well as to highlight some of the main limitations and issues that often undermine the success of IT initiatives.
Here are four of the many possible examples.
Recording the requirements: Agile or absent?
An Agile methodology is often thought to eliminate the need to clearly identify the requirements. Moreover, structured recording of the requirements is sometimes seen as an impediment to agility itself and a cause for slowing down.
However, we have discovered how this masks some underlying problems and creates or amplifies others:
- Behind the lack of clear requirements or the difficulty to fully describe them often stands the lack of expertise or the dispersion of expertise in business processes. One often limits to working on slogans, titles and word of mouth, fearing to face actual business.
- The lack of requirements fundamentally undermines the construction process. One can compare it to the absence of a foundation, and the consequences that follow are the same.
The real advantage of an Agile approach is that it offers a possibility of a rapid and focused analysis of requirements:
- quickly identifying the fundamental elements of a solution and translating them into a limited number of drivers and of simple, clear, easily understandable assumptions.
- describing and framing the essence of what is necessary.
- allowing a quick and effective evaluation of costs, times and risks.
Analysis and design: Agile in form but rigid in substance?
Every once in a while, even with some requirements present, the Agile approach remains only on the paper. Companies – or consultants – use practices, techniques and templates that are related to the traditional implementation approach, where the attention is immediately moved to the detail. These include detailed descriptions of interfaces with the systems, traced records to be documented right from the start with the utmost precision, detailed description of the UI, very complete mock-ups, and most precise descriptions of the reports.
To complete this picture, add long validation processes that push away the goal.
These elements have little to do with the main purpose. Still, the developer needs them to actually proceed to the implementation by adopting any of the “traditional” tools at their disposal.
Implementation and configuration: short development cycles or inevitable re-cycling?
It is often desired to work on the implementation in “sprints”, with short and easily verifiable development cycles. However, it is difficult to pursue this approach in practice, for a number of reasons:
- the requirements are tremendously unstable even short-term, and the stability of the requirement is a necessary condition for working in sprints;
- conversely, the analysis is still based on a waterfall logic, monolithic and full of detail without any incremental approach;
- achievable intermediate results are not expressed, and it is difficult to identify and work in independent and consistent units of work;
- the tools in use are inadequate for models and logic of incremental building.
It should be emphasized that an approach based on incremental building requires tools that support it. Without them, “incremental building” transforms into “the possibility of continuous re-cycling and remaking of an application built according to traditional logic”.
This has nothing to do with Agile and involves ever-increasing times and costs, where every line of code has its weight.
UAT (User Acceptance Testing) & Roll out: so Agile that it is not what I expected
As the fourth point let us consider the certification phase of an application by users. In reality it often appears unsatisfactory because no explicit criteria were given to define how what has been achieved corresponds to what is desired (“definition of done”, “use case test”, “success criteria”).
The notorious UAT therefore results in showing the user something they probably do not know, in the realization of which they did not participate, yet asking them to check whether it is in line with what was expected (or what they didn’t even know was expected). Chronicle of a death foretold: without clearly defined success criteria, the project is destined to a myriad of re-cycles, disputes and makeovers that often lead nowhere.
On the contrary, in an effective Agile approach the satisfaction criteria the project will work on must be clear from the start.
Based on our experience, a certification or UAT should be conducted not with respect to generic expectations, but to defined and explicit success criteria. Ideally, test cases can be traced back and are independent of exogenous factors.
Is there an alternative? The assertion here is not to show the ineffectiveness of Agile modes, but to propose an alternative at least for the EDM context. We at Irion have decided to invert the paradigm. Instead of thinking how to apply an Agile methodology in our projects, we decided to make Agile the Application.
Beyond the word play, Irion EDM is an Agile by design platform that allows to be extremely agile in projects and in the realization of enterprise data management solutions.
Our methodology is Agile because the platform we work on is Agile. And the platform is Agile because it is based on a declarative paradigm that turns over many assumptions of traditional development. It is in the combination of these factors that we try the success of our projects.
Why?
Let us quickly go back to the critical points analyzed.
Collecting the requirements
A platform based on a declarative paradigm makes it possible to reason according to an Agile approach, goal-driven in the phase of collecting the requirements.
- We concentrate on really understanding what the essence, the need, the goal is.
- Our definition of requirements is extremely fast and accurate, it is based on a few founding drivers that guide the underlying declarative model.
- We rely on the assumptions that define the perimeter and leave out the details irrelevant for the assessment of the risks and costs of the project.
- We provide the evaluation of complex projects giving fixed price estimates with a high level of reliability.
- For us, a change request is something that comes in an objective and unequivocal way and is coherent with the initial scope. It is never an arbitrary modification in specific details or in functional analysis, nor a request for the system’s fine-tuning.
Analysis and design
The analysis of an Irion EDM based project never requires tiresome documents dozens of pages long. Instead, there is just one document that turns the user requirements into a high-level design and a related functioning model.
In addition, in our declarative model, the EDM platform automatically generates the solution documentation, based on how it is implemented and configured, and keeps it updated in response to subsequent developments.
It is the platform that makes the project Agile. This way Agile methodology does not just stay on paper.
Implementation
In a traditional and rigid development environment, the benefits of an Agile methodology will not be able to actually take root at the implementation stage.
Instead, Irion offers a platform and an integrated work environment created “by design” for incremental building thanks to the underlying declarative model. This makes it possible to proceed by the subsequent iterations of build, design review and release, shortening the supply chain and anticipating end users’ onboarding.
A number of factors often make the development difficult, long and expensive, such as the implementation and modification of data reading and transformation processes, the predefinition of structures and archives, changes to the UI and to reporting, the debug, change management processes. In an Irion project, all of this is significantly simplified.
Here are some quick and effective examples:
- In a very simple way one can configure the solution with the logic of independent and self-consistent “building blocks”. Each part can be realized and verified independently and in parallel, increasing overlapping and reducing the time. Therefore, modifying a component never affects the entire solution.
- The system is not expected to have predefined data interfaces.It is very simple to work with test data or dummies waiting for the “producers” of the necessary information to make available the real datasets.
Thanks to the declarative model those who design a solution in Irion:
- do not have to strictly predict a predefined physical data model. The data structures are self-adaptive and self-contained in a set of databases whose physical data model is automatically managed by the platform;
- do not have to worry about managing execution dependencies and their modifications;
- leave it to the system to optimize execution plans and to adapt the procedures according to the data volumes.
- The release of components, modules or parts occurs without the need to compile the code gradually as it is built.
With Irion, the implementation can be truly optimized and broken down into sprints. Shortbuild & review cycles ensure the solution’s compliance with the requirements is ongoing and not only in the final stage.
UAT & Roll Out
At the end of a project we reap what we “objectively” have sown. The Irion approach defines the success criteria of a project, so they can be verified in the solution prototype releases subject to periodical design reviews with users.
- The UAT phase can be distributed over intermediate releases without running the risk of overall inconsistency.
So full speed ahead with Agile, but without stopping at the methodology. Let us focus instead on the tools that have made Agile “alive” and that radically change the way of doing projects.
When it comes to EDM, Irion is the answer. Those who managed to invert the paradigm with us do not go back now.