Hanna Leivo, Project Manager, March 22, 2021
Software development is a continuous cycle of discovery, innovation, learning and adapting to change. An agile mindset supports such a process, as it is iterative and feedback-based. Individuals and small teams can also adopt the same philosophy, even if they are working as a part of a larger, not-so-agile project.
The Manifesto for Agile Software Development was created exactly 20 years ago, and so far its history has been diverse and varied. Agile methodology might sound like it is strictly targeted to the needs of software development. However, there is no reason why non-technical teams can’t adopt an agile mindset and model as well. Many other organizations have also improved their flexibility and delivery speed with an agile mindset. Many are now working specifically in hybrid environments, where traditional scheduling and project management processes are used alongside tactical agile methods.
Surely, they haven’t gone anywhere. Most enterprise-level projects are still planned and executed as waterfall projects, and often for a good reason. Enterprise-level projects tend to be complicated and involve considerable risks. However, waterfall projects are based on a way of thinking where we must perfectly understand what we intend to build before we can start development. Project teams try to look into the future and think of every single problem in advance. This is quite different from the agile mindset, which acknowledges that we are not fortune-tellers. We do not and we cannot know the answers and challenges before starting the work.
An agile mindset is based on making observations during the development process and the readiness to react to changes or problems as they arise. And they do arise. Agile development is both reactive and proactive. Solving arising problems might cause ripple effects in other development and business processes. Agility also means reacting before the next issue even forms.
We tested the agile hybrid model in a 3-year enterprise-level project in the energy and oil sector. The main project, involving various suppliers and systems, was executed using the waterfall model. Our project team, which consisted of teams from the client and Nortal, operated as one agile unit from the start. It planned, tested and executed the deployments together from start to finish. After three years, we are pleased with how well the hybrid model worked in a waterfall project. Small, independent project teams may well adopt this approach and integrate it into more traditional project delivery processes.
”An important aspect of this model is that the client becomes a natural and essential part of the planning process.”
In the agile model, regular, daily conversations with the client and their teams facilitate openness and increase trust between the client and the supplier. In the delivery phase, daily meetings with the client can function as a stand-up between the teams, and roadmaps, project plans, and priority lists can be uploaded to shared folders. In addition, regular product demos and testing sessions with key users and the technical team create opportunities for immediate feedback.
An important aspect of this model is that the client becomes a natural and essential part of the planning process. Working closely with the development team, the client can see the progress of the development and comment on it along the way. For organizations, the most visible benefit of using this approach is the iterative release of finished functions. Thus, the client sees the development progressing rapidly and, with the advancement of the project, the functionality of the product improving as well.
The client can also evaluate the performance of the product in production and adapt their plans accordingly. Similar to how development teams use the ”inspect and adapt” framework during development, businesses can utilize the same agile mindset in their product strategy.