Tag Archives: Performance

Undercutting – Using SCRUM sprints to strategically beat the competition as pit stops do in F1


Good luck Max Verstappen (twitter:@Max33Verstappen) on getting podium places at USA and Mexico after the great achievements of Malaysia and Japan!

As said before, the pit stops improved. By incorporating all developments in technology as well as fine-tuning the roles within the team the pit stops were made as efficient as possible “difficult to beat 1.9 seconds”.  All in all, pit stops contributed the most when used strategically to win races; that means that based on the efficiency level attained on a perfectly synchronized process with flawless collaboration of the team, the squads gained an advantage of 26 seconds over the opponents. 

Without going into the overall strategy, rest assured that making the team work efficiently is not a mere milestone, it is constant practice and sharp focus from all involved members including the crucial factor of trust. As Michael Schumacher said – “When you start out in a team, you have to get the teamwork going and then you get something back.”

In that sense, at Uniface our teams have reached the level of efficiency which allows us to release our software on many platforms and for two different versions of the product every scrum sprint (every 2 weeks). We can still improve and we keep on doing that as KAIZEN are part of our DNA nowadays. And the biggest achievement we see is, as in F1, being able to apply that predictable process to the overall strategy.


Let me go back to what happened at the F1 with the pit stop, once the team had mastered the level of efficiency, the squad decided to think out of the box and not concentrate only on the pit stop but on the overall performance of the race. At Uniface, we are aligning the business with IT to look at the overall strategy, although we still improve our SCRUM ceremonies. We think that the areas where we will gain the most are vision, strategy, roadmap, backlog management and overall in open two-way communication. I’ll keep you updated with the progress on this fascinating project. Remember, undercutting is the art of knowing when the competitor will stop or come back to the race so that you can intentionally beat him or her by planning your own pit stop accordingly.

In my opinion, we need to make the most out of the well-performed process of delivering software to use the ever-changing priorities and hit the market with the software our customers/prospects need on time. We come from an 18-month cycle (~78 weeks) to a 2-week cycle to release software, now we need to use that to strategically deliver what helps our customers the most… in a changing world.


Food for thought
The following table is an attempt to compare pit stops and scrum sprints, I know it is not perfect but its intention is to spark thoughts. Let me know what your think about it. Enjoy!

Pit stops Symmetry SCRUM Sprints
Used in Race strategy Goal is to win Used in Delivery strategy
Execution of the pit stop Synchronized perfection Sprint work
Pit crew Highly trained technical members Development team
Team / squad Harmonious collaboration Scrum team

Changing tires


Adjusting car

Tasks mastered by the team Architecture



Delivering stories

Choreography Coordination Swarming
Collaboration Communication Collaboration
Changing rules Adapt / Fast response Changing requirements


Technical and Emotional factors of Application Performance

Application performance has always been an important topic in Information Technology, however often seems to be neglected.

So, what is performance? A simple abstraction is, “how much, in how long.” This can be broken down into many technical metrics e.g. efficiency, throughput, utilization etc… however it is often easy to forget the emotional measures e.g. the perceived performance, time to action, usability, number of clicks etc… . “How much a user can achieve, in how long” is just as important as “How much a computer can achieve, in how long.” The fastest solution is of little use if it takes the user an eternity to use it. Think how much quicker you are able to use many applications once you learn the various shortcuts e.g. CTRL+C instead of (move mouse)->Edit->Copy.

Over the years, there have been many views on when it is best to think about the performance of an application. A common approach has often been to “test at the end and fix performance problem then, rather than architecting for performance.” The core concept here is that for the vast majority of applications, raw performance is not a critical factor for much of the functionality, so why waste effort addressing performance upfront where it is of little impact?

At the other end of the scale, raw performance can be a key success factor for the majority of the application logic. This makes it important to architect for performance and regularly assess. One interesting formal realisation of this is ‘Performance Driven Development.’

Which approach is best? It all depends.

Many areas require thought when thinking about performance. It is easy to immediately think about individual algorithms and routines, however the higher level technical and physical architecture require careful consideration too. Things such and caching, load on demand, batch processing, asynchronous & parallel processing, machine sizing, network architecture, component  distribution etc… can all have a huge impact on the application performance. From the user perception side of things, error prevention, self-diagnosis, UI consistency, visibility of system status etc… can also have a huge impact.

If we take “Visibility of system status,” this can quickly improve the perceived application performance. One example of this is adding a progress bar. Many studies have shown that users consistently feel an application performs better when they can see the progress. Further to this, for a fixed amount of time, the rate at which a progress bar fills dramatically affects the perceived change in performance. Observations suggest a progress bar that increases at the same rate, or a progress bar that accelerates towards the end, provoke better results in user perception. A bad choice here can however have the opposite effect and give the impression of worse performance.

In conclusion, performance is a wide topic that goes beyond simply making the quickest algorithms. There are both technical and emotional factors to consider.  Like much in Information Technology, it is important to remain pragmatic when considering the many factors, along with finding a balance between architecting for performance versus tuning during testing.