Adapt, connect, innovate or die...

Last Tuesday evening, I was invited by Thomson Reuters to attend one of their special events dedicated to innovation in finance.

The location was quite prestigious (i.e. the "Maison Blanche" in Paris) and both the organization and the speakers were truly excellent.

To be honest, I was expecting much more marketing and sales speech from Thomson Reuters than what we had actually. But Mind you, I am not complaining ;-)

The event started by a short but brilliant 20 mn talk from Navi Radjou. He's Innovation & Leadership strategist, but also co-author of the "Jugaad Innovation" book (A frugal and flexible approach to innovation to the 21st century).

We then continued with an excellent 45 minutes panel about HFT, algo trading and innovation in finance. This panel was animated by Guillaume Thouvenel (Executive Coach & IT Emergency Manager) and speaker were Jean-Marc Bouhelier (CEO Celoxica), Dominique Ceolin (CEO ABC Arbitrage), Olivier Martin (« Unified Platform » COO, Thomson Reuters), Philippe Musette-Sykes (Senior Advisor to the Board, Kepler Cheuvreux) and Riadh Zaatour (Quant Analyst, McKay Brothers).

After this panel and a conclusion by Rémy Granville (Thomson Reuters), we all networked around a buffet... in front of the illuminated Eiffel Tower.

Yes the panel was very interesting, but I'd like to focus here on Navi's intervention.

Innovation by Navi RADJOU

The topic was "how to reinvent financial services in the 21st century".  And its core topic was really about innovation.

Navi first tackled some of the CEO common beliefs/myths: "Our group is Invicible/Irremovable, our group is Universal, and" ... another belief  which I can't remember here, sorry ;-(

Irremovable?

In fact, the average lifetime of big company moved from 75 years (in 1940) to 15 years (in 2014)... Too big to fail? Nah... Navi took few examples of Disruptive effect.

For instance: Marriott & Accor are really big companies in the hostelery/inn business. But Airbnb jumped out of the blue in 2008. They are now able to provide more rooms to end-users than Accor and Marriott can. They can even do it in some emerging locations, were the ol' groups aren't able to create Inns or to take market shares.

Music, Taxis, ... in fact, the concept of impermanence seems to generalize in every business domain.

Wealth management is another digital disruption victim for instance.

Gulliver and Lilliputians ...

Because everything is possible now with crowd-founding. It's a new deal. For everyone (e.g. the recent 41 M$ raise for the RSI video game... 41 Millions $ !).

Universal?

By the way, do you know that Nigeria emerges 3rd most profitable stock market in the World?!?

Navi tackled the "Universal" belief of CEO (i.e. our activity or business model is universal). His main point was that there are lots of innovations and disruptive models emerging from all around the world. Africa, Asia, South America, ...

Let's take M-PESA for instance. This phone money transfer solution has dramatically transformed the lives of all Kenyans (no need to take the risk to walk with money in their pockets anymore). It has also revolutionized the way Kenya does business. Without banks.

According to Navi, there are lots of things to learn from what currently happens in those emerging countries & markets.


So. How to adapt, change and innovate to succeed and survive in that moving world?

Agility advocacy

Agility is a must for all modern companies. Indeed. When everything is changing all the time. Companies have to get ready to embrace those changes. Quickly enough.

The GAFA threat

Google-Apple-Facebook-Amazon. If you don't change and embrace new technologies & ways to make business, those giants will do it for you.

And there is a pattern here. Google is emblematic, but all those successful companies have built their own ecosystem to speed up & ease any of their new moves now. For financial services (and any other industries), there is probably something to learn from.

Transcend the Business/IT silo to innovate

According to Navi, the solution to innovate and be successful nowadays is to transcend the Business/IT silo. At last, I would say.

Open & connect with the others

Another key to success for companies is to open themselves to the others:

•  To open close discussions with their clients (through social networks, or via prototypes)
•  To open for co-construction with their partners
•  To open for co-innovation with their technology suppliers

"Innovation": a modern bias?

Navi also warned us about a bias that most of the company have nowadays: they create dedicated teams for innovation, dedicated awards, dedicated labs... Openness is the real path to follow. You have a lab? why not. But don't let dedicated people play alone to the game of innovation. Let's open it to everyone, including external partners.

By the past, innovation came from inside the 4 walls of the companies. Innovation is now happening outside the 4 walls. It's happening among partners, thanks to active networking that companies need to foster.

Navi then introduced us the 4 roles of innovation: the Inventor, the Transformer, the Sponsor, the Connector.

IT guys should be the Connectors for innovation. Not the inventors!

Instead of desperately trying to be Inventors, successful IT divisions are now much more Connectors.

IT guys must inform their business of what's going on with technologies.

You don't need to invent to innnovate! Knowledge is NOT power. Finding and sharing knowledge IS power.

And technology watch is not sufficient. We should also watch new usages  for inspiration. This is exactly what BBVA is doing with its Cross-Country Emerging Markets Unit.

Takeaways

Navi left us with few takeaways:

1. IT guys must exit the pure function of back office and become more strategic partner with their business
2. IT need to reinvent its relationship with its suppliers. Fostering more on (technological) partnerships and co-construction
3. IT needs to foster and rely on an "Agile Architecture" to sustain its business and to continuously innovate.

Agile Architecture?

Yes, with mostly 3 drivers/qualities:

1. Simplification
2. Openness (towards 3rd parties)
3. Evolution

Talking about simplification, you definitely have to see this!

Yes, I'd like to conclude this post with something that my mate Cyrille had shown me. It's a short, but exceptional TED talk from Yves MORIEUX:

> As work gets more complex, 6 rules to simplify <.

I strongly advise any people working in a big organization to take 12 minutes to see it. You won't regret it. A truly engaging & inspiring contribution.

Raising the bar

It's been a while now that we organize and attend various kind of Software Craftsmanship events at work.

Usually at noon, we leverage on our big company infrastructure (meeting rooms, town halls,...) to gather more and more people -month after month.

Our objectives: to meet, share, connect, learn, debate, code, hack...

After few years of difficulties (we faced some issues while our organization was scaling), we started now to raise the bar collectively by improving here and there our overall mindset and curiosity.

There is still lots of things to improve -mos def- but I have the feeling that we have triggered some kind of snowball effect here. A positive snowball effect.

Let me describe you the kind of events that continue to help us on that journey.

Brown Bag Lunches

The concept of Brown Bag Lunch (a.k.a. BBL) was probably the spark that ignited the fire of that positive dynamic. And this is still a very popular kind of event here. Probably the most popular one.

Introduced within our company by Romain LINSOLAS -our local Huggy Bear- and from an original idea of David GAGEOT (famous french Software Craftsman), the concept is pretty simple : we contact a speaker -usually an external one- and we welcome him for a free talk within our wall during lunch time. It's free, opened to every developer (first-come, first-served policy for seats). The topic may be whether on a craftsmanship technique, an open source library, a noSQL db, a kind of architecture (e.g. reactive, distributed, lambda, hexagonal), a low-latency middleware, etc.

Everyone is coming with his own Brown Bag (for the sandwich), and the organizer generally pays the speaker's lunch.

Usually between 1 or 2 hours depending on the topic and the Q&A session, this is the perfect spot for anyone to learn stuffs (even for the "I  have no-time for market watch" guys).

For the speaker it's a good way to prepare himself and to rehearse before a more official conference (like we did for our DEVOXX sessions). It's also the opportunity for him or her to meet and chat with other craftsmen, or to be the first one that the company will call when expertise on that area or product will be needed.


Since we have a lot of speakers working within our walls, but also a crowded audience of developers, we recently started to organize internal BBL sessions (with internal speakers). Some of us are also now "baggers", being capable to meet you within your company to talk (done with my mate Cyrille DUPUYDAUBY at betclic for instance).

If you are in France and want to organize BBLs, don't hesitate to consult the official site: http://www.brownbaglunch.fr/ to find speakers near your office. You won't regret the experience!

Coding Dojos

Widely-known, the coding dojo is an excellent way to learn and discover other concepts or techniques. It's also a great occasion to connect with and to have lots of fun with other passionate developers.

The concept? We meet at noon (10-20 persons in the same meeting room) and we try to solve in one hour or two, a small problem (the code kata) proposed by the chair of the session. 15 minutes before the end of the session, we all stop our progress, and make a public retrospective to share and challenge our various approaches. The occasion also for the chair to give us more hints about this kata that he usually has made before (few times, in other contexts).

Regarding the logistic, almost everyone brings his personal laptop. But since we usually pair, even those that didn't have a laptop may code. Depending on the kata also, everyone is picking the language of his choice to work it out (Java, C#, Javascript, F#, Scala, Clojure, Haskell, ...). 

Firstly introduced by my friend and eXtreme Programmer Philippe BOURGAU, Cyrille MARTRAIRE and Gilles PHILIPPART were truly the ones that institutionalized the coding dojos then, as a regular event. Indeed, even if this summer was pretty quiet, last spring there were almost one coding dojo per week (usually nicely chaired by Eric LE MERDY). But I must admit that I miss the fun, creative and very informative sessions chaired by Jean-Laurent DE MORLHON (working elsewhere now). A true mindset inspiration for me, when I organized some of them afterwards.

By the way, here is a hint for you if you want to launch this kind of events within your working environment: don't hesitate to find an incentive to break the ice and make new developers joining the movement.

The chicken and the egg situation

Indeed, someone that never attended a coding dojo will be often reluctant to join one, but those that have tasted a coding dojo once, will usually be recurrent attendees.

That's a fact, a coding dojo may firstly appear impressive if you never attend it before. Will I be able to pair with guys I don't know yet? Will I be able to code as fast as the other attendees? ... are common questions silently un-asked. But once you've attended a first session, the result is always the same: we all realized that it is not only easy, but truly fun! (and BTW, kata aren't about complex algorithms, nor about any given tech stack that you wouldn't know)

To reach some .NET developers that were not used to contribute to such events (and probably a little bit shy or anxious, since they had lots of excuses to refuse again and again), my solution had been to make a deal with our purchase department and Microsoft, and to offer temporary MSDN account activations (i.e.  the ability to download a tons of MS product for free) to every developer that will attend their first coding dojo.

Whether you are contractor or internal employee, you will be able to install Visual Studio on your personal laptop, but only if you attend a coding dojo first. Here, I have to thanks again our purchase division mates, and our contact in MS for that. Because with that thing... No more chicken and egg problem for dojo attendance.

I won't detail much more on coding dojos, there already are lot of literature on that area, but simply give you some of my favorites: Gilded Rose (legacy code refactoring), The ("office") code carpaccio (my personal adaptation of the code carpaccio kata. i.e. how to slice your work in order to add business value on every 8 minutes iterations), Mars Rover (perfect for TDD design), the Cash Register (how to avoid being blocked by fragile tests when business requirements are changing blazing fast), etc.

Hackathons

Organized by our company, and hosted by Ecole42,  this hackfest has mobilized lots of developers during an entire WE (too bad that wasn’t during the week), around the theme: "create new kind of collaboration tools for distributed dev teams". A nice initiative that will surely be reproduced in the future.

Some other ideas we started to launch recently

"Hack da cafeteria"

During a recent discussion with Bernard NOTARIANNI (co-founder of the Paris #XProPa), we had an idea for a new kind of lunch-event.

Indeed, while I was explaining my proposal of organizing dinners in Paris for XP practitioners: wine, food and craftsmen (explanations here in French), he stopped me and said: "nice idea! but why don't we start here, within this company, by hacking the cafeteria at noon for debating around development topics?", "That's right! Why don't we?" ...  The concept of the Hack da cafeteria event was born.

This concept is pretty simple: we join the cafeteria with a topic to debate and to share about with other real practitioners (e.g. "How to convince skeptical dev and project managers to allow pair programming?", "Mob programming, how does it work for you?", "CQRS & event sourcing in action with concrete cases", "How DDD practices helped us within our projects", etc).

We split ourselves into tables of 6 to lunch and debate the topic of the day. After a 1 hour of lunch-debate, every tables merge for the coffee in order to share with the others tables their 2 or 3 highlights.

At the end of the day, a short minutes may be forwarded to anyone interested by this topic (especially the people that are not practitioner already, or located at the other side of the globe ;-)

The very first session is already scheduled and will occur early September. I'll surely post something about it after.

All those events are easily affordable, and are perfect occasions to break silos and to connect people from different cultures, teams and habits.

"Mate, you have to see this!"

Is another stuff to do at lunch-time. Something I would have liked to organize since a long time, but that I will actually schedule in 2 or 3 weeks from now (I've made my poll, and it seems that there is appetite on this too ;-)

The idea: to display somewhere at noon, the video of a talk, conference, quickie, ... that strongly impacted one of us, and that we wanted to share with peers. Not only to share its content by the way, but also to debate all together on it afterwards.

You don't have time to do some market watch? Let yourself leverage on other mates' best discoveries! Simple, easy, and the opportunity to open some technical debates, even if you can't attend some meetup evening events in Paris (what I call my geek evenings).

I've read pretty much the same concept within Sandro's book with tons of tips for the logistic when we don't have access to the ideal rooms/theaters (even if I'll try to borrow our official theater at work, if this initiative is having success). And we already have lots of videos (and debates) in mind for the first representations...

And last but not least, I'm proud to introduce you

The Lunch-box mob

How would we properly implement event sourcing to add more business value and audit trail capabilities to an Order Management System (OMS)? Will we be able to leverage on the LMAX Disruptor without being forced to reimplement all the associated LMAX stacks in .NET? (i.e. ressources pooling, cache-friendly collections, etc) How would we implement a Smart Order Routing system (SOR) with relevant low latency and throughput performances, but without scarifying code readability & maintainability for non-experts? Which programming paradigm to choose for this kind of reactive system: LMAX disruptor-based? In-house Sequencer-based? RX? F#? 

... were some of the questions that led Tomasz JASKULA (DDD and F# Paris co-founder) and I to pair together at noon with our laptops in order to spike and build stuffs (yeah: enough said! time to code ;-)

That why we created the Lunch-Box github organization, and started to work on an open source Simple Order Routing (a kind of Smart Order Routing financial system, but without the smart algorithm part). The #SORLunchBox project was born! (see details on the project's wiki)

We've been since joined by some mates that have both the SOR functional knowledge and the envy to collaborate. Again:  our Mob programming crew was born! (with 4 people for 1 keyboard and a big screen).

This is the very beginning, but since we are not working on the same teams, we decided to meet at least 2x2hours a week -at noon- to work on it. We split our project into various journeys, and will probably keep a logbooks to diffuse what we will discover, next to our code which is open sourced.

This kind of experimentation has lots of benefits. It has already learned us various things (functional, mob programming organization, etc.) and bring lots of fun too! And who knows : maybe this spike open source project will help other teams, but also help ourselves (through the feedback of people elsewhere).

Experiment, talk, learn, debate, build, and share

What i'm saying, as a conclusion, is that you always have lots of benefits to experiment, talk, learn, debate, build, and share. Yes, sharing your passion, your failures, your discoveries is good, and helpful. For you, and the others.

Most of the events and occasions I talked about in that post are free and very easy to organize. Don't wait that your company or structure help you to start. Also, don't expect to have lots of people with you to start doing things. Start with 2 people, communicate on it, have fun... and let the other join the initiative.

Be the spark that will ignite the fire of Software Craftsmanship within your organization! 

wiked! the solution to DRY all our projects KM

Since my latest post: It's really time to DRY our apps' Knowledge Management! I had the occasion to share this topic with several mates, and thus to discover that the maven site plugin was perfectly fine for what I intended to do (thanks to Christophe LALLEMENT & Alexandre NAVARRO by the way).

Thus, no need to reinvent the wheel for that (which is perfect fine for me).

So I started to play with maven (quite new for the .NET expert I am), and especially with the maven site plugin ecosystem. At the end, it took me several hours in order to fully understand how to use it properly. With some questions like:

• Which maven plugins (and versions) should I configure within the pom.xml I intend to use in order to generate the web site for my project (which is not a java project by the way)?
• Which minimal pom.xml could I set in order to generate a web site with the mvn site command-line (important for non-java project, and to KISS)
• Where should I put images and other resources in order to be able to reference them properly from my markdown pages
• Why and when should I have to call `mvn clean` before the `mvn site` command-line in some rare cases (like when changing the project name whithin the pom.xml file)
• How to set a better look n feel to the overall generated web site?
• Which markdown syntax was working, and which one was not well supported by the tools (i.e. the atx-style headers)?
• etc.

I finally intended to package something that would help me (and others) to quickly setup such web site generation solution for every new project Knowledge Management.

Thus, i'm proud to present you the wiked! solution,  now available on gitHub.

More than a simple bootstrapper that will ease you to earn some time when setup-ing such a solution for your project, wiked! also offers you a structure and some content for all your projects web sites (see the values and practices section for instance).

And since the DRY principle was one of my driver, I won't fully describe here what wiked! is all about. If you are interested, you can have a look at the wiked! ReadME.md

Hope this help.

It's really time to DRY our apps' Knowledge Management!

While I was reading the amazing Pragmatic Programmer manifesto, several years ago from now, I really enjoyed the "Keep Knowledge in Plain Text" principle (tip 20).

Unfortunately, I never really took the time to apply this principle seriously for the Knowledge Management (KM) of the various projects on which I worked. Every time, I lazily put all the team/application related informations whether in a wiki, or as MS Office documents stored on a Sharepoint... (sad panda ;-)


Last time, while I was having a lunch with a colleague of mine (a well-known and passionate french craftsman), I realized how lazy I was so far regarding this KM topic. With 2 or 3 words only (read-only wiki, Markdown documentation, SCM), Cyrille starry-eyed the dormant craftsman in me.

Indeed, since:

• wiki web sites for DEV teams usually finishes badly (e.g.: lots of different wikis/sections for the same component/teams, no proper knowledge of what is still relevant and what is deprecated, structure mess, etc)
• documentation created separately from code or components is less likely to be correct and up to date
• it’s not easy to compare/diff MS Office documents
• it’s important for every piece of knowledge to have a single, unambiguous, authoritative representation within a system (DRY principle)
• the text documentation has becoming more important than ever since the advent of the blue book (to express the ubiquitous language of our projects, to clarify some large-scale design intents, etc)

It would be a good idea for us to find a way to get rid of traditional team wiki site, and instead to write every documentation in:

• text files written in Markdown format (we may benefit from any Markdown existing tool/editors)
• stored within the SCM of our project (e.g.: SVN, git)
• and to make our Software Factory (re)generate a static web site (like a read-only wiki) every time we changed those Markdown text files from within our SCM. 

As benefits, our team/application documentation will:

• always be up-to-date and versioned
• easily diff-able (text files with Markdown format)
• respect the dry principle (with our SCM as its golden source)
• easily browsable by everyone in a readonly but readable wiki-like web site (DEV, QA, Support teams, …)
• easily modifiable by team members in a well know and official location (as easy as creating/modifying a text file in a SCM)

Of course, the idea here would be not to reinvent the wheel, but to reuse any existing Markdown renderer & static web site generators instead (the step beyond the github Readme.md file). But if I can’t find something and make it out quickly, I would probably initiate an open source project to implement such system.

Cyrille was right: it's probably time for us now to kill wikis! and to reinvent them.

Last but not least: a very interesting post of Cyrille about Collaborative Artifacts as Code.



BREAKING NEWS: I found a solution for my use cases, described here.