While writing this post, I am on an airplane to Helsinki. Nice sunny city. And lucky for me it is about 50 degrees Celsius warmer than the last time I visited it. In Helsinki I will have look at a couple of projects that use a distributed agile approach, but fail to deliver on-time and on-budget.

When I get back to the Netherlands next week, I will pick up coaching in three different organizations and three very different projects. The first project is all about continuous software product development, with business developers, quarterly releases and multiple configurations of the products delivered. The second one is building a public available service, both for mobile and web, using .NET and Mono technology. And the third project is rebuilding an old customer-facing client-server application in Java, whilst moving towards a service oriented architecture, complete with document management and business process automation. So in merely two weeks I will look at five very different projects, in different organizations, with different targets, and very different issues. But there is one common denominator: they are all trying to be as agile as they possibly can.

All projects great and small

In only a few years agile has moved from guerilla warfare to mainstream. The popularity of everything agile is reaching new peaks. From agile practices such as continuous integration, pair programming, and test driven development, to agile approaches, such as Scrum and Kanban to even open space sessions, agile thinking, agile gaming and a seemingly never ending stream of agile conferences.

Despite the fact that no-one in the agile communities actually claims that agile, or Scrum, or Kanban, is a silver bullet for all projects great and small, many organizations these days move towards agile, based on a firm believe that agile will solve all their problems. And it just doesn’t.

Dealing with x

In my experience, agile approaches only cover a small subset of the topics and issues that projects in the real world will need to address. Simply because most agile approaches merely provide a minimalistic framework to guide your projects, and simply because it is virtually impossible for the authors of agile approaches to provide fitting solutions for each and everyone’s problems.

Very often project teams ask me: how do you deal with x in agile? And feel free to replace x with every issue that your projects have suffered from in the past years. This month x’s for me? Estimating bug fixing, velocity for starting teams, agile and service oriented architecture, agile and building frameworks, distributed functional testing, documentation in Finnish, while developers and testers can’t read Finnish, agile work breakdown, estimating user stories, DBA’s that have too much control, or even how to shorten the time that is required to move from development to test (which is currently two weeks).

So how do you deal with x in agile? If I was a Scrum Master (with or without the dash) my default answer would probably be: it depends. It’s an easy way out. Your audience will continue to believe all wisdom is converged in Scrum, even without offering a real solution. But then again I’m not a Scrum Master. So my answer is a bit different: agile doesn’t cover x.

No tailored solution

Basically, agile doesn’t exist. And even worse, there’s no such thing as the agile approach or methodology. At most, there’s a set of approaches that adhere to a set of principles. And although these agile principles and the approaches that adhere to them will give you a sense of direction on how to solve your specific project issues, none of them will provide you with a tailored solution.

Difficult choices of a businessman

Moving towards agile does never mean that you should stop thinking and go on automatic pilot. Each and every one of your projects is different. They start different, use a different set of techniques, have different teams with different people, serve different clients with different demands, you have different roles in your organizations, apply different techniques and technologies, and projects have different endings.

More than meets the eye

Projects are all different, and thus there is no one-size-fits-all agile approach. You will always have to tailor agile to your organization and to your project. Find out what it is that your project requires, besides implementing the basic agile principles. Figure out how you want to deal with requirements, as user stories could well be an over-simplified technique. Identify how estimation works best for you. Don’t throw out old techniques that your organization has been using for years and years just because they are not mentioned in the Scrum Guide. If your environments don’t match on-click deployment, identify how it can best match agile projects. Identify how to report out to your management best. And try to establish how the roles in your organization could match the way you would like to deliver. What is it enterprise architects can contribute? Or functional analysts? And foremost, make sure your testers now how important they can be in agile projects. Even though most agile approaches don’t mention any of these roles specifically.

To some, these warnings may well be an open door, in that case: carry on. But in my experience, most organizations and projects taking the plunge into agile, Scrum, Kanban, XP, please be aware that there’s so much more than meets the eye.