Agile projects are on the rise, but a solely agile approach is not always the most suitable choice for every project. It is necessary to validate in advance how much agility is appropriate for a project, especially before starting it. But even in the middle of a project, you can carry out an assessment using the Adaptive Project Navigator© with its systematic and holistic 360-degree approach to verify the project methodology.
“Would you tell me, please, which way I ought to go from here?”
“That depends a good deal on where you want to get to,” said the Cat.
“I don’t much care where—” said Alice.
“Then it doesn’t matter which way you go,” said the Cat.
“--so long as I get SOMEWHERE,” Alice added as an explanation.
“Oh, you’re sure to do that,” said the Cat, “if you only walk long enough.”
This short dialogue from Alice in Wonderland describes why framework conditions and goals play such an important role. Far too often, we rack our brains for a solution without clearly understanding the problem. We plan and start projects without clearly defining what should be reached. We assume we have clearly defined requirements and wonder why they constantly change during the project. Or we choose a methodology without even knowing if the necessary conditions for its application have been met.
It is not uncommon to hear about how large-scale projects failed. There are many reasons, from unrealistic project planning and missing goal definitions to a project team unable to take important decisions independently. And let’s face it, every one of us has been part of a project that has been delayed or even failed.
In BearingPoint’s Agile Pulse Study 2019, almost half of the participants stated that they have more than three years’ experience applying agile methods.
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.
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.
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 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.
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.
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.
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.