3 tips to convince the Client to use Agile
If we want to convince other people, we need to understand them. As an AgilePM, you need to understand the thoughts and fears of your clients. Put yourself in their shoes. From clients’ perspectives, it’s really hard to understand why PM is trying to convince them that having flexible scope in the project is a good approach. It sounds like you do not want to deliver some chunk of work for them, right?
In this 5 min reading, I will propose a few arguments that worked for me. If you want to share your thoughts on this topic, please give it a shout in the comment section. Let’s help each other by sharing experiences.
In short, arguments that worked for me to convince clients to develop software using Agile are:
- Agile is focused on value, but value perception changes overtime
- Value is delivered frequently, which improves benefits realization
- Business & Tech people are collaborating closely throughout the project lifetime
Let’s now go deeper into each of them.
Agile is focused on value, but value perception changes overtime
That’s right. What was important at the very beginning of the project, do not necessarily have to be important during the implementation. Priorities can change over time, and that’s how our life works. Your clients’ competitors could release a new product, feature or our business has came up with a great idea for improvement that ought to be released in the Product. There are a lot of factors around the project, which can impact it.
That’s why having flexibility in the projects matter. Especially, when it comes to the scope. Having flexibility is crucial part of Agile projects. Otherwise, we will treat all of the Product features equally important. And to implement change you will need Integrated Change Control procedures, adjust all of the three project triangles (scope, cost, schedule), and adjust all of the related project constraints (like resources). Life will be much easier, if you would only change priorities for few tickets in the JIRA Backlog, rather than do all of the unnecessary things mentioned in previous sentence.
Value is delivered frequently, which improves benefits realization
Agile is both — iterative and incremental. We deliver scope (which represents the value) in iterations. Usually, the cadence lasts for 1–4 weeks long. Moreover, we are delivering value incrementally, which means we are building on top of the previously built software.
Iteration
Agile Teams are used to deliver value in iterations. Every 1–4 weeks Business people are meeting with Tech people to discuss work to be developed as well as priorities.
Increment
During each Iteration, the Agile Team is building on top of what was previously built. It is a very important advantage for Agile over Waterfall. One of the biggest issues with projects manage in Cascade manner was final integration. If we didn’t test software integrity between different software components, we can have plenty of integration issues. At this time, the software is probably huge. Debugging different components will take much longer than if it would be done throughout the project. Agile projects minimize this risk, due to the continuous integration and continuous testing. If we have a bug, we have a much smaller scope to investigate and repair.
Benefits Realization
As previously mentioned, value in Agile projects is delivered iteratively and incrementally. Due to the practices of CI/CD as well as continuous testing, a business can assume that after each increment they have a “potentially” releasable product. It is a business decision (usually done by the role called Product Owner), whether to release the increment or not.
Frequent delivery of value allows businesses to realize benefits faster, and approach them incrementally. For example, instead of waiting 12 weeks for the final product release, we can decide that we will release three increments, every 4 weeks. This exercise will allow the Product Owner to gather information from stakeholders, and implement changes if necessary. This approach will de-risk the project by, basically, not developing things that nobody wants. Moreover, the business will be able to charge for the product from the 4th week, instead of the 12th.
Business & Tech people are collaborating closely through the project life time
A very important part of the Agile concept is the constant collaboration between Business and Tech People. Frequent interval planning, review, and retrospectives imply greater communication between those two groups, as well as improves the working environment.
Business people want to know what they can get and by when they will get it. In Agile, this information is managed using Product Roadmap, Release Plans, and Iteration Plans. However, usually, those people do not want to go into details. Therefore, they can’t estimate the effort/time required to deliver, as well as they are not aware of product dependencies, constraints, or limitations.
On the other side, Technical people usually are not aware of what are the benefits of delivering particular software components in a given timeframe. Usually, they are even not aware of the Product Roadmap and lack the bigger picture.
In Agile we are trying to fix it. Frequent collaboration between Tech & Business implies that tech people know what is going on, and Business People have a better awareness of the feasibility of successful project delivery.
Take Away
In this post I shared with my 3 best arguments to convince your Client to work to implement Agile software projects delivery. Feel free share your thoughts in the comment section below!
