Should you be Agile whatever your project context?
and Agile does not stand for less process
We have all seen the agile craze in the digital world. A method born from the inability of V-Cycle to respond to the volatility of customer requirements in a highly innovative domain. Contrary to what some people often think, agile is not the solution for less process, nor is it the ultimate solution for the success of your project.
This article assists you to ask yourself the right questions if you have to identify a methodology for your digital development project.
Agile
It is not necessary to define the agile approach and its principles, indeed you will find a large number of articles about this subject and here are the ones that I recommend:
Some fundamentals of the agile approach can be challenged, that ‘s why it is not always appropriate to define the agile with less document, less process and less planning. On the other hand, these aspects experienced throughout running a project are compatible with the agile approach. This method provides a framework in which the agile team members will have to produce the deliverables. Nowadays, online tools enable writing documentation in a collaborative manner, while staying agile. Likewise, there is not less process but a different process.
As indicated in “The Misconceptions about the Agile,” a good project manager is not optional for the success of an agile project. In other words, the agile does not exempt you from planning your project.
“ If an agile approach is used on a project, it does not replace the implementation of a real management.” (Concept 3 of “ 5 misconceptions about the agile approaches”)
Agile is an obligation of means.
The approach of agile is an obligation of means, rather than an obligation of result. It is regularly criticized for a low engagement on the budget and the scope. Nevertheless, these low engagements do not always involve getting more expensive or longer. You can be more efficient with an agile approach than with a V-cycle approach (or its derivatives), and inversely.
An agile approach does not define “what” but “how”.
You will choose agile to be able to iterate the roadmap for your product without being fully decided on the functional scope. Selecting agile to visualize the progress of your project through regular demonstrations and can be able to rectify if necessary. You will choose agile to favour quality rather than quantity.
Agile requires proximity, or responsiveness.
A lot of people who have experimented an Agile approach with development teams working closely with the business teams will confirm the success of the method. In contrast, it is not always simple to come up with the same result with the same system for remote teams. And it is more complicated to guarantee a certain productivity if you choose to involve a service provider. In fact, the engagement of means is difficult to “maximize” if you do not have a minimum of proximity. Thus, do not hesitate to position one of your managers into the agile team that is remotely provided to you. His/her role is to facilitate the exchanges by increasing the responsiveness of both sides.
The selection of the methodology according to the project context.
At ekino, project contexts are heterogeneous. Our teams vary by a factor of 1 to 12 with different types of project: innovation, business web application design, mini site, intranet, maintenance, etc… It is difficult to adopt a universal methodology, this is why we do not impose solely a single approach on our clients; we recommend the proper methodology to the project context, ensuring that it will maximize the value of the investment.
Therefore, there are several questions arisen:
- Does the vision of the project clear and shared or to be challenged? (In fact, in the context of a clear and shared vision, it would be more reassuring for choosing a classical waterfall methodology. A contrario, an agile approach will bring you more value if you want to challenge your vision)
- Does the application intend to last long with improvements or it is just for a short term duration?
- Does the product owner (or the client) frequently available or occasionally available to support the application development?
- What are the budget constraints versus the scope?
You got it then, selecting the most appropriate methodology depends mainly on the project context.
Avoid those who will tell you that one methodology best fits for your software development team without even having studied your project context.
Contact us if you want to know more about how we build digital applications at Ekino.
