3 Consider risks
Agile is quite different than the standard way of execution in corporations. It brings benefits, but it also brings some risks. These risks should clearly be stated to the management.
Picture below shows most important risks introduced by the agile way of work.
Here we are talking about:
- Risk of not delivering full scope as set at the beginning;
- Risk of lower level of control by typical project steering bodies;
- Risk of less alignment with possible stakeholders – this is important in wide organization with conspicuous culture of alignment.
Let me elaborate a bit here.
Traditional way of executing things is based on clear and detailed scope which should be fully delivered in order for the project to be passed to a line organization. Each change in scope or time has to be communicated to and approved by relevant steering body, and before that aligned with relevant stakeholders of the project.
Described process is not feasible in agile way of doing things. First of all, you don’t commit to the scope, but rather on the overall goal that should be achieved within certain time. Further on, typically, product owner has the capacity to decide on priority of things that should be developed. By exercising this capacity he/she is inevitably changing the scope without asking for the approval.
This is possible because agile is based on the confidence that governing people put into product owners giving them mandate to make decisions that maximize benefits for the company.
Obviously the way how agile should be run is considerably different to standard way of doing things. This has to be clearly communicated to management when agile is introduced. Otherwise, management expectations will be where they are with standard project which might cause frictions later on when the development starts.
4 Be clear on the budget
I believe this one is obvious. Introducing agile requires team dedicated to digital agenda, this, again, means some funding should be found for appropriate team setup. This should be communicated clearly in order not to create false understanding with the management, and consequently introduce potential miscommunication in the future.
5 Stress benefits for the company
Once the bitter pill of risks and funding has been put down the management throat, some sweet syrup should be added for the pill to be swallowed.
Many articles have been written explaining why the agile is beneficial for the companies. I will list a few at the bottom of this post as a reference, but let me stress the most important ones:
- Delivery into smaller chunks focusing on the value for the customer
- Introducing Design-Prototype-Test-Develop loop which eliminates uncertainty over the product and demand
- Introducing more coherent and better working teams
6 Communicate expected deliveries
Finally, deliveries of this phase of introduction of agile should be clearly stressed. Here, you have to be cautious not to fall into a trap of committing to fixed scope. As mentioned above, a goal or ambition should be given as expected delivery, not a list of features.
Example could be: In the said period we will deliver:
- Improved authentication mechanism to our app
- New product page that will improve user experience and conversion rate
- New payment mechanism with one-click payment option
In addition you can give overarching vision for the period like: Improve user experience in most critical areas.
An example of how it can be communicated: