From Doing Agile To Being Agile
Agile is a buzzword. We feel that we miss out if we don’t become agile. So we say that we are agile, that we follow scrum
, that our processes follow agile.
The true meaning of agile is flexibility. As opposed to rigidity. This can refer to the process we use as most companies understand it. But it also refers to people. An agile process cannot work without agile people.
Especially if part of a team is offshore, the agility of behavior is fundamental. We need to cultivate understanding back and forth (of the remote colleagues, of it culture, of why people behave the way they do
). And we need flexibility in dealing with the (cultural) difference we understand. Instead of forcing our own value system and expectations upon ‘the others’, we need to flexibly adapt our own behavior to the new situation. We can also discuss the behavior of the other team members in order to get all on the same page.
From Fixed Price To Sprint Based Payments
Most companies start their offshoring endeavor with fixed price projects. Most managers expect fixed pricing from their vendors, because they get a budget and need to fit their projects into that budget.
Agile/scrum and fixed price don’t go along very well. I would even say a pure fixed price agreement cannot work in an agile collaboration. The premise of agile is that the team flexibly builds the software the company needs (as opposed to what they envision at the start of the project). Sprint by sprint, the team determines with the product owner what needs to be built. Based on what has been built and user feedback, what gets built eventually might be 80% different from what was envisioned at the start.
So the agreement has to be more agile
. What can be given is a scope of a project, based on the initial understanding. The team tries to deliver as much value and functionality within that scope. The buyer is in the drivers seat in determining what gets built each sprint. The scope is fixed, the functionalities are not. And payments can be done based on the sprint’s result. This means we can invoice the time spent. But it can also mean that the invoice contains the % of user stories that have been completed. If we have 100 story points in the next sprint and 80 get done, the invoice contains 80 story points (and a price per story point can be agreed) or 80% of the time spent. 20% was lost. If there are buyer and vendor, they could decide to share the 20% ‘loss’ 50-50. If there are third parties, it could be shared equally.
I believe this is the way forward in software development in general and in offshoring specifically. It applies to software, but can also be adjusted to other types of work. Payment on results. The risk is equally shared. Interests are aligned.
From Shipping To Partner To Collaboration
The old model of IT services is a black box approach
. A buyer sends the requirements into the black box of the vendor. The vendor ships the product exactly as specified to the buyer. The buyer pays. In some collaborations this way of working still works. But as we’ve seen in the past decades, many IT projects fail and I would argue that the shipping to partner mentality is the main cause.
What is needed is true collaboration. We’re human beings trying to build something together. There is no you and me, but only us. We may be part of different companies, but our interests are aligned. With this mentality, a true partnership can develop. Partners can for example sell each others products back and forth in their respective markets. They can co-develop products they bring to market. The vendor builds products with the goal of making the buyer more competitive, make them save costs, win in the marketplace.
In offshoring, this mental change is fundamental. As the people doing the work are geographically and culturally distant, ‘collaboration’ is needed to bridge this distance.