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!

img_1372

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

Introducing Self

I am an independent IT consultant, lean & agile practitioner,  passionate about financial & banking software products, methods, processes, teams and organizations.

Logo-pour-zoho--40pct

Since mid 2012, I am practicing software delivery using agile methods and processes and I came to the conclusion that agile goes hand in hand with the delivery of high-quality software systems.
It also appeared to me that many corporates such as large financials need agile. Many of them are undergoing alignment and turnaround strategies in order to generate corporate renewal. In such a context, agile is a perfect fit.

If agility and innovation is at the heart of your corporate strategy, do not hesitate to visit us at http://www.sublimedelivery.com

Introducing Self

Cities and corporations

Here’s where it all comes together: Pollution, climate change, and many of the other perils life faces on Earth are largely the work of companies. Will companies learn to act more like cities and ecosystems—to become adaptable on the longest timescales, to evolve and change rather than trying to make the world bend to serve their interest.

What if financial institutions learn to act more like cities and ecosystems? How would they look like?

Cities and corporations

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.

agile

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

The testing bottleneck

Behavior-Driven Design

With Agile, testing is part of every iteration, testing processes are highly automated,  developers test their own code and QA team members continuously improve testability & tools.

Software quality is the result of good processes & tools

Behavior Driven Design is a full-stack agile methodology that supports such endeavors. In practice however, using tools that implement Behavior Driven Design workflows are intimidating to learn.

To start with Agile however, I find it far more crucial to get first the words right by describing software behavior using the Domain Specific Language (DSL) that comes with BDD. Most of the problems that delivery teams are facing are communication problems.
BDD aims to help communication by simplifying the language we use to describe scenarios in which the software will be used: Given some context, When some event occurs, Then I expect some outcome :

  • The given part describes the state of the system before you begin the behavior you’re specifying in this scenario. You can think of it as the pre-conditions to the test.
  • The when section is that behavior that you’re specifying.
  • Finally the then section describes the changes you expect due to the specified behavior (post-conditions).

BDD enables closer collaboration with users, bankers, developers, testers, programmers, operators, project managers or any other FInTech project stakeholder.

Another interesting use of BDD is to facilitate integration and communication between different distributed systems as described in Ben Mabey’s post Using cucumber to integrate distributed systems and test messaging. His work opens doors with respect to testing strategies of asynchronous systems using Swift, Fix, MQ messaging systems or even distributed ledgers.

So, do not get only the process right, but also the words!

Behavior-Driven Design

Readiness

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.

Readiness