The X-Team Spirit

Ladies & gentlemen,

AIGLU launches its first Playground. Come and discover serious games or fun workshops in a welcoming environment around Agile Values, October 3 @ 17 h 45 – 20 h 00 at the BGL BNP Paribas Business Center venue.

We will experiment a new game designed by Per Lundholm and Mia Kolmodin at Crisp: the X-team Silos Game – getting in T-shape!


This game is about the cultural shift from expertise to collaboration (and for those who have read Micheal Sahota’s ebook “Working with organizational culture”, you will certainly recognise the mechanisms that are at stake).

If you want to understand why you have to get rid of your silos or if you want to have some fun at the BGL venue, do not hesitate to join us and to subscribe to the AIGLU workshop. 

We’re looking forward to seeing you there!

The X-Team Spirit

Technical debt

Technical debt occurs when system’s “viscosity” makes it more and more difficult to add functionality cleanly or to upgrade easily.

If you don’t repay your technical debt, it grows:

  • If technical debt is not repaid, it accumulate ‘interest’ making it harder to implement changes or to upgrade the system to more recent versions.
  • The “uglier” the system gets, the more error-prone and time-consuming it is to refactor your system.
  • When technical debt remains unaddressed then it will generate entropy where the system might totally decay over time.  This in turn might lead to the radical “big bang” replacements requiring huge monetary investments. Don’t let it grow unless you want to pay more in the future.

Furthermore technical debt restrains flow. It merely slows down your software delivery process. So, avoid it right now and fix it so that you can accelerate.

Technical debt

The testing bottleneck

When projects have long acceptance tests periods due to dismal code quality and when there are never enough testers in the team to get the work done you almost have no other choice then to alleviate your testing bottlenecks as follows:

  • Have developers to do the work of testers instead. Not very popular but extremely efficient. Priority is given to the old stuff to migrate in production before developing the new stuff.
  • Implement testing tools and scripts to ease testing.
  • Automate tests.
  • Continuously improve testing processes.
  • Build a Test Craftsmanship Community within your organization.
  • Hire more testers.


To make a long story short: build less but build it stable!

The testing bottleneck


I was recently asked by a top manager of a well known universal bank what kind of projects are most suited to be delivered in agile mode.

To my mind, an approach for selecting the most appropriate projects is to assess the readiness of delivery teams through the introspection of key agile enablers. I like to use the term of “readiness model” rather than “maturity model” as it sounds more appropriate when starting with agile.

The model suggests that, next to intrinsic agile enablers, there are also roadblocks ahead that go beyond project responsibility.  They relate to transverse subject matters such as infrastructure and organizational settings. Without addressing them from the early beginning, it is far more likely that delivery teams will not get on board.

1.  Infrastructure & organizational subject matters

An agile enterprise transformation implies new roles & responsibilities, new governance models and requires foremost working with organizational cultures…the top #1 challenge in large financials.

In addition, infrastructure pain-points (or, let’s face it, dramas) related to test environments, release management, source control, branching strategies and deployment processes will require increased focus, lots of improvements and huge investments.

All of these subject matters, whether they are related to your infrastructure or to your organization, should be addressed to a dedicated task force. Such an agile task force is an internal expert team, that guides and energizes the transformation effort by removing roadblocks and by creating energy and excitement for the change.

2. Intrinsic key enablers

Delivery teams can than assess, according to their current knowledge of agile, the readiness of their projects according to 10 fundamental questions. The score of each question is summed up to give a global scoring from -20 to +20  as shown in the figure below. cursor

I find it crucial to discuss these key questions collectively with your team. The aim in view is  to obtain a consensus about a global scoring:

  1. Are upfront specifications required?
    [-2 = always, -1 = mostly upfront , +1 = mostly just in time, +2 = No, specs are only done just in time]
  2. Are business stakeholders identified and available?
    [-2 = unidentified, -1 = unavailable, +1= sometimes available , +2 =always available]
  3. Is change a common place for the system?
    [2 = Never, -1 = Rarely,  +1= Sometimes, +2= Frequent changes]
  4. Do you think that your current software tools are adapted for agility?
    [-2 = No, -1 = Not really, +1 = More or less, +2 = Yes]
  5. Are project teams and business stakeholders co-located?
    [-2 = Different countries, -1 = Different cities, +1= Same city, +2 = Same building]
  6. According to you, are the coding skills of the team sufficient?
    [-2 = No not at all, -1 = Not sufficient, +1= Intensive training required, +2 = The craftsmanship is right]
  7. Is the system subject to banking regulations?
    [-2 = Yes -1 = Quite yes, +1= Not so much, +2 = Mostly irrelevant]
  8. Is the team experienced in project delivery?
    [-2 = No, -1 =Not really, +1 = Some are experienced, +2 = Yes, team is very experienced]
  9. Can the system benefit from short delivery cycles and frequent releases?
    [-2 = No, -1 = Not really , +1 = See some benefits, +2 = Yes, Continuous delivery is what we need.”]
  10. Is the envisioned architecture of the system flexible?
    [-2 = No, -1 = Not really, +1 = Quite flexible, +2 = Flexible]

These questions are inspired and adapted from a popular software engineering textbook (Sommerville 2010). I find it striking to see how these questions relate to the underlying agile values & principles.

3. Readiness of delivery teams and their projects

We consider that projects that have a score equal or above 10 are “agile enabled”. A score under 10 means that the conditions are not met to succeed with agile.

Here below you will find a project portfolio where 4 out 12 projects will take the agile journey.

readiness levels

In the diagram we have also represented the coaching effort. It’s a Fibonacci scale with values like 0, 1, 2, 3, 5, 8, 13, 20, 40 and 100.

It merely shows that the coaching effort is inversely proportional to the readiness of delivery teams…and yet…agile coaches are indispensable change makers you cannot miss.