Innoveo joins Pactera!

As some of you already know, we have joined the US/Chinese PacteraGroup since January 1, 2014. Innoveo Solutions will be renamed in Pactera Switzerland, our software product name remains "Innoveo Skye". The whole team remains in Zurich, Switzerland and will be empowered in the coming time. We are very happy to be able to join these 20’000 people company and to profit from Pactera’s Sales und big customers’ base! Our next coming months will be very exciting, also by entering the Asia Pacific markets. Also a very solid constellation for our existing customers.

Comme certains le savent déjà, nous avons décidé de rejoindre le Groupe sino-américain Pactera au 1er janvier 2014. Innoveo Solutions sera renommé Pactera Switzerland, le nom du logiciel reste "Innoveo Skye". Le team reste à Zürich et sera augmenté dans les prochains temps. Nous sommes très heureux de pouvoir nous joindre à ce groupe de plus de 20’000 employés et de profiter de la puissance de vente et des clients existants de Pactera! Les prochains mois s’annoncent plus qu’existants, tout comme les premières acquisitions en Asie. Cette constellation est aussi très intéressante pour nos clients existants.

Press Release English:

Press Release en français:

Seth Godin –The business of Software

via Seth Godin

If you are reading this post, you may know how far I like all the super valuable inputs of Seth Godin. Really inspiring! So, when Seth was publishing a post about the business of software, I was super excited.

First I have learnt that Seth’s first job was to lead a team that created 5 games for …. the Commodore64!!

Some, to my point of view, very interesting abstracts from his post. Although I *really* encourage you to read the whole post (even a bit long, really great!):

[…] Clearly, just writing a piece of software no longer makes it a business.
So if it’s not about avoiding fatal bugs, what’s the business of software?

At its heart, you need to imagine (and then execute) a business that just happens to involve a piece of software, because it’s become clear that software alone isn’t the point. There isn’t a supply issue–it’s about demand. The business of software is now marketing (which includes design). […]

COMMUNICATE TO USERS: As we’ve seen in just about every industry, marketing involves effectively communicating a story about benefits to (and among) the people who will appreciate them. For software entrepreneurs, this means identifying a group of people who need the utility of what you can offer them and who are willing to give you permission to educate them about why they should buy. Without either element, the software is dead. […]

I think niche opportunities for software are largely unexploited. […]

So, the questions I’d ask:

  • Who can I reach?
  • Is the product so remarkable that they will talk about my product with their peers?
  • Can I earn and maintain permission to continue the conversation?
  • Once they learn about the utility offered, will they pay for it? [...]

ENABLE COMMUNICATION BETWEEN USERS: This is the holy grail of software. […] The network effect is the increased utility of a device that enables communication. […] If you can improve productivity or satisfaction by connecting people, then people will selfishly help you do your marketing.

When building a software business that uses the network effect, I’d ask:

  • Does the connection this enables create demonstrable value?
  • Is there an easy and obvious way for someone who benefits to recruit someone else to join in?
  • Is it open enough to be easy to use but closed enough to avoid becoming a zero-cost commodity? […]

LAST THING: Paying for it. In a competitive market where the marginal cost of an item is zero, the price will move to and eventually reach zero. […] The goal, then, is to create a dynamic where the market isn’t competitive. […] The other condition that’s necessary, though, is that users have to believe that payment is an option. The web has trained the vast majority that interactions online should be free. That makes the act of selling software, particularly to people who haven’t used it yet, really difficult. There are two ways around this:

  1. Free samples. Many software companies (37signals being an obvious one) have discovered the drug dealer model, in which the software is free for a month, connections are built, utility is created and then it begins to cost money.
  2. Move to a platform where commerce is expected. […] The app store for the iPad is like that. The expectation is that this software is going to cost money. It’s far easier to sell a serious app for the iPad than it is on the web, because the platform is organized around commerce.

[…] I wanted to help you realize that just because you can code something that doesn’t mean it’s a good idea. The issues of permission, of networks, of scarcity and of the desire to pay are inherent in the business part of the business of software. […]

Wow, really really impressive analysis!

Demonstrating strength

via Seth Godin

Wow, interesting post from Seth (a while ago, but still ;-). It is about showing (or not) “weakness” to the outside, which is seen for Seth clearly as a strength. Totally agree with that. I don’t like people that are making errors and have issue to apologize. For me, always a first signal of “more coming issues”…

Actually, I agree with *every* point mentioned, even if there are not always *easy* to implement ;-) But who says it should be easy?


Defer to others

Avoid shortcuts

Tell the truth

Offer kindness

Seek alliances

Volunteer to take the short straw

Choose the long-term, sacrificing the short

Demonstrate respect to all, not just the obviously strong

Share credit and be public in your gratitude

Risking the appearance of weakness takes strength. And the market knows it.

And I’m still convinced you can run your business well *and* follow these kind of rules!

Fear of conflict?

via Jeff Bussgang

Excellent post from Jeff concerning dysfunctioning teams, based on a book from P. Lencioni – Five disfucntions of a Team. Patrick Lencioni lists the five main issues that can araise within a team, and how to combat them:

  1. Inattention to Results
  2. Avoidance of Accountability
  3. Lack of Commitment
  4. Fear of Conflict
  5. Absence of Trust

Jeff is then emphasizing the impact of fearing confllicts within an organization.

[…] Again and again, I see management teams and boards of directors shy away from conflict. It is quite natural for humans to avoid conflict.  In fact, our deeply programmed “fight or flight” instincts are designed to protect ourselves and run away when we sense danger.  Interpersonal conflict is a danger we all prefer to avoid as it makes us uncomfortable. […]

Here are a few techniques I’ve found help address this issue, particularly in start-ups. [more information in the post]

  1. Building Trust
  2. Annual Reviews
  3. Systematic Post Mortems
  4. Go Direct

[…] Conflict can be stressful, draining and uncomfortable.  Yet, it is incredibly natural, healthy part of life, particularly in a start-up.  And creating a culture that can handle conflict effectively clearly has a positive impact on performance.

Whole post is definitely worth a read ;-)

Warm welcome to David!

After the start of Carlos on December 16, 2010, we are again very proud and happy to be able to announce that David Wilson, our new Senior Solution Architect, has started to work at Innoveo yesterday!

David has a Bachelor of Science from the Edinburgh University, and is bringing with him 25 years of IT experience in the fields of Software development, engineering and architecture, consulting, and project management. He knows also the Insurance industry quite well, as he was working as a consultant for Winterthur, Zurich, and ZurichRe in the past.

David (in the middle of the picture) at our recent Innoveo X’Mas Event 2010 with Carlos, Nestor, Roy, Oli and Robert).

We are also very happy to welcome our first “English native” speaker, as David is Swiss and … Scottish!

cross-posted on the Innoveo blog

Warm welcome to Carlos!

We are very happy and proud to be able to inform you all that we have hired Carlos Prieto Cañal, our new Senior Solution Architect. Today is the first day of Carlos at Innoveo!

Carlos has a Master Degree in Computer Engineering of the University of Oviedo/Spain, with a Master Thesis pending in Artificial Intelligence. One of his publication:
Hybridizing a Genetic Algorithm with Local Search and Heuristic Seeding

Carlos is also a SUN Certified Java Programmer 6, and has a Master in J2EE Applications development from SUN.

He was working for CSC (Gijon, Spain) in the last 4 years, where he could, among others, acquire knowledge of the Insurance market while he was involved in an international project developed for a major Insurance company based in Swindon/UK during 2 years.

Carlos (middle right of the picture) at our recent Innoveo X’Mas Event 2010 (I will come back to that ;) with Andrea, Nestor, Laurent and Cédric.

Quite a long time that we haven’t got colleagues from Spain in our Team, so it’s a great pleasure to increase also our “internationality” again!

cross-posted on the Innoveo Blog

Do more vs. do better

via Seth Godin

In extenso ;-)

The easiest form of management is to encourage or demand that people do more. The other translation of this phrase is to go faster.

The most important and difficult form of management (verging on leadership) is to encourage people to do better.

Better is trickier than more because people have trouble visualizing themselves doing better. It requires education and coaching and patience to create a team of people who are better.


Innoveo 3rd anniversary!

Yes, already 3 years that we have founded Innoveo!

That was such a dense period, with so many experiences, wow.

As we are now used to, we have celebrated this special day with a good lunch near Zurich. Very good time indeed :-)

Warm thanks to the whole Innoveo team for making all this possible!

Cross-posted on the Innoveo Blog

IMPORTANT: Want a job at Innoveo?

We are searching for an excellent and motivated Software Engineer, with a focus on Java and Web Development, to support us in the development of our standard Software product -Innoveo Skye- at our office in Zurich, Switzerland. Some more information:

  • Web technology: (X)HTML, CSS, AJAX, JSF, jQuery
  • Basis technology: J2EE, Spring, XML & SOAP, Portal
  • Development: Eclipse, IntelliJ IDEA, Subversion, Maven, Tomcat, TeamCity, TDD, BDD, Scrum/XP
  • Languages: English and German

More information in this pdf (in German).

Do not hesitate to contact me if you need more information. And to spread the news!

Thanks in advance ;-)

Cross-posted on the Innoveo blog.

Lean, Agile & Scrum conference in Zurich

As you may know, Oli (our VP Product at Innoveo) and myself participated last week to the 2nd “Lean, Agile & Scrum” Conference in Zurich, also called LAS 2010.

The topic this year: From the Scrum project to lean enterprise.

Interesting, isn’t it?


  • For me the clear highlight of the day was the presentation of Mary Poppendieck (she has written the first book about Lean development in the Software industry with her husband) – The tyranny of “The Plan” (presentation here). She explained almost all principles and bases that led to the creation of the Scrum methodology. Very convincing ;-)
  • I’ve heard now for three times quite in a row that experienced companies using Scrum are implementing very strictly the Scrum frame (no adaptation and/or tinkering), but are very careful with other Scrum best practices and lessons learnt that cannot be always replicated.
  • Again, we have heard very often how far it is absolutely central to have the software engineering and automatization parts under control by introducing such kind of agile approach. What they call “software craftsmanship”.
  • All were also confirming how long it takes to transform deeply a company ;-)
  • Some speakers were explaining how far they are still struggling with Agile Software Architecture. Seems that maturity in this field is coming quite at the end of the transformation process.
  • Heard also that Scrum doesn’t fit well to Maintenance & Support, and that Kanban is more accurate for organizing these activities (but not enough experience yet to confirm Kanban in this field).
  • Anecdote: the CTO of bbv (about 110 developers using Scrum since 5 years) said that it is not so easy to spread this kind of agile approach, as “Swiss managers like very much to command & control, which is absolutely against the aim of agile approach”. Not sure that this is so particular to Switzerland actually :-)

Mary Poppendieck

The thinking tool called Agile

Henrik Kniberg, presentation

The illusion of a “good tool”, Don’t blame the tool

Good tools are helping to:

  • visualize the workflow
  • limit work in progress
  • focus on quality
  • prioritize
  • empower
  • support continuous improvements

Using the wrong tool vs. using the tool wrong (both have nothing to do with the tool itself)

The aim of going agile has to be linked with the vision and values of the company => be careful to solve the right problem, i.e. the root causes and not symptoms

Agile is simple but hard!

Transforming BBV into an agile company

Marcel Bauman, presentation

Why changing to agile?

  • business requirements are changing a lot, customers are asking for very short projects where you can show step-by-step results, reqs are changing during the projects
  • fun for people and developers
  • young people are coming more and more on the market with agile teaching

Why Scrum?

  • standard method, most used in Europe

Bbv favors (manifesto):

  • individuals and interactions over processes and tools
  • working software over comprehensive documentation
  • customer collaboration over contract negotiation
  • responding to a change over following a plan

Scrum works only with:

  • source mgt, continuous integration, wiki, test env
  • need a lot of virtual machines and processing power
  • automate everything that can be automated
  • remote access (VPN) for all employees
  • XP as a base! => 40% of developers don’t like pair programming


  • no reporting on individual level, just project-level
  • incentive on team-level
  • pair programming interviews

The tyranny of “The Plan”

Mary Poppendieck, presentation

Key Success Factors for successful projects:

  • teamwork
  • deeply experienced people
  • focus on key constraint
  • decoupling
  • cash-flow thinking

In other words:

  • design the system to meet the constraints; do not derive constraints from the design
  • break dependencies
  • manage the workflow

Schedules based on experience are reliable. Schedules summed up from task breakdowns are guesses, hypothesis about the future.

Optimize Throughput, not utilization (coming from Queuing theory)!

  • minimize the number of things in process
  • minimize the size of things in process

Level the workload:

  • manage workflow, not tasks
  • establish a regular cadence

Limit work to capacity

  • timebox, don’t scopebox
  • pull, don’t push

Cross-posted on the Innoveo blog.