As we have already mentioned above, the Agile implies:
These are really cool principles. They allow to react flexibly to the current situation, current trends and the real needs of the clients. Permanent releases allow you to check and adjust fresh ideas instantly. Focus on the most important features allows you to dispose efficiently the available resources and to provide the most up-to-date service and the most demanded functionality.
This approach is exceedingly successful and effective almost in all industries and especially in IT!
This all sounds great, but let us take a look at this process from the point of view of the budgets and deadlines. After all, managers and business owners should understand by whom, when and for how long this or that functionality will be realized. It is necessary to set priorities properly. It is necessary for the releases planning. It is necessary for making strategic decisions on business development and resource management.
For example, here are frequently asked questions, the answers to which are extremely important when making managerial decisions:
However, Agile starts facing problems with the answers to these questions... Because it is very difficult to provide projections or assessment of the upcoming work in the world of flexible development: Agile doesn't imply building of so detailed and clear plans, specifications and deadlines. Moreover, even if the approximate assessment will be given, it is very difficult to ensure its feasibility within the development cycle: our originally scheduled scope will always vary and be adjusted after each iteration. There will be cool and fresh ideas, various corrections, the recommendations that should be released primarily. Yes-yes, it is how Agile works.
Agile adherents may object to this point: why do we need deadlines and budgets? After all, Agile assumes continuous delivery of high priority features! After each iteration we will release new functionality, which will immediately start to work, produce a profit and give the opportunity to gather feedback from real use!
However, we dare not agree with this opinion.
It is not always correct approach to release continuously new developments on the live environment after each iteration! Very often, feature or product is not attractive to the client, not yet a minimum set of functionality has been implemented. Will you use the product which has only a "welcome" page and log-in details? Will you visit the online store, which does not give the opportunity to order a purchase after you have spent time on review and selection of the goods, again?
And how to act without features delivery scheduling? As a rule, before the product or any new functionality launch, different media and marketing activities are applied; and they need to be pre-planned and organized. Or the new functionality requires adjustments in different areas of your application, which will be performed by other departments or teams, and this activity should be synchronized.
The absence of coherent budget is a very dangerous approach in the implementation of projects in general. Because all the participants, anyway, have certain budget size expectations. In this case, the real budget and expected one would have difference and cause many problems: distrust and tension will grow between the participants of the project, extra processes control, which is not especially necessary, will be introduced. In some cases, the budget exceed can lead to the product development collapse or the dismissal of part of the team, which is certainly very sad.
All of these looks and sounds so, that Agile is good only in the "ideal" projects: when we already have successfully working product, bottomless budgets, completely loyal customers and the lack of complicated management situations.
In the same real projects: when our budgets and resources have a reasonable limitation, the exact terms of the implementation of the new functionality must be identified and followed with the minimum error, when our product has not become the leader in its segment yet and the consequence from the introduction of unsuccessful or incomplete features can be very painful, more conservative methodologies which give more predictability and control should be used.
But actually this is not the case! Agile is perfect for any companies, teams and projects! However, if the issues of planning play an important role in your project or company, you should use the so-called hybrid approach: Agile which includes a number of best practices of the project management. At the moment, the hybrid approach is the best choice for organizations which are just beginning to implement the Agile!
Let us then consider what elements of project management should be included in the pure Agile to make it absolutely appropriate to any company, to minimize the risk of potential problems and to increase the probability of successful completion of any project
There is no necessity to evaluate the project as precisely as possible, only high-level, approximate evaluation is enough. Also, if the project is expected to be long-termed, it is not necessary to assess the entire project, it is enough to evaluate the scope of one or few phases.
Such an assessment is very important, because:
In this regard, we must either maintain the existing road map without changes or restructure it neatly in accordance with the new global purposes! Alongside with that, the rebuild and the consequence of these changes must be absolutely transparent and comprehensible to all the participants
This is, perhaps, the most important point! As we have already repeated many times, priorities and scope changing is expected and welcomed in flexible development methodologies, and as a rule, when we talk about scope changing, we imply its expansion. In this case, the main objective of the project team is to reconstruct correctly the so-called project triangle which consists of scope, terms and resources. The scope increase can be corrected by means of adding resources or changing the date of the final release, but the most common adjustment occurs by means of scope revise: after each priorities change or adding new functionality the project team should analyze all the tasks planned for the nearest grand release and form a new scope and road map. The success of the project practically fully depends on how correctly and transparently these corrections will occur!
As the priority and scope corrections will occur often enough, the permanent scope revise will become time-consuming and problematic process for the project team and the stakeholders. It will have to be taken into account the dependencies between tasks, their importance, complexity and decided what and how can be shifted. Also let us not forget about the fact that the size of the team can be changed: the team can be increased or decreased, people will take compensatory leaves, sick leaves and maternity leaves... And all of these changes must be also taken into account in the updated road map.
Therefore, it is extremely important to use modern tools for project management (such as the TBB, Jira, Azure DevOps or other). This will save a lot of time while changes processing that will make the process of scope revise transparent and clear for all the participants, it will allow not to forget and never miss an important nuance or task.
And you will be pleasantly surprised at how powerful, flexible and fast Agile is!
You can get acquainted with one of the highlighted project management tools and our other articles in more details here.
In the next article we are planning to consider the use of Agile in distributed teams which are in different geographic locations, and best practices for self-motivating team creation.
To be continued...
