EurosportBET

It is possible to create a product from scratch and be on time for delivery, in very tight time, technical and legal constraints, using combination of agile management and up to date tooling.

On Tuesday 8th of June, a new French online sport betting and poker internet site has been put online, the day online gaming market was officially opened by French authorities. It was the first legal .fr online gaming site to start operating in France.

EurosportBET (and its British site) is an inovating sport betting internet site, making online betting straithforward and accessible for anyone, viewable on any plateform including latest tablet devices, and offering a large sports spectrum.

Pre match and live betting is now going to be simple and efficient for anyone, adding a real new dimension to sport events. Do you want to bet?!

When software development agility  is not considered as a trendy fashion to follow, but a pragmatic way to improve productivity and quality, it can give the best. Looking back to 2009, one interview of IBM’s VP Sue McKinney by DZone stands above other papers or interviews, by giving a clear and simple view on how to manage change to agile paradigm.

The approach is summarized in one single sentence:

Short, time box iterations with stakeholder feedback –working software.

This short slogan hides a much more complex plan to switch to agile. The (not secret, not new) success formula is, as usual, a mix, and a strong link between people management (especially grassroots and executives levels buy-in, momentum creation, stakeholder feedback), and technical best practices (continuous integration, automated testing to name few of them), under influence of one single major constraint: to deliver often and fast. Hence knowledge in the technical and people management fields are key, as the ability to acquire this knowledge fast if missing. This is what makes the difference between successful organizations and sterile ones.

As a result, IBM’s 25.000 people on 124 sites worldwide are moved from standard waterfall-ish paradigm to a more flexible one. Key recalls:

• technical practices are as important as people management ones, one can not work without the other,
• the switch to agile paradigm can be efficient despite non collocated teams, geographic distance, and large scale organizations.

Nothing new under the sun, but the fact that with the time derivation from simple targets (firm schedule, cost efficiency, quality) can be forgotten, and that there are proven solutions to solve the problems.

Yes, again it’s very clear agility works at large scale, but as described in Scott’s paper, this requires much more than a 2 days certification (to become a so called “master”) to achieve this result.

Agility is often seen as a young paradigm which works only at low scale

Agility is often seen as a young paradigm which works only at low scale, especially because some Agile methodologies work good at small scale, but are difficult to use at large scale « out of the box », as the practices they suggest to use cannot be scaled.

For example, SCRUM or XP (Extreme Programming) may not be scaled so easily in a big organization or for complex products. This is because such approaches bypass the holistic understanding of a situation, and neglect possible solutions, especially the technological ones, by a lack of vision, adaptability, or knowledge.

SCRUM stand up meetings or “post-its” user story boards may work when the number of involved people is small, when the number of stories to implement is not too large, and when dependencies between teams are not so complex to manage.

In nowadays ecosystems, products complexity and organizations dimensions cannot be a show stopper to the possibility to grow, to adapt fast to the changes, to produce faster and cheaper, with high quality standards.

In nowadays ecosystems, products complexity and organizations dimensions cannot be a show stopper to the possibility to grow, to adapt fast to the changes, to produce faster and cheaper, with high quality standards.  This is especially true in software development and online products branches, as competition is dramatically enforced due to the technological evolution speed, and the transparent information access resulting of information diffusion on the planet.

Product complexity, technological evolution speed, fast information diffusion and market globalization seen as handicaps for some will be the success factors of some others. And this is where agile management will play its role, by assisting companies to reach high competitiveness levels, to grow and to adapt fast to the changes.

Teams working on one single product may be distributed over several countries or continents, as a consequence of the market environment on one side, and the possibilities offered by object oriented, component oriented and network based developments, communication means performances and subsequent globalization on the other side.

Can such teams produce new products releases frequently and on time, keeping the quality level high, growing in throughput and size, while sticking to customers’ needs, market changes?

Yes they have to, and yes it’s possible! But this has nothing to do with SCRUM or XP. This has something to do with the roots of agile management, and especially the holistic understanding of the markets and production environments. With such an approach, the pragmatic solutions which lead to speed, schedule respect, quality and cost quantum leaps are combinations of best practices (processes, technologies, organizational changes), rather than a blinded-eyes implementation of one single methodology.

In the end, the management itself must be managed in the agile way, and not only the projects which are to be managed.

Clear prerequisites to this “pragmatic agility” are then to have a good knowledge of the best practices palette, and to keep the possibility to adapt chosen solutions depending on existing and rising constrains, as chosen solutions are never static in time. In the end, the management itself must be managed in the agile way, and not only the projects which are to be managed.

The holistic agile planet

Experience shows that best practices population contains four invariant, or fundamentals management patterns, which can be tuned and adapted, but which are part of almost every efficient agile management organization of any scale:

• To keep customers and their needs close to the teams in charge of production, in order to be customer and market driven,

• The transparent monitoring, especially of work progress and quality, based on negotiated and agreed metrics,

• The promotion of teamwork (and customers should be part of the teamwork), rather than keeping isolated islands and black hole areas,

• The systematic use of technology and automation when possible.

These four invariants are linked to each other. Technology and automation can ease reporting, reporting can be used to promote teamwork by sharing agreed metrics providing a common referential, and customers and their needs can be kept in the loop thru teamwork, by participating in planning and priority management.

Beside those four invariants, a large number of market best practices should be used to ease and support agility. Continuous and delta integration, test driven development, are some of them. But, as for the four fundamental invariants, they are also linked together: an automated build system may generate a lot of noise in the quality signal it generates if not coupled with an efficient configuration management system. Fundamentals and best practices are linked together, and this is what the holistic approach is about.

In the end, the combination of fundamentals and best practices leaves little room for multiple isolated situation understandings, and promote a global teamwork were customers and providers share one common goal, and were production is eased and controlled.

Although agility, as any concept, can be seen as a purely theoretical and sterile approach, using best practices combinations can really give a boost to productivity and quality, while reducing costs and allowing size growth.

The use of the difficult conditions some companies are currently facing for marketing purposes is one thing, which I personally find of very low level (we are in a financial crisis, not a production one). Another point is: how about product lifecycle evolution in car industry? Well, time from idea to market has been considerably lowered thanks to PLM solutions for instance, and of course quality management, organizational changes, and other practices. Of course, this presentation does not contain any fact and figures on car industry, which is a pitty, as car makers are most probably one industry branch which managed to cut costs and improve productivity at large scale.

Therefore, I would like to ask: how about professionalization of people who want to professionalize an industry?!

“What is the optimal team size?”

This is a recurrent question in a lot of organizations. And there are two main approaches to answer it. An approach (like SCRUM’s one), sets a (so called) “natural” limit to x collocated team members. This limit is often presented as an a priori limit, even if some heretics allow themselves to set the limit higher if the team’s dynamic increases. Organizational design is not considered as a choice variable: collocation is preferred, there is a “natural maximal team size”, the only possible organizational change is a team split, etc.

Another approach consists in creating a mathematical model, in order to simulate variable impacts and find the optimum setup. This approach is quite new (first publication between 2002, 2004), but is very interesting. Simulation is nowadays widely used in a lot of industry branches, so why not apply simulation to organizational field?

A very interesting example of this model approach is described in the paper “Optimal team size and monitoring in organizations“, from Pierre Jinghong Liang, Madhav V. Rajan, and Korok Ray, from repectively Carnegie Mellon, Standford and Chicago universities. As the title suggests, organizational design is seen as a non static variable (an optimum can be found), and a link is established between team size and monitoring. But this is not all: incentive contracts offered to workers and managers are of course also taken into account. Team size, monitoring and incentive contracts are the 3 “instruments” used in this approach. Although  interactions between the model’s agents (workers and managers) may be complex, the modelization and associated simulations leads to some rather simple learnings:

• the robustness of workers contracts
• it is almost never worthwhile to employ multiple managers to supervise a given set of workers
• complementarities between team size and monitoring, and between worker talent and managerial monitoring ability

These are already interesting results, although used model is static in time. It may be expended to take into account variations over time. The link established between team size and monitoring is also interesting, as monitoring now plays already a key role in modern organizations.

T Indicator

Usually, an implementation cycle starts with a commit, which is the moment in time where both business and workers agree on the value to deliver. The workers commit to deliver this value at the end of a sprint or release. But for various reasons, the final reached value may be different, because  some requests may be dropped out or added,  and some effort may differ from initial estimations.

In order to display these kind of values in one single and simple visual indicator, I had the idea to use stacked columns type of chart, mixed with a maximum vertical line.

As a consequence of the T shape in the middle, and because T is target first letter, I proudly named this new indicator the “T indicator“.

This indicator is intended to be very easy to read, as it does not require to “mentally” move objects to get a global picture of the situation. It avoids to use 4 different columns with different colors, or pie chart parts, standing to each other. Therefore, it’s much more compact, and should impact faster the eyes looking at it.

How to read it

• the top of the column represents the delivered value,

• the “T” is set to the initially committed value,

• the light blue block height represents the amount of added value,

• the dark blue block height represents the initially committed value minus removed value.

In case you might be interested in using it, feel free to download the Excel spreadsheet! This file is in MS Excel 2007 version, but will work in Excel 2003.

Possible extensions

There are two main types of reason why a backlog may change during a sprint:

• added or removed business requests,

• grown or lowered effort compared to initial estimations.

The current version of this indicator does not make any difference between the reasons why the backlog changed. But it may be included by using different color codes on half side of the column.

Exemples

Value target not reached.

Positive value delivered, some value removed, some value added.

Positive value delivered, value added, no removed value.