June 17, 2015
Get in touch
Last week someone who had read my article about agile companies asked me how we at AOE manage to live this agile culture while being able to thrive economically at the same time. It's no secret that project work is difficult - driven by deadlines and stints. Surely, self-determination and corporate democracy don't really fit in such an environment, was the objection. Of course this is true. Which means that the time has come to explain why we don't consider ourselves to be an agency and why we think that projects are only a stopgap solution. And what our business model is and why I think it is a groundbreaking model for the digital economy.
The truth is that we simply aren't that good at project-based work. Of course it's not the case that we don't implement projects successfully; but, if we compare ourselves to companies in the U.S. that complete two to three mid-sized Magento projects a month as a matter of course, our skillset when it comes to fixed-price projects is rather limited. And that's ok.
The reason is that our business model, which isn't based on projects but rather on customers that work together with permanent teams on the clients' strategic platforms over long periods of time, is unique. Here, we can justly claim a leadership position; we are able to deliver on the potential of this business approach like no other service provider in the web development market.
Therefore, we aren't looking for projects but rather for customers. Customers who are asking themselves whether it's better to establish internal web development departments or to look for an external partner for support. Customers who are building large, strategic platforms and release new functionalities every two weeks once the first Minimal Viable Product has been launched.
For us, therefore, a project is only a bridge to create a long-term relationship with the customer. A first joint attempt that is designed from the outset with the "big picture" in mind: Our aim is that the project team continues to work for the customer, if possible within the same or larger scope.
Whereas we were reluctant to communicate this approach to potential customers a year ago, our mindset has since matured. Two weeks ago, for example, I visited a potential customer with Kian Gould, the CEO and founder of AOE. We spent the morning discussing requirements with the customer's representatives; we talked about how we put teams together, that we would only accept T&M as a contract and that, in our opinion, the customer should contract the team for two years. Suddenly, Kian exclaimed:
This was pretty daring, at least from a traditional sales point-of-view (after 10+ days of preparation, four-hour flights and a more-or-less sleepless night in a hotel room...), but it was honest. And, after a moment's silence (that actually felt much longer), the customer dealt with it with aplomb. And then we introduced the details of the concept:
We believe that a good team is the most important success factor for a project. The team must possess the proper skills, it must assume responsibility and it must provide services to the customer with enthusiasm. But, it must also have a life beyond work and maintain good team spirits. This isn't anything that can be assembled on-the-fly and it's nothing that can be perfected in three or four months. Our best teams have been together at least six months. What we can observe here regarding output, quality and velocity is without peer. And, these teams aren't working on one project with a fixed timing and scope, they are working continuously on one platform. How this platform is further developed is decided by the customer - and it isn't uncommon for the team to also impact this decision in one way or another.
The team model only works, however, if one uses agile processes. And this is where our second strength comes to bear; our agile work is aligned exclusively with Scrum. Our teams (no larger than eight people), work on clearing the backlog of user stories in sprints defined together with the customer and, as a rule, release new functionality every two weeks. In this way customers are able to define which features they want and which pace they want to go themselves. In our opinion agility is a critical factor for successful digital transformation. We provide our customers agility with the "Method" and, needless to say, we train our customers and ensure that agile processes are correctly implemented - for we have rarely found that truly agile development takes place, usually we just see Waterfall with standups and retros.
In traditional Internet agencies T&M billing, that is invoicing time and material, is therefore the most-desired scenario. One imagines that one can invoice absolutely everything and a project is automatically profitable. To be honest, I think that really romanticizes the whole issue. The customer usually views this as billing according to effort expended with a cost ceiling. Agencies are held just as accountable as if they were operating with a fixed-price contract.
Team & Method is no blank check - and shouldn't be. After all, we want to be successful with and for our customer. It is always a cooperative effort.
Rather, Team & Method allows the customer to develop large, complex software products and benefit from a well-established team and clearly calculable costs. We therefore simply offered the above-mentioned customer a team of eight people for a period of 18 months. This is the timeframe we consider realistic to implement the product in all release stages.
That the customer will then do exactly that with the approximately 2,800 person days is unlikely. Rather, the customer will more likely find out along the way that features other than those originally recorded in the specifications are more important. And, thanks to "Method", the customer will be able to implement them. All of this without new contract negotiations or change requests or big and long planning meetings. He will simply do it with the team. And save money along the way; our experience shows that in traditional fixed-price projects with teams of six to eight people, one person is needed almost entirely for contract coordination. In the "Team & Method" model this team is saved almost completely, meaning that it is available for actual implementation.
Many will say that it isn't possible for them, because they don't have any large project inquiries. In some ways that's true, of course. A new team always needs a certain Storming Phase. But, this is no different from the traditional project business.
For us as a software service provider this business model is an asset. We achieve far more stability in our business than our competitors through long-term contracts. By focusing on our customer business instead of on project processes we are able to develop long-term customer relationships. A customer is very reluctant to disband a team that provides him with numerous benefits. Essentially, this is the driving force behind our strong, above-average growth of the past years. And quality, unconditional quality.
At the same time I think that our model can be a game-changer for the entire industry. There is far too much quick & dirty and far too many employees are burned. The customer is the one who always suffers, as the agency somehow always remains profitable, and employees simply change jobs. But the customers are left along the way: with pallid projects, solutions that can't be developed further, insecure platforms.
I think that this is also a pioneering model because it always creates three winners; for one, the customer who, through the freedom of an own team, can build solid platforms, the employee who can do a good job in an exciting and stable social environment and the agency, which can operate in a far more stable economic climate.
I am convinced that one could implement this model in agencies with smaller customers, as well. After ten to twenty years of project-based work such a fundamental change is difficult. For us here at AOE I can state that we are currently well on the way to accomplish this change.
