All posts by Thomas Botton

Native or Hybrid Mobile Application, Which One Should I Choose?

It is complex for non-geeks to understand the mobile application ecosystem. We often hear jargon such as mobile apps, hybrid apps, native apps, single-codebase-cross-platforms apps, etc.

Some clarification is needed.

Continue reading about Native or Hybrid Mobile Application, Which One Should I Choose?

Tags: , , , , ,

5 lessons learnt about the new SAP Cloud Platform SDK for iOS

The SAP Cloud Platform SDK for iOS was released in March and we were very excited to try it out. This toolkit allows companies to let developers build, extend, and run iOS apps based on SAP back-end data. Thus, business’ employees can access live data at any time from their iOS mobile app, and enjoy the standard SAP Fiori design language they are used to.

We booked a one-day hands-on with Noé in our ThinkSpace war room with the objective to have a demo app up and running and plugged to the SAP Cloud Platform (formerly known as SAP Hana). This may sound like an easy goal but honestly, knowing SAP, we thought that it was already ambitious.

Continue reading about 5 lessons learnt about the new SAP Cloud Platform SDK for iOS

Tags: , , , , ,

Do I Need a Mobile Application or a Mobile Website?

In our digital era where people’s attention is scattered between apps and websites, it’s not easy to know whether you need a mobile application, or if a responsive website (that can be accessed via your web browser) would meet your needs.

I have this discussion every week with new clients, and I thought it was time to share our reasoning here at Liip in order to give you a clear answer if you still hesitate.

Do You Want To Reach Your Users, or Bring Rich Features to Them?

When clients come with a mobile app request, I explain them that most of the time, a web application is more efficient in terms of investment, as well as in term of reach.

The second question I get after this answer is: “When would I need a mobile app, then?”
In my point of view, mobile apps are useful when they are crafted to be rich — vs. the reach that web applications can provide. Rich in terms of features that are only available on mobile devices, and that can’t be achieved via web technologies.

Continue reading about Do I Need a Mobile Application or a Mobile Website?

Tags: , , , , , , , , ,

5 industrial challenges mobile applications can solve

How can mobile applications support industries to undertake a digital transformation? In supply chain, risk management, or information distribution, mobile applications will make tasks easier for your employees, thus increasing efficiency. Read about 5 industrial challenges that mobile apps can solve.

First of all, it is important to carefully chose between a web and a mobile application. Mobile apps are useful when they use one of the device’s native capabilities (e.g. Bluetooth, GPS, camera, etc.), and when they enhance the experience provided to the user (compared to what a web application could do).

Industrial challenges

The challenges industries face are often very good candidates for mobile apps as they leverage all their potential. Therefore, I have identified five recurring issues that industries are facing nowadays. These pain points can be easily relieved by mobile applications.

Challenge 1: Productivity issues due to technical limitations

Continue reading about 5 industrial challenges mobile applications can solve

Tags: , , , , , , , , , , , , ,

How to reduce your development and maintenance costs with APIs?

An API-based solution has many advantages. The biggest one is the significant spare on development and maintenance costs, thanks to a modular infrastructure. With the example of a recent work for a watch manufacturer, this blog post explains you in 4 points what added value an API can bring to your IT environment.

Context: a manufacturer’s production line without a central server

We were recently involved in the digital transformation of a manufacturer’s production line. The main issue of this manufacturer was control-desktops that were not centrally managed. In consequence, for each code change, an update was required on each control-desktop. It was an expensive and time-consuming process.

Production line - A

This image represents a production line with standalone control-desktops, and their costly maintenance routines.

Continue reading about How to reduce your development and maintenance costs with APIs?

Tags: , , , , , ,

Soft Skills for Scrum Masters

(Originally written by Thomas Botton and Benoît Pointet for the Scrum Alliance and posted at

Playing the ScrumMaster role by the book is not enough. Successful ScrumMasters have developed many skills throughout their experience, often soft ones. We present hereunder a handful of such soft skills that we have identified as important during our own experiences as ScrumMasters and Scrum team members at Liip:
* Motivator
* Banana smiler
* Emotions director
* Rule breaker
* Humble leader
* Success maker

Motivator: Ensure the flow

The ScrumMaster should always be a motivator of the team. Wikipedia provides a nice example for us: “Hunger is a motivation that elicits a desire to eat.” Just as “hunger” is eliciting the desire of “eating,” the ScrumMaster should elicit the team’s desire to improve, to move on toward higher performance.

There is, however, no single way to motivate people. It is up to each ScrumMaster to identify how to turn the personal interests and values of the team members into new motivations. Example: Make it the rule for one sprint that each extra story point delivered and accepted in comparison with the previous sprint will earn the team a beer! Such a playful goal can help the team concretize both performance and appreciation for its efforts.

It will be hard to bring a team toward any objective if you are a bad motivator.

Positive attitude: Simply smile to infuse energy

Some people are born with a smile on their face. They have a natural advantage when acting as ScrumMasters. Indeed, a ScrumMaster should come every morning with a banana smile on his face to make the day start with a great team atmosphere.

You’ve probably been through it: The ScrumMaster jumps here and there, delivering messages/critiques in a negative way even as early as the daily stand-up. Consequently, the team mood gets bad from the morning onward. Keep a positive attitude all day long, even during boring meetings, even when facing harsh realities. This mind-set enables the team spirit to be in continuous improvement mode.

The ScrumMasters we appreciated working with were able to diffuse positive energy throughout the day, and turn failed sprints into opportunities. And all that just with a smile.

Listener: Channel emotions

Emotions fly around in a Scrum team. There might even be more emotions than in Waterfall teams, because Scrum team members are more invested and engaged more closely in the project and product. A smart ScrumMaster will let emotions happen and lead them toward the team’s benefit.

Don’t shut emotions down; learn to channel them. A positive emotion is the opportunity to reinforce the mood of the team, so let it fly around! And handle every negative emotion as the signal of a deeper problem: Listen, empathize, and get to understand the root cause.

An experienced ScrumMaster will know how to appreciate positive emotions and hunt for the impediment hiding behind the negative mood.

Rule breaker: Kill the routine

If there is one person in a team who should take time to think of new ways of working, of new meeting formats, and so on, it is the ScrumMaster. Software developers are often too much in their code; product owners are negotiating all day long with stakeholders. It is definitely a breath of fresh air when the ScrumMaster sets up the next retrospective at the coffee shop down the street. Everyone is surprised and excited by trying something new!

This is true for every kind of process and rule: Breaking them — even momentarily — can impact them positively, as it takes the team out of its comfort zone in order to keep a lively flow, away from the twilight zone. By positively breaking the rules, you make it clear to the team that changes are part of the game, and you enhance your team’s mind-set. Exceptions are also very good reminders of the rules in place and their deep reasons. Don’t hesitate to question rules to remind everyone of their profound “why.”

Humble leader: Propose instead of impose

If you wanted to be ScrumMaster because of the “Master” in it, step out. ScrumMastering is about empowerment, not imposing submission. Of all the ScrumMasters we’ve worked with, some of the poorest for the team were those who showed lack of humility.

Being humble is one of the most important soft skills of a ScrumMaster. There’s no reason for a ScrumMaster to shout his truth around, nor to force people to follow his way, just because he holds this special title. The humble ScrumMaster listens more than he talks, exemplifies Scrum methods and leadership to team members, recognizes the value of each team member, and steps back as soon and often as he can, to ensure that the team self-organizes. In doing so, he gains and keeps the respect of the whole team.

Success maker: Celebrate

When a Scrum team succeeds in ten sprints and fails one, everyone will remember the failed one. Our business culture considers success the normal outcome and labels anything not so clearly successful as “failed.” This has long-term effects on a Scrum team: It misleads the team into focusing on lack of success, the exceptional thing that should not happen, and makes the team act out of fear rather than hope. The team operates in run-for-your-life mode rather than in race-for-victory mode. That’s all cultural: When success is normal, why should you even celebrate it?

A good ScrumMaster should recognize the impact of concrete success on the team dynamics, and the importance of having small and regular successes throughout the sprint. If needed, lower the bar momentarily. Make sure praise for good (yet not great) work happens within the team. Having gained a bit of a positive momentum, you’ll know it’s time to raise the bar again, and celebrate each new success even more.


There certainly are many more soft skills that a ScrumMaster can benefit from. We hope that readers will walk away with at least one pertinent insight on what ScrumMastering means, beside what the books say. We’d be delighted to hear what other soft skills you consider to be core assets of a ScrumMaster.

Symfony documentation in French is online!

A year ago, I started to work with the Symfony documentation French translation team.
At this time, I was actually not imagining that it would take so long to get all that work done.. In case you don’t know, as of today, the Symfony documentation team already wrote more than 300 documents! Counting 1 to 4 hours to translate one doc plus the time to review it, you get an idea of the overall workload!
But anyway, it’s done: the Symfony documentation French translation is finally live on!!!

The main reasons behind my choice to join this project were the following:

1/ Get more involved in the symfony community and in an open-source project in general

I chose Symfony2 as an entry point in the open source world because I like to use Symfony2 a lot for my personal projects and also because at Liip, we are working with it since its first release.
Another motivation source was the fact that I always found someone (or some documentation) from the community to help me out while I was needing it, so my goal was to give that help back somehow.
Moreover, Liip is supporting open source projects – and even more the ones we’re using internally – by offering employees the possibility to work on them during working hours!
That was a great opportunity for me so I asked for some time in order to push forward our work earlier this year. I was lucky to get a 6 man days allowance that I consumed actually very fast. The timing was great because it gave me more time when I was starting to lack of personal time to work on the translations.

2/ Getting wider and more detailed knowledge about Symfony2

This is one point people don’t think about when you tell them you are doing translation work. Indeed, as you need to read and translate every word of every sentence of every document, you are learning a lot of things while going through every documentation pages! I was actually surprised that some part of the framework such as the DI (for “Dependency Injection”) component were so well documented.
Also, the good part in this work is that you get to know all the latest features and changes thanks to documentation updates.

This second point was one of my main incentive to keep the will to do translations after months: always learn more and more.

3/ Helping French speaking people (with little or no English language knowledge) to get into Symfony2

Last but not least, as mentioned in 1/, I wanted to give the community something back with these translations.
So I thought that a good way to help could be to enable people without good English knowledge (or no knowledge at all) to learn the Symfony2 framework, and hopefully to appreciate it as much as I do.
I really wish that at least some person find it useful to dive into the Symfony2 framework.

4/ Improve my english (and my french as well…)

As English isn’t my mother tongue, I think I will always have something to learn about it (in French too actually…).
That wasn’t an initial incentive as I was thinking my technical english wasn’t so bad but reading English written by native people taught me some more grammar and orthograph I wasn’t aware of.
When I think about it, I also had to look back into my French grammar favorite websites too. Indeed, talking and writting the whole day long in english at work showed me that you can easily forget some rules (when not mixing them between languages)!

Looking at the point we have reached today, we see that we have come a long way until the “go-live” last saturday.
I must admit that sometimes, I was lacking motivation seeing no one replying to tweets talking about the work in progress… I was wondering if the effort would be worthy.
But three days ago, when Greg (@gregquat) announced on Twitter that we were done (or better to say “in sync/up to date” with the symfony-docs english master repo), I was amazed to see how many retweets and replies we got in the following minutes.
That was very rewarding and rose our “motivation level” more than ever. And that won’t be too much as this kind work is a never ending task: existing documents get improved (or completely rewritten from A to Z: the translator’s worst nightmare) and new ones get added.

In case you are still hesitating to join or start a Symfony translation team, I hope I gave you enough reasons to go for this challenge ;-). Don’t forget that you need to be really motivated, but it will be rewarding for you and the community! That’s really a worthy endeavour!

If you are interested in the French team, go and read the dedicated wiki page or contact me (@skeud) or Greg (@gregquat) if you have any questions.

Key Dimensions of User Stories

(Originally written by Thomas Botton and Benoît Pointet for the Scrum Alliance and posted at

Dealing with a large amount of user stories (more than your fingers and toes can account for) is not easy, most often they sit one after the other in your product backlog, or they are shuffled on a story map. Dealing with user stories is basically projecting them in a space of dimensions. The three essential dimensions to our scrum process at Liip are: the backlog order, the complexity (we call it effort), and the business value. Let’s review briefly the first two and then focus on the third one.

Backlog absolute order

The product backlog order represents the urgency of a story. The absolute ordering forces the client to refine his understanding of the product backlog: there’s only one single most important story to do next.

Story points

The complexity, is an integer value from the Fibonacci series, which represents a mix of technical complexity, work time, and even uncertainty bound to a story. Developers agree on it through the estimation poker game. Those two dimensions are commonly used in scrum teams around the world. The third one, business value, not so much.

Business value

Why isn’t the business value that much used? Probably because scrum masters tend to forgive more to POs than to developers and because POs don’t see the need to express this value. But business value matters – to everyone in the team. Even more, business value represents something that’s deeper than the reason of the user story, something laying deep into the business logic: the added value that the story brings to the business.

But that’s so hard to express. Really? Really harder than estimating the complexity of a story? Think twice! Or rather, think the same: complexity estimation is relative and summative. Business value estimation should be the same: estimate the value of a story relatively to the others, and resume this value in a single number.

You got it! We do estimate business value the same way the developers are estimating the complexity. We ask the PO and stakeholders to play estimation poker – and they love it! It’s a unique opportunity for them to get together and come up with an agreement on story relative values.

Applying the same rules on estimating business value and complexity has an important side-effect: it brings understanding and respect in the project team. A PO will be more likely to understand why some stories need to be reestimated by the developers – and vice versa. Using a numerical scale for the business value also allows to visualize it (cf. chart below), something MoSCoW can offer in a limited way – if at all.

As an example, here’s such a chart for the stories of sprint 1 (green), sprint 2 (blue), and the remaining of the product backlog (grey) of a small project we started recently. You clearly understand that stories laying at the top-left corner are the most interesting, which is why we took them in our first sprint.

The ROI (a.k.a Return On Investment)

Such a chart brings to your scrumish minds a sense of “Return On Investment”: the ratio between the business value and the complexity (aka. BV/SP). Since both are relative metrics, this is a relative return on investment that you’ll never be able to translate into dollars, but which allows you to compare user stories. On the following chart, ROI is increasing in an angular way. It is now fairly easy to spot the undone stories (grey) with high ROI: 8, 20 and 30. Those are probably the ones that the PO will put at the top of his product backlog.

Those three dimensions are very flexible until sprint commitment. However, right before it, both the complexity and the business value must have been estimated for the top of the product backlog, which means that the product backlog has been re-ordered! The classical sprint commitment can then occur: the team pulls the stories from the top of the product backlog into the sprint backlog, negotiating order and amount with the PO. After commitment on a story, both its complexity and business value should not be altered, since it would tweak the metrics.

Agile Tour Lausanne 2011

Two weeks ago, the first edition of the Agile Tour Lausanne took place. Luckily, Liip proposed me to sponsor some of my working time in order to prepare it.

It was the first conference I ever organized and I must say that if you are interested in doing something similar, just go for it! It is really a great experience!

Thanks to my co-organizers Yann Lugrin, Jonas Vonlanthen and Frédéric Noyer, we managed to get more than 60 attendees – which was beyond our expectations.

The Agile Tour organization

As introduced on its website, the Agile Tour organization aims to “massively communicate about Agile, share their visions of Agile, federate and support people and local businesses in regions” once a year during October and November, all around the world.

Each event is self-organized and should involve as many local people (organizers, speakers, attendees) as possible; the goal to keep in mind being to “create leaderships” in a lot of regions of the world in order to “impact the professional world”.

The last part of the previous sentence is the most meaningful to me as it’s exactly what we try to achieve every day at Liip.

In Switzerland, Lausanne is the third city organizing such an event – after Sierre and Geneva. Nevertheless, we thought there was enough space between Sierre and Lausanne to not overlap too much and also because the Agile Tour is not about competition, but about acting as a community.

In that spirit, we were even coached by the already existing Agile Tour Sierre team (thanks again Jean-Pierre Rey!) to benefit from their experience.

The conference – a short summary

We prepared the day so that it was mainly focused on real world experience feedbacks of Agile practices, and more specifically Scrum.

As we were expecting part of the attendees not having any background knowledge about the Agile topic, we decided to start the day with theoretical presentations.

It was a very good choice because it created a common knowledge basis for the following discussions which happened during lunch and coffee breaks.

Then in the afternoon, we organized talks showing real use cases. Companies like, l’Etat de Genève and Liip presented how they deal with Agility in their daily business.

If you weren’t able to join us, you can easily go through the speaker slides that you can find on the Agile Tour Lausanne website.

The conference – follow-up

As the attendees know, we asked all the participants to fill an evaluation form in order to gather feedbacks.

Hence, we will have soon our retrospective (an Agile event has no choice but to use Scrum itself) to check what people thought of their day and see how we can improve – and maybe an Agile Tour Lausanne 2012 will be announced afterwards.

Tags: , ,

Symfony2 Bundle Structure, a use case

(Written by Thomas Botton and Patrick Zahnd)

Symfony2 was released as Beta 1 few weeks ago. Since it starts to be our main PHP framework here at Liip, we decided to dive deeper into the core component of Symfony2: the bundles. Indeed, the structure of it needs to be clearly understood in order to have maintainable and sustainable code.

This blogpost aims to propose a project that one can take as a real life example for building its own bundle set with a correct structure – at least avoiding the main common mistakes.

In general, a bundle is meant to be a standalone component that can be reused and implemented by anyone in their project – as nobody wants to reinvent the wheel.
Bundles can have controllers, entities, forms, views, etc… To prevent these components to end up in a mess, Symfony2 comes with some rules and architecture to follow.

We recommend reading the Symfony2 “Bundle Directory Structure” post before starting at this point:

Full bundle structure


Used to expose commands to the console (app/console).


The place you put your controllers. You should separate Frontend and Backend controllers into subdirectories – if you have both – in order to have it more readable.


Here you can load your own services by creating a so-called Extension.


Mapping for ODM objects. For example Contact Messages which you send as an email.


Mappings for your ORM objects.


Form definitions.


Configuration of your project.


XML (or YML, or PHP) configuration files, like the routing.xml for example. Default is to use XML, and you have to use XML in Bundles you’d like to commit.


The templates in the format you prefer (PHP, Twig, …).


Translations file in XLIFF format.


Public files like images, CSS stylesheets and Javascript files.


Bundle functionality tests.

Sample project

As an example, we decided to go with a web application handling various music events and the user comments.
The following shows how to translate/divide a simple feature list within a set of bundles.

  • Events
    • Frontend
    • Event list
    • Search event
    • User can register for event
    • Backend
    • CRUD event over an admin interface and on the console
  • Visitor Echoes
    • Users can write a comment
  • Contact form
  • Pages displaying static content


Described in bundles

  • EventBundle
  • EchoBundle
  • ContactBundle
  • StaticBundle

Event bundle

The EventBundle encloses

  • commands to access the backend function
  • frontend and backend controllers
  • entity for the concerts
  • form to add concerts (backend)
  • form to register for an event (frontend)



The EchoBundle encloses

  • frontend controller
  • entity for the echoes
  • form to add an echo



The ContactBundle encloses

  • a frontend controller
  • contact form



You should not use this approach in production, this is just for example

The StaticBundle only encloses a frontend controller which will be responsible to take a page name as routing argument and then to display the corresponding template. If none is matching then 404 is displayed.



From this small case study, we can see some “bundle properties” drawing up which can be pick up depending on the bundle you are building:

  • Backend/Frontend differentiation: this structure allows you the get more readability and help you find faster what you want to work on, depending on if it is front or backend. This splitting usually occurs to the following directories: /Controller, /Ressources/views and /Tests
  • DB interaction based bundle (i.e. Entity/Document and Forms): that is the case for a lot of bundles which rely on one or more entities needing forms to interact with (create, modify or delete)
  • Customizable/Dependency Injection: this is the place where you can handle your own services. Therefore you have to create a so-called Extension. To understand that, you might want to read the following two blog posts: /

To sum up, we could say that the bundles’ goal is to split feature/functionality in order to be reusable as much as possible. If you end up with only one bundle for your web application, you might be wrong. Just get your head back from code and think: it must be a possibility to break your “SiteBundle” into at least 2 bundles. Else it means that you are having a static website, then you should go with a “StaticBundle”.