If you’re thinking about transforming your organization to more of an agile mindset, your first question is going to invariably be “where do I start?” Should I pick a single team? A single project? Maybe we should just training everybody and go? These aren’t easy questions to answer. Depending on the situation, the right answer for you will be different than for someone else. In this blog post, I hope to provide some guidance.

A transformation needn’t encompass the entire organization. While some businesses have embraced business agility all the way to the executive team (Valve, Buurtzorg), most others have transformed only their service or product development portions of the organization.

Pilot with a Team

Some transformations start very small. A single team, even one carved out of a project with other teams, can be implemented as a pilot team in order to discover what workflows might “break” in an agile environment and require modification. The advantage to this is that management gets an opportunity to identify and correct problems in a constrained space and correct appropriately. The disadvantage to this is that it can take quite a bit longer and is prone to failure when management feels that there are too many workflow problems to make it worth fixing (in essence, accepting permanent sub-optimization in order to avoid the short-term discomfort of adjusting how teams work).

Big Bang Approach

Some transformations are big bang. Entire departments become agile by 1) providing training for everyone involved and 2) building a migration plan arranged along “day one” and “after day one” steps. The advantage of this approach is that it creates a very quick transformation and agile approaches can be used all the way to the management team in the planning, controlling, and monitoring of the transformation. A second advantage is that the organization does not have to maintain two ways of doing business: agile and “not-agile.” This eliminates a lot of unnecessary confusion down the line. The disadvantage is that it can be chaotic for a few days as all of the problems surface. Our experience with this approach is that even the chaos is easily managed if everyone knows what to expect. In fact, at one company, we launched 41 Scrum teams on one project in two days. There were a lot of questions for a couple days, but most of the problems were addressed within the first sprint (the resulting quality of the product was measurably better than previous product releases AND we finished only one week late after eleven months).

Pick a Product or Project

My advice is to lean toward a service-specific or product-specific approach, transforming the teams and groups that will have the most substantial impact on the service providing or product development teams. In other words, perhaps you have four or five product development teams; they would certainly need to be involved in the transformation. However, those teams are also supported by people management, product management, customer service, and possibly program management personnel. All of these people – anyone that provides input to an agile team, supports an agile team, or accepts output from an agile team – should also be involved in agile training.

If your company does contract-based work, select a project with which to begin your transformation. Involve the entire project team (don’t leave anyone out) – all developers, management, everyone.

If your company does product development (multiple releases or continuous deployment) or service provision, select a product or service with which to begin your transformation. Start by training the service providing and product developing teams as well as any other individual or groups that interact with the teams on a regular basis.

Assign products to teams, not individuals.

Be careful when a bunch of products are being worked on at the same time by a small number of people. Too many of our customers try to create an agile transformation around a bunch of independent product developers where one or two are assigned to Product A and one or two more are assigned to Product B, and so on. This situation won’t create a team – it creates a mess.

My rule is simple: assign products to teams, not individuals. If you really want to create an effective agile organization, stop assigning work to individuals – the reality is that most complex work these days aren’t done by a single person anyway, so let’s embrace the complexity.

You can have five teams on one product or one team on five products, but get your organization out of the habit of “assigning” people to products.

Every Situation is Different

As all organizations are different, so all transformations are different. The key is to include the “critical mass” of the product development organization in order to be successful.