Doing Agile versus Being Agile

Share on facebook
Share on twitter
Share on linkedin
A lot has already been written on the difference between “Doing Agile” and “Being Agile”.“Doing Agile” boils down to using the agile terminology, because everybody should be agile, but in fact doing business as usual. “Being Agile” is however implementing a new culture, backed-up by a vision and a consistent set of practices.

The latter is usually linked to organizations with more success stories in digital transformation. Still as developers we encounter a lot of companies that are merely “Doing Agile”.



The first anti-pattern is the presence of “Product Owner Proxies”. Usually this is justified by the fact that domain experts in the business have little time for developing new digital capabilities (aka software). So we add business and functional analysts to “capture” their wishes and knowledge – and of course consulting companies like this. However this action introduces multiple indirections via documents and thus lengthens the feedback cycles from “idea” to “deployment” of a new digital capability.

Extensive documents with requirements and large use cases are the indicators of this anti-pattern. The right pattern is of course using practices that enable communication between domain experts and developers. Should we then get rid of business and functional analysts? I would argue not, but their role has to change. They should be focusing on helping the domain experts and the developers to write and prioritise user stories and engaging in DDD (Domain Driven Design). This is an enabling function.


Another anti-pattern is the presence of a series of architects from enterprise architects to solution and infrastructure architects that produce documents with a lot of schemas, detailed constraining rules and in-house standards. Again these activities are aimed at constraining and controlling development teams and tend to lengthen the feedback loops. Architects are needed to encapsulate, carry and communicate the vision and basic principles, but these principles should be there to enable the development of digital capabilities, not to restrict them. Consequently, workshops and working together in the product/service teams are then more useful.


A third anti-pattern is the orientation of project-leaders and program-managers on micro-steering activities and traditional reporting on budget consumption like percent work remaining. Yes budgets are important but also the value one gets for one’s investments – later more on agile estimations and planning. This is better served by enabling teams to work and focus on the right requirements, taking away barriers and installing feedback measures that relate directly to the work being done.


Actually “Being Agile” ultimately will lead to some reorganization in your company with a strong orientation on integrated, multi-functional and empowered product/service teams responsible for a product/service from its inception to actually running it daily in the digital world.

This is what DevOps (BusDevOps?) is all about and it shortens feedback loops!

A product/service should be built and supported by one and only one team. Yes one team can support multiple products/services but that depends on the criticality and the size of the product/services.

Within these teams focus will be on agile practices as advocated and supported by practices known for more than a decade now. See eXtreme Programming (XP)-practices like:

  • Fine scale feedback
    1. Test Driven Development via Programmer Tests and Customer Tests – Unit Tests & Acceptance Tests
    2. Planning Game
    3. Whole Team – Onsite Customer
    4. Pair Programming
  • Continuous process rather than batch
    1. Automated Continuous Integration/Deployment
    2. Design Improvement – Refactor Mercilessly
    3. Automated Small Releases
  • Shared understanding
    1. Simple Design – Do Simple Things, You Aren’t Gonna Need It, Once And Only Once, Simplify Vigorously)
    2. System Metaphor/Vision
    3. Collective Code Ownership
    4. Coding Standard – Coding Conventions
  • Programmer welfare
    1. Sustainable Pace – Forty Hour Week

So I find useful to (re)read the goals of agile practices and meditate on their usage in a concrete environment and learn how to improve one’s way of working.

In the next blog I will reiterate on the origins of “Agile” and then we are ready to dive into the practices.


Wouter Adriaens

Leave a Reply