We’d like to introduce an extract from our newest session booklet – Adapting Agile. It looks at how to create customized and hybrid development processes that work for your organization. This forms part of our VFQ & Agile Learning Pathway.

Not all problems, circumstances or contexts are the same – so no framework is one-size-fits-all. If the methodology was written to take account of your precise circumstances then it wouldn’t be applicable
to anyone else. No wonder then that organizations need to ‘adapt’ Agile – what really counts are the underlying patterns and principles, not specific practices.

But – and it’s an important but – nobody likes change. Which means that all too often we see people adapting Agile, not because they need to tailor practices, but because they want to avoid changing the behavior that made them implement Agile in the first place.

We wanted to preface our coming blogs on the underlying patterns of Agile with a long hard look at whether you truly need to make adaptations in the first place.

We’ve given three examples that we have often heard presented as barriers to a ‘strict’ Agile implementation:

1. Agile emphasises interactions over documentation, but we exist in a heavily regulated industry. We have to provide extensive documentation as part of our governance in order to ensure that we are meeting our regulatory requirements.

2. XP recommends designing as you code, but we have an extremely complicated data structure. We need an extensive architecture in order to make sure that the different databases are properly linked and can be used with the many external systems.

3. Scrum demands small, co-located teams, but we work across several countries. We have a development team in India, a management team in the US and a design team in Europe. It’s not possible to co-locate these people.

Let’s look at each problem in turn.

Documentation is required

The question here is not that Agile rejects all documentation, but that it believes interactions are more valuable. So creating documentation should not be at the expense of personal communication. Plus we should think about the kind of documentation required.

Many developers point out that the best documentation is the code itself. Well-written, carefully refactored code ought to be self-explanatory. This can be tested – bring a developer from another team in and ask him to read the code. Does he understand it? If not, is it because you need to make the code clearer? If the problem is in the code then rather than writing a document to explain it, you should first clarify the code.

If you are trying to explain the software’s purpose to a non-technical person, then most code documentation is not going to help either. A short description of the software’s purpose will help more, along with the acceptance criteria that prove whether that purpose has been met.

Hang on! We needed to create those anyway in order to develop our product in an Agile manner, and we updated them as we clarified our purpose using feedback… so do we actually need anything else in terms of documentation…? Hmmm.

Architecture is required up front

Once more the question is not whether some architecture is required but how much. End-to-end functionality, however minimal, requires decisions about architecture.

In XP, a walking skeleton provides this framework. This basic architecture is a direct result of writing tests before coding. Writing tests does not mean a lack of design, in fact it tends to mean more rigour in the process. For example, if the minimum functionality required six databases to be connected, then the walking skeleton would reflect that. But if a small unit of functionality could be achieved with only two databases connected, then the skeleton would begin with just two. In the process of creating the skeleton, you might learn something important which would change the type of connection you use. You gain this learning more cheaply than if you had developed the entire architecture first.

Disparate teams

Let’s consider the point of co-locating a team – the quantity and quality of spontaneous communication. When we have a team in different time zones we make it harder for them to be in frequent touch, we make delays and mistakes more likely and so we ought to factor in the expected waste caused by miscommunications. How important this is depends very much on what type of project you are running.

If you don’t need your team to communicate informally and frequently, then you can get by with installing video conferencing, web cams or running Skype on everybody’s machines. If you have a highly creative project with many uncertainties then you might need to pay for regular face-to-face meetings – at least at inception and before or after important milestones. When you calculate the costs of doing this, you may find yourself questioning whether you could actually co-locate the team. At any rate, by looking at the problem fully you can stay focused on the principle of spontaneous communication – even if you have to drop the practice of co-location.


Adaptations depend on understanding the underlying principle behind each practice. As long as we satisfy the principle, how we do so is open to debate and any number of creative solutions. We’ll examine what Emergn believes are the underlying principles in a coming series of blogs. But it’s always worth asking yourself whether you really need to adapt a practice, even if the answer is uncomfortable.

Recommended Posts
  • Niall Barry

    I think the points are well made, particularly the documentation one. I’m not sure I’d fully buy the Architecture argument, though. I think it depends on scale. If we are talking about architecture at a mid to large enterprise level, then we’ll need some service outside the agile team itself to provide general direction/constraints/vision to the team so that detailed design can take these into consideration. This is why, in DSP, we have an architecture group and a modelling function.

Leave a Comment