⏱ Estimated reading time: 8 minutes

Table of Contents

Developers and managers: creating trust in an Agile context

By Bastien Gallay, Agile coach @ Upwiser

Developers

Developers like managers have ideas they cannot always explore at work. Test-Driven Development and Pair programming are two of these.
Recommended: “The Expert” YouTube shorts

Amongst developers, the turnover is very high [Statistics origin is unknown]:

  • 71% of them leave because their salary is not competitive enough;
  • 58% of them leave because they do feel recognized enough for their job;
  • 58% of developers would trust a complete stranger more than their superior!

In addition, new types of jobs join the IT realm: mathematicians become data scientists, ergonomists become UX designers, etc.

Only 36% of IT projects are delivered on time. Some companies add more supervision, others more resources. Though, this reduces decision capacity.

The disagreement triangle

   Scope
  /\   
 /  \-- Estimated project
/    \  (Our baseline)
------ 
|      Cost
Time

           Scope
          |
          /\
         /  \
        / /\ \
       / |  |---------- What has been sold (Scope +, Time -, Cost -) 
      /  //\\  \
     /  //  \\  \
    /   +    +   \
   /   /|    |\-------- Estimated project
  /   / /    \ \   \ 
 /   / -------- \   \-- What has been delivered (Scope ++, Time ++, Cost ++)
/    ------------    \
-----------------------
|                     |
Time                  Cost

Agile

Agile is an empirical methodology which manifesto has been officially written in 2001. The four values mentioned in the manifesto are:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

In all of this, Agile is meant to reduce the failure rate and increase the success rate of projects. This philosophy is not magical and not practical for projects of all shapes and sizes, though. Specifically, engagement and communication is what makes projects feel better.

The Delegation Poker

This exercise will simplify the process of decision making by distributing the tasks. The deciders have to agree on set rules what is their most appropriate level of delegation

  1. Tell: I will tell them = I will do it
  2. Sell: I will try and sell it to them = I will teach you
  3. Consult: I will consult and then decide = I will hear your input and decide
  4. Agree: We will agree together = Let’s decide together!
  5. Advise: I will advise but they decide = I will help you in your decision
  6. Inquire: I will inquire after they decide = I will ask questions after your decision
  7. Delegate: I will fully delegate = You will do it

The Lean coffee

The Lean coffee is an exercise meant to speed up meetings, make them more productive and allow everyone to contribute. Like most meetings, a Lean coffee will start with an objectives and key points review. After this, meeting attendants will vote for the points that matter the most. The most important topics are then tackled one by one with a thumbs up / thumbs down vote after the end of each five-minute session to decide if the topic is worth discussing further.

The advantage of such a solution is to prioritize the sensitive points of the meeting, allow everyone to have a voice and allow for post-meeting discussions with the people who wanted to prolong the discussions to understand why they wanted more time.

Always try to include managers into the steps of your project. Your project exposes several layers of super-tasks: Todos < Days < Features < Iterations < Versions < Products < Portfolio < Strategy. Each of these layers exposes its own objectives with people accountable with the success of those objectives. Intel and Google successively thought about the organization of of what is called Objectives and Key Results.

Additional tips and notes

Do not hesitate to use checklists to track what has been done and what has been completed.

In a professional context, Trust can be expressed as the following formula:

         Cr + Re + In
Trust = --------------
              SI

Cr: Credibility. What your CV and your experience says of you.
Re: Acquired responsibilities. Grows with your stay in your positions and in your career.
In: Intimacy. Your good relationships with your coworkers.
SI: Self-Interest or Orientation. Simply put, your interests.

Here is a standard team efficiency model for a project:

                      --------->
                     /     |
                 ----      Improvement
Training        /
|            ---
|           /-------- Normalization
|          /
|         /
----     /
    \___/
      |
      Conflicts

How to start working with Agile: Start with a pilot project, experiment, make sure both parties (client and internal) have expertise and that the teams are both ready and in agreement.

Knuckle: Automating frontend CI

By Guillaume Amat, Frontend architect @ ekino
Knuckle

It is common to follow the DRY - Do not Repeat Yourself - rule to avoid one of the most common causes of technical debt: code duplication. The problem: why does this principle does not apply to project configuration, duplicated from project to project. With such a tool, you could:

  • Auto-generate the configuration
  • Auto-install dependencies
  • Auto-update your dependencies

Knuckle currently supports the following tools: Prettier, ESLint, TSLint, CommitLint, Husky, Lint-Staged.
About CommitLint: this tool auto-generates your changelog by requiring developers to follow rules when they commit.
Next up: Support for StyleLint, Jest, an actual eject, an add wizard and audit. Do not hesitate to contribute to support your favorite tool!

Installation

The installation of Knuckle is strictly identical to ESLint, Prettier, etc:

$ yarn add --dev knuckle
$ yarn knuckle add # Select your tools
$ yarn knuckle up # You are ready to go!

Knuckle can also use existing dependencies to generate a list of dependencies to install and configurations to edit. It will automatically detect and use the dependency manager set for your project!

Overriding the default behavior

$ mkdir .knuckle
$ touch .knuckle/.prettierrc # The name of the configuration file you want to override
$ # ... Edit the configuration file with the desired behavior
$ yarn knuckle up --no-install # Done!

Ejecting

$ yarn remove knuckle
$ rm -rf .knuckle

Scaling Java applications: To infinity and beyond!

By Julien Roy, Java architect @ Bankin’

The idea of this talk stemmed from a client who could not evaluate the load of their future application. By load we mean the number of simultaneous users or their session duration. One of the only objectives was to propose an API that could respond in less than 50ms and scale infinitely.

To achieve this, some ground rules were laid: the application was to be stateless, require no I/O, use cache whenever possible and be built with autoscaling in mind. In parallel, load tests validated the scalability and the set objectives. They were set to 250 Virtual Users with 10 minutes of ramp-up time and 15 minutes of execution.

The process

The process is iterative and must be run every time a bottleneck is removed, until the objectives are reached.

  1. Log analysis: Look at autoscaling, memory, CPU logs and exit codes.
  2. Reproduction: using equivalent tools, test your application and try to reproduce your issue. For load testing, JMeter is the standard, otherwise system analysis and tracing will do.
  3. Fix: Patch the issue. This step might lead you down the rabbit hole, though.

Pumba has been recommended to chaos-test Docker infrastructures. This tool can be used to simulate latency between multiple containers.

Key points

  • Your environments must be identical or as close as possible to each other;
  • Every issue must be reproducible;
  • Retrieve as much metrics as possible;
  • Only one change at a time!
  • Automate your testing processes;
  • Every issue must be locally reproducible.