How we stopped doing projects and invented "Team & Method"

I get asked quite regularly how AOE manages to live an agile culture while being able to thrive economically, all whilst working with some of the biggest corporate entities in the world that are not exactly what you would call agile organizations. It’s no secret that project work is difficult – driven by deadlines, pressure and impediments. Surely, self-determination and democratic decision-making don’t sound like a sound fit for such projects in these organizations.

I thought it would be a good time to pronounce more publicly why we invented the “Team & Method” approach to tackle this obvious conflict of setup and how this has led us to an incredible success rate in our customer relationships.

Frankly, the truth is that complex and innovative projects are more likely to fail than not when done in a waterfall approach and based on a fixed price tendering/RFP process. The mere definition of a digitalization project to me is absurd. Digitalization is a strategy, not a project. And, it is never complete either. Moreover, for a strategy you need a partner, not a vendor.

Strategic parternships instead of projects

We try to avoid projects in general. Don’t get me wrong, any partnership starts with a project and develops into something bigger, given the right circumstances. However, we only start projects if we see potential for a real, long-term strategic partnership. The reason why we choose this approach has a lot to do with the way we build and foster teams. We don’t body-lease, we don’t shuffle teams together for every new project. Instead, we build long-term, agile Scrum teams that stay together for years in most cases, have under two percent fluctuation in staff and are therefore able to deliver a performance to our customers that is second to none. Anyone who has ever had to build a development team knows that it can easily take up to six months for a team to move through the phases of storming and norming into performing. We do this only once and then those teams stay with one customer for a very long time, or we move whole teams from customer to customer in their entirety, depending on the amount of teams needed in any given phase of the project.

What we can ensure in this way, though, is that when we start a new engagement we have real teams available, that know exactly how to work, communicate and design, build and run major digital infrastructures. None of the big 10 IT providers can deliver anything like this. While we were reluctant to communicate this approach to potential customers a couple of years ago, our mindset has since matured. It all changed exactly two years ago when we visited a potential customer for the first time. We spent the morning discussing requirements with the customer’s representatives; we talked about how we put teams together, that we prefer to work agile and that we don’t think we can come up with a realistic fixed-price that would make sense. And then I suddenly burst out:

Projects at this scale lead to bad products, to a lot of frustration and a very long time-to-market. This is not what you want. What you want is a team that implements project iterations efficiently and successfully. Launch, test, adapt etc.

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, for the first time, we introduced the details of the new concept to the world:

T as in Time Team

We believe that an excellent 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 spirit. 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 for at least two years. 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 solution. The customer decides how this platform is continuously advanced – and it isn’t uncommon for the team to also impact this decision in one way or another.

M as in Material Method

The team model only works, however, if you use proper agile processes. This is where our second strength comes in; 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 in projects called "agile", usually we just see a more flexible waterfall approach with stand-ups and retros.

However, for us “Method” includes more than just agile Scrum. It entails highly trained cross-functional teams that are actually capable to not only develop, but can also take the customers through all the stages of design, deploy, build, and run, and can scale as multiple teams rather than grown teams. Our biggest customer teams consist of seven dedicated Scrum teams that work year-round based on these principles.

This of course requires a lot of training, knowledge sharing, stack experience and breadth of skills. Something we foster through numerous measures from personal training and conference budgets to communities of interest, developer evenings, pair programming, etc.

A New Definition of T&M

The classic model of Time & Material has received a lot of scrutiny by purchasing departments and stakeholders alike. Time & Material carries many problems for the customer, which I am not going to name at this stage, as they are quite universally known.

Team & Method is no blank check either – and shouldn’t be. After all, we want to be successful with and for our customer. It is always a cooperative effort. So, whereas in Time & Material the service provider tends to just try to get as many people billed as possible, with limited interest in getting things done efficiently, things are different in the Team & Method approach. Here, we are essentially paid by sprints, and as each sprint has a clear backlog and outcome, we track velocity over time. Continuous customer reviews are also part of the process; the customer has every possibility in the world to see how efficient his AOE team really is.

So in essence, 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 aforementioned customer a team of eight people for a period of 18 months. This is the timeframe we consider realistic to implement the initial solution in the first three release cycles and it turned out to be a hugely successful project on all sides.

The probability that the customer will then actually develop the exact solution he envisioned during that meeting with the approximately 2,800 person days is quite low. 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 large and long planning meetings. He will simply do it with the team in a bi-weekly, efficiency-driven continuous process -- 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, change request, scope and billing management. In the “Team & Method” model, most of this wasted time can actually be used towards actual implementation and results.

Win-Win-Win Situation

I am a strong believer that our Team & Method approach will over time re-define how the classic customer-agency or customer-integration provider relationship works. This is also a pioneer model because it always creates three winners:

1. The customer: who, through the freedom of a dedicated team, can build solid platforms,
2. The team member: who can do a satisfying and productive job in an exciting and stable social environment,
3. The service provider: who can operate in a far more stable economic climate.

There are two factors, which, in my view, are the biggest testament to our success with this approach; our customers that work in such a mode tend to stick around for five to ten years on average, and AOE has what is probably the lowest staff churn rate of any digital services provider in Europe at under two percent per year. Please challenge me on that!

To show you one example of this collaborative, long-term strategic approach, we recently produced a video together with our partner congstar, with whom we just celebrated our tenth year of agile collaboration. Six Scrum teams work for congstar on a continuous basis and a beautiful proof of the success of this relationship is that, due to its technological superiority in customer self-service, congstar has been voted “mobile carrier of the year“ for the seventh consecutive year in 2018.

If you are interested to find out more about our agile culture and agile teams we have plenty of information on our website at www.aoe.com and our blog.