Tại sao phải hiểu agile là một phần cho business?

• Step 1: Understand typical teams, roles and job titles
• Step 2: Define your requirements
• Step 3: Widen your net with your job description
• Step 4: Where and how to post jobs
• Step 5: Evaluating applicants

We deliver agile training on weekly basis in Wunderkraut. Our training got started many years ago because most of our new customers didn't have previous agile experience, the ones that did had mostly bad experiences from "agile", or what I now days call fake agile. Today delivering agile training and coaching both with and without implementation projects for the same customer is a core part of our business.

There are plenty of other agile trainers on the market, most of them focusing on technical agile for in-house teams. By this I mean teaching agile practices very well but usually missing one point that is very important for many customers: How to use agile in a customer-vendor relationships. Don't get me wrong, there is nothing wrong on what most agile trainers teach, it's just that our focus is slightly different.

The origins of agile are in product development with in-house teams. When agile is applied in a customer-vendor relationship quite a few things change. As a result of these changes agile can start breaking down. We don't want to just accept "enterprise compliant" half arsed agile, so we've set out to fix the situation. We want our customers to enjoy the benefits of proper agile even in customer-vendor relationships.

So what exactly makes customer-vendor agile different?

After coaching customers on agile for years I'm unfortunately nowhere near to having a comprehensive list, but I'll try to summarise some of the most common differences.

Trust, or lack of it

With an in-house development team there's implicit trust in place. Sure, in a dysfunctional organisation employees may not be fully trusted, but in a customer-vendor relationship the vendor is not trusted at all by default. Lack of trust usually manifests itself as different checks and balances, many of these can be really damaging for the agile way of working.

Tadaa - development

Way too often vendors are considered as magicians. There is some sort of plan in place, based on that a request for proposals is sent out, a vendor chosen and that ends the involvement of most key stakeholders. The vendor is expected to go away, do their magic and in the end come back and reveal the completed product in a tadaa moment. It doesn't make any real difference if the vendor does agile behind the scenes or not, the only way to get a real difference is to have heavy involvement from all key stakeholders during the entire project. This would not happen with in-house teams, but for some reason it's still expected in many customer-vendor relationships.

Open season for agile: Procurement and legal

When legal departments and procurement of large organisations get involved agile is often hunted down actively. I've seen exceptions to this rule but frankly they are few and far in between. Naturally this is just one of the manifestations of lack of trust. Trust is replaced with contracts and any real agility killed by fixing everything in contracts. This is the way procurement and legal is taught to protect an organisation, in agile it can turn against the organisation and cause great harm by causing projects to fail.

Not-so-fixed teams

When agile is done internally the team rarely changes. This can be very beneficial for the productivity of a team and makes improving the performance of the team much easier. You'll learn this is a great thing in your scrum training. And it is a great thing indeed, but there is always some room for improvement. With an external vendor flexible resourcing becomes much easier. Bringing in external experts for some parts of a project, adjusting the team size to help the product owner keep up with the velocity and access to external coaches are just some of the new opportunities in customer-vendor agile.

Spreading best practises between agile organisations

Scrum of scrums or other similar practises can be a great way to spread the best practises in an organisation. Spreading best agile practises between tens or hundreds of organisations is however something very different. Using an external agile coach is one thing, but two agile organisations working together is really something different as far as learning goes.

Quick projects with a large impact

A traditional Scrum team is 5-7 people working together for a long time. In a customer-vendor project the team is often smaller and the project shorter. The team doesn't have all that much time to go from forming to performing and beyond. Most our projects go from the start to first live deployment in two or three months. The cooperation between the customer and the vendor lasts years, but the team size and composition changes based on the needs. This makes it much more difficult for the team to improve and requires different kind of support for the team.

Training to the rescue!

We really can't fix any of these problems on our own. In a relationship with two parties it requires both parties to fix issues and capture the maximum potential of the cooperation. The only way we can get there is to provide training for our customers.

The core of our training is pretty identical with any other high quality training on agile. We cover the whys and hows just as any high quality trainer should do. On top of this we also dive deep into the issues and potential in an agile customer-vendor relationship. We find this easy because we live and breathe this world every day. Taking this approach has so far been very successful both for our customers and for us.