No more “frAGILE” – every project deserves a custom-fit methodology

Agile frameworks such as Scrum and Kanban or scaling frameworks such as LeSS and SAFe assume that many projects are too complex to be thoroughly planned. In response, small development teams perform iterative and incremental tasks. Plans are adapted empirically, team members self-organize, and the general plan, the so-called product backlog, is constantly reprioritized based on the different phases. A quick, transparent, and cost-efficient realization of complex products is the goal of agile approaches. The importance of agile methods can be seen by even change-resistant organizations trying to “agilize” their projects.

But is an agile approach the solution, and if yes, why do agile projects also stagnate?

Many organizations have difficulties adapting to agile working methods, and when we analyze “agile projects“ in detail, we often find hidden waterfall models and relabeled traditional behavior patterns. Sometimes it is the organizational culture, sometimes a lack of experience, or the chosen method simply does not fit the project.

According to the “13th State of Agile Report” from VersionOne, published in 2019, a lack of management support for agile working methods as well as an overall resistance of the organization against change present enormous obstacles for the realization of agile methods. An even more significant impediment is a lack of experience with agile working methods and the incompatibility of the organizational culture with agile principles. Thus, a more differentiated analysis seems to be reasonable.

The 360 degree-approach of our Adaptive Project Navigator©

Especially before starting a project – but also during a project – a systematic and holistic assessment (360 degree-approach) can help verify the project method. A software solution developed by us, the Adaptive Project Navigator©, aims at this holistic approach. By asking substantive questions categorized into the four dimensions of people, scope, IT architecture and client specifics, a holistic approach can be identified – if, for example, a purely agile approach is suitable for a specific project. These results are enriched by a recommendation for the appropriate roles, events and artifacts.

The people dimension

Our experience shows that successful projects not only need goal-oriented, well-trained and competent employees but also executives that support, develop and trust their employees.

It should be no secret that motivated employees are a significant factor in the success or failure of a project. Nevertheless, many organizations seemingly forget this or rather disregard it, and therefore projects often fail due to a lack of communication or missing team spirit.

Agile frameworks take advantage of people’s potential involvement in a project. But they do not guarantee cultural change. Even if agile frameworks seem simple, their implementation can often be tricky. New methodologies come with changes for every project member. For example, members of an agile team not only want to see their individual responsibilities on paper, but they also want to live them in everyday project activities, which is often incompatible with existing organizational hierarchies. If that is the case, the new roles cannot be lived, resulting in falling back to old structures.

Therefore, it is critical to analyze by using targeted questions, such as is the team authorized to make decisions on its own, is the team cross-functional, does the team use a common project site.

The scope dimension

The scope of a project is one of the three general measures of the “magic” triangle, with time and budget being the other two. The triangle is used for comparing classic versus agile.

As a basis for time and budget planning, the scope is fixed in classic projects, whereas it is variable in agile projects. Feedback is an essential part of the iterative planning process of agile projects. Planning also continues during the implementation phase.

While working with clients, we often notice that many organizations are thinking more and more about using agile methods to respond to stakeholder requirements and changing market conditions more flexibly. Indeed, product development with many uncertainties on the customer side is almost predestined for an agile approach. But classic methods still have their right to exist and can be efficient.

The Adaptive Project Navigator (APN) helps analyze this dimension further. Even if the scope of a project seems to be fixed at first glance – for projects with substantial legal or regulatory requirements, for example – a detailed analysis of the scope can show the opposite.It is also possible that a close examination of the scope would indicate that combining both methods into a hybrid would be the most efficient.

The IT-architecture dimension

A general overview of the IT architecture is an essential precondition for choosing a project method. From an empirical perspective, the number of projects with an IT context is increasing significantly, and we expect an even higher relevance in the next years.

An antiquated and heterogeneous IT landscape with complicated and extensive interfaces could prevent adherence to the agile principles of “early and continuous delivery” and “inspecting and adapting.” The same applies to classic release management, as new versions must be released more often within agile projects, requiring a higher frequency for new features. Whereas new versions and features are released quarterly in classic projects, sprints only last one to four weeks. That is why a better translation and integration of system and product versions are needed in agile projects compared to classic projects.

An early understanding of the applications, interfaces, technical infrastructure and other general conditions, such as release management, helps validate how to deal with the given circumstances and which framework is the most helpful.

The client specifics dimension

Organization-specific factors also play an important role in agile working methods and are considered within our 360-degree approach – the ability and willingness for transformation can be analyzed within this dimension. An advantage of this category lies in anticipating challenges within the organization not covered within the other three dimensions. While the other three dimensions cover standardized questions, the questions within the client specifics dimension focus instead on an organization’s circumstances.

Conclusion 

Not all projects are suited for the application of purely agile methodologies. Each project deserves its custom-fit method. To assess if a classic, hybrid or agile approach is the most suitable, it makes sense to analyze the main influencing factors based on people, scope, architecture and client specifics. And that is what the 360 degree-approach of our Adaptive Project Navigator does.