Speeding up the production of software development is a typical request to software development teams. A naive solution to this problem is to simply double the people working in a team to consequently double the output of the team. However, as experience shows, this typically introduces problems like organizational overhead, more communication effort, poor common understanding of coding style and functional requirements, less people with a good overview, poor ramp up and knowledge transfer capabilities. Therefore, we need different, more feasible approaches. In this paper, we describe such approaches, more specifically, we describe how visualizations, communication tools, team size and team staffing influence software development speed. This paper provides hands-on experience on how to reach the goal of delivering working and well-crafted software in time and in a distributed working environment at Infonova. We identified the following key areas for successful scaling and distributing of agile engineering: (1) team organization, (2) infrastructure for distributed development and (3) automatic visualizations and feedback.
Slides for a talk held in 2012 at the OTS Software Conference in Maribor (http://ots.si/Prejsnje_konference/OTS_2012/Povzetki.html#G_Oettl)
Direct Style Effect Systems -The Print[A] Example- A Comprehension Aid
Lessons learned in distributed agile engineering on a large scale integration solution
1. Lessons learned in distributed
agile engineering on a large
scale integration solution
DI Georg Öttl, Dr. Boštjan Grašič, Thomas Schenkeli, Dr. Stefan Klein
This slide shows the two lenses of the R6. On the left we see the process and module framework of the R6 and on the right we have the business architecture view of R6.
Focusing first on the process and module view on the left, we are showing three tenants at the top: VSO 1 through to VSO n.
Below the tenants we can see the red arrows which are the processes which are in turn supported by the blue boxes which are the modules. Since the platform is written in Enterprise Java 3.0, all the processes and modules are inter-connected by API’s. As a result all the tenants have access in their own right to the R6 functionality.
In other words, the tenants each have their “own” Product Mgt, Customer Mgt, Order Mgt, Billing and Accounts Receivables, as well as access to some aspects of the Platform & Business Mgt.
Additionally all this functionality is also available to the “primary operating entity” often called the wholesale aggregator, represented by the grey arrow titled “wholesale virtualisation and whitelabeling“.
Due to the platform design and its use of the API’s, the process and module framework translates into the business architecture illustrated on the right. As already mentioned, the primary operating entity or the aggregator has use of all the processes and modules, as do each of the tenants on top.
Hence R6 offers a service provider the opportunity to be the aggregator or the wholesaler, with the opportunity to support multiple tenants at the same time – all running their own separate business models. Of course, some service providers might wish to also be tenants on their own platforms as well.