Be happy! Use Agile even with external partners!
When looking at the definition of Agile frameworks like Scrum, it is clear that they are really meant to be used within single organizations. Organizations that either work with their internal IT department, or even better have parts of their IT embedded in the normal business. And while the benefits of working in an Agile way are very clear, most organizations find that it is very hard to extend this way of working to a situation where you work with external partners.
The main difference between “internal” and “external” is that there is an implicit trust of the internal resources, but a distinct distrust of external parties. We trust the people we work with, but distrust those external companies that will bill us for every last cent.
Whether or not this feeling is justified is beyond the point, but the feeling persists almost everywhere. The “remedy” is almost as universal: iron-clad contracts that explicitly specify what the external party is supposed to deliver, when that should be, milestones and often even penalties for missing deadlines. Now let’s count the number of Agile Values that we are violating in this way. I will do it for you: 4 out of 4. No way you can successfully work in an Agile way with an external partner this way.
So, how do we solve this? At Luminis we face this situation daily. We want to help clients achieve their goals and believe that software it the most important asset they have in achieving those. We want to work together with them to help them succeed, we do not want to be in a position where we delivered what we promised but that turns out to be the wrong thing. In short, we want to be Agile and work with the client not against the client as is the case in traditional software development.
The start of the solution is to explain a few things to the client:
1. Whatever you write down in your iron-clad contract is going to change. You know before you start that what you write down will be obsolete before the project ends. At the end of the day, do you want what you are going to write in the contract or something that will solve the real problem?
2. Agile, more specifically Scrum, is not “do whatever you like”. It is agreeing per sprint what should be delivered, checking after (most often) two weeks, learning and improving all the time. You will never hear at the end of a project that there is a problem, you will hear it after a few weeks. This improves your control, and does not reduce it.
3. Working Agile gives you control (previous point), but also means that you are able to change, extend, or reduce the scope at any point. You are the final decider on the backlog, you decide the priority nobody else. You can change your mind at any time. And if there is a blocking problem that means the project should not proceed, you can get out also.
While it may seem that working in an Agile way means less control and more uncertainty, after all scope is going to be variable and the team decided what they can do, that is not the case at all. You gain control by frequent checks and you gain control by the flexibility of managing the backlog. Sure, you may not get what you wanted at the beginning, but you surely will get what you want at the end. The only “but” here is that you have to have a certain amount of trust that the external partner you work with is really going to do their best to help you. But ask yourself: if you do not trust in that, should you even work with that partner? Given that basic trust, working in an Agile way gives you a lot better chance of success in the end.
There are a few ways to gain this level of trust. First of all, any client is free to talk to previous clients and get to know from them whether or not we are trustworthy. But secondly, we actively try to get at least one internal IT person to join our team. That person has inside knowledge of what we do and can therefore check whether we are really doing as we promised.
Another frequently heard objection is that the specifications are not done at the beginning (and we do not want them to be!), so the Product Owner needs to spend a lot of time during the project and he/she does not have the time to perform that role. We mostly counter that by using a delegated Product Owner; one of our analysts and Agile experts that performs the daily interaction with the team. While they are with Luminis, they act as though they are part of the client company even if that conflicts with the interests of Luminis. The delegated Product Owner frequently communicates with the real Product Owner in the client company regarding specifications and priorities. This way the internal Product Owner remains in charge and control, but most of the day-to-day work is delegated.
To sum up:
• Given basic trust, working Agile with external partners has a lot of advantages
• Gain trust by talking to previous clients, and try to have one team internal team member join the external team
• Delegate the day-to-day tasks of the Product Owner
We find that by using this structure we are able to really cooperate with our client, and together make the client successful.
