DIGITAL INNOVATION

Allen provided our class with a case study on IONA Technologies:

IONA Technologies was an Irish software company, founded in 1991. Incubated and born out of the academic centre of Trinity College, Dublin, the company became a fast-growing ICT startup with headquarters in Dublin, Boston and Tokyo. Focusing on technology excellence, they specialised in distributed service-oriented architecture (SOA) infrastructure. Their products connect systems and applications by creating a network of services without the need for a centralised server or an IT stack.

The first case study outlines the growth of a group of Academicians & Engineers doing research and development in Trinity College into a pioneer IT company in Ireland. Starting with client and developer trainings for their products, they soon realised that professional services (consulting) could become an important revenue stream. The soon served various customers in various industries with different products and consulting services. The case study highlights the challenges of rapidly growing ICT company. The professional service team, consisting of "the crème de la crème" of their engineers, together with Marketing and Sales were the only to have customer contact. The IONA engineers were fixing product bugs in the client site, resulting in a lack of knowledge transfer within the organisation. No bug tracking processes within IONA existed, increasing the challenge of delivering the quality products the clients needed and wanted.

The second case study concerns the challenges of managing the increasing workforce and complexity. Management of cost and complexity (resources) within the different team members was one of the main issues at IONA Technologies. An over commitment by the management to the clients, the increasingly difficult and complex processes, fix-quick-mentality made it increasingly difficult to maintain the quality and service standards when increased in size. The management did not execute good leadership by lacking strategic vision and goals and poor decisions on the company's investments into dated technologies when in fact they should have invested in new different solutions. They were stuck in the Innovator's Dilemma, sticking too close to the current customers, managing the existing complexity without anticipation into future products and markets. 

The overall criticism lies on their development processes having been outdated and very much like the waterfall model (Planning, Developing, Testing and QA and Launching). They actually should have embraced new more agile methodologies and frameworks like SCRUM or Extreme Programming. Of course, the application of methodologies always must suit the context and environment but given that their products were open platforms, vulnerable of the constant external  and situational changes, they should have applied a methodology allowing them for greater reactivity and responsiveness.


In the brochure of Trinity, it says that IONA was on of the top 10 companies in ICT with this highest IPO in history. It was acquired in 2008 fo $162 million.

Lego. We all loved these brick-like plastic pieces to build castles, dragons, cars or the star-wars chip.

But when these lego bricks suddenly transform to a digital product because some technological add-on or motor has been topped on, we were the biggest fans of all times. Lego Cars, Lego Robots and so forht

In fact, it has only been a week I was attending Web Summit in Lisbon. I honestly did not listen to a lot of talks as I knew they would be available on-line after the event, but for some talks and topics I could not resist. Legos was one of them.

It was about the fact that companies would need to shift their focus from looking outside their firm to find innovation but rather to exploit effectively the resources they had. Their employees but also their clients. Lego is the most engaging brand in the world on social media and that all because Lego uses its social channels and feeds to kid's and creative's challenges. By calling for their community to come up with new ideas or join a wave of existing ideas with competitions, they also solve two problems at the same time: customer engagement and idea sourcing from outside. How were they able to do this? Their internal social media and idea development team sits together every Monday with the sole purpose to launch a new challenge or idea for the community. The whole Monday is dedicated to experimentation. At the end of the day, the idea with the most votes will be casted in the shooting on Tuesday and published by Wednesday. Thursday and Friday are used to evaluate the campaigns and lessons learned from the previous week. Sometimes, the challenges can become self-drivers and grow to a movement like the Lego Man that went on travels in the world. This social feed is years old and still there are a few hundred uploads a day. Sometimes, new ideas emerge from previous campaigns so the system becomes a closed cycle of innovation: idea generation, deployment, sharing, replication, evaluation, idea generation. Incredible!

'Agile'. 'Lean'. 'Simple Design'.. You hear it everywhere how the - originally - software methodologies have been appropriated by other teams to develop and manage their business models, products and projects to become more customer centric, iterative and more focused on rapid testing. Multiple iterations, early feedback and adaptable product development go along with the idea is 'fail cheap, fail quick, try better.' 

Before the 'agile revolution', software development teams have been primary working with the waterfall methodology. Beck (1999) introduced the Extreme Programming methodology as one of the early adopters of agile software development methodologies. Rather than working on a process of 1.Analysing, 2. Designing , 3. Implementing and 4. Testing, the agile is an adaptive, iterative method where these activities are all executed throughout the software development process. 

However, agile methodology seems to be more of a philosophy rather than a simple method to apply.

The methodology not only needs to fit into the context given, but also the team has a primary influence on whether the process is successful or not. Krutchen (2007) explains agile as a culture. The idea that software development becomes a team activity where the members of the group code in pairs, interact with each other, test, iterate and challenge their idea and quality continuously requires a strong team spirit and increases the complexity of managing these teams. This is where SCRUM came into play. Williams et al. (2011) explains SCRUM as:

'an agile software development process that works as a project management wrapper around existing engineering practices to iteratively and incrementally develop software.' (Scrum + Engineering Practices: Experiences of Three Microsoft Teams, Williams et al., 2011)

Nevertheless, many teams mix up the methodologies to fit into their individual context. While extreme programming normally requires the customer to be involved in the development process, this role is often replaced by the product owner or another leading member of the team. Many teams do not label the way they work as "agile", "SCRUM" or "extreme programming" but rather define themselves as opponents to the "waterfall model".

Nowadays, we can discover these lean development methods even in the development process of physical goods or even strategies. Human-centered-design and design thinking methods that involve the customer in the development process have become the source of creating sustainable products and business models. 'The lean startup' focuses in rapid prototyping, multiple iterations of the model and testing before engaging into pre-defined strategies that bear high risks and uncertainty. 

Lately, we have been discussing in class why software development can become a complete disaster and result in a "big ball of mud" (unstructured, complex codes). The reasons can be multiple: management (too close or too lose), the wrong team, the wrong process but also the wrong attitude. 

In order to work together on successful software development, every member of the team needs to work towards the same goal, giving the best he can and supporting his/her team members. 

One pattern that appeared in the article "they write the right stuff" (Fishman, 2007) was the notion of healthy rivalry. The software development team is seperated into two teams: those who create the codes and those who test and verify the codes. The fact that the teams worked against each other in terms of quality assurance but were aligned to work towards a common goal (developing the best software) made this process particularly successful. The code creators, knowing their code would undergo critical assessment and quality tests, would put more efforts in pre-testing their own codes and delivering better results to that the opposite team had fewer mistakes to reveal. On the other hand, the verifiers, trying to reveal all mistakes in the code, were twisting the codes upside down to find all possible mistakes and "beat" the other team. However, is mistakes were made in the end, no individual scapegoating or blaming would be allowed as their created and verified the codes in group. If there was a mistake, the process and system allowed the mistake to occur, so everybody was responsible.

But it is not just about the process. It is very difficult to find the right people that would feel comfortable in such a setting: being controlled, work as a team, no individual blaming but of course in return also no individual rewarding was possible. This is particularly interesting as many people mistakenly believe that "IT staff" and developers do need to have team spirit, communication skills and leadership responsibility. But in fact, this example shows that this self-directed and auto-sustaining process of creation and correction requires these skills and capacities from the team.
This is just another great example of management myths in software development.