One of our biggest challenges at Parallel Agile is explaining how two apparently unrelated aspects of our business are actually very closely related. Specifically, how our domain driven database and API generator (aka Parallel Agile CodeBot) enables the Parallel Agile Process, which allows large teams of developers to collaborate more efficiently and breaks the “two pizza rule” on team size.

To understand how the CodeBot enables large-scale parallel development we need to go back to Brooks’ Law, the widely believed postulate that you can’t accelerate a software project by throwing more developers at it. Fred Brooks identified some key reasons why this has been (for the most part) a truism for the last 50 years. Two of the most important reasons are:

1) Communication. When you add new developers to a software project, somebody has to explain to them how the existing code is structured, and the new developers each have to experience a learning curve before they can be productive. Generally it’s the experienced developers (who are already productive) that have to take time away from their own work to train the new folks. So adding developers can actually slow you down.

2) Integration. If you have a large team of developers working (relatively) independently, it’s going to be difficult to make all of the pieces plug together and play well as an integrated whole piece of software.

It’s important to remember that Fred Brooks developed his postulate while managing a large mainframe operating project (OS/360), which was introduced in 1964. That’s a long time ago. There were no UML modeling tools, no REST APIs, no NoSQL databases. So it’s not unreasonable to ask the question 55 years later whether any modern technical innovations might mitigate some of the underlying factors that have made Brooks’ Law seem to be inviolable for such a long time. That answer turns out to be Yes – making a domain model executable mitigates both the communication and integration problems and enables large-team development to work a lot better.

While I’ve never been a big fan of Brooks’ Law, when we started the research that led to Parallel Agile, there was no particular intent of trying to disprove it.  It started back in 2014  when Barry Boehm and Supannika Mobasser invited me to give a guest lecture on ICONIX Process in their  CS577 Software Engineering class at the University of Southern California.   Around this time I had developed an interest in geofencing, and had in mind to develop a geofenced mobile app that delivered coupons to your phone when you got physically close to the business that was offering the coupons. 

When I accepted the invitation to guest lecture I decided to ask if they would like me to grade a couple of UML homework assignments in addition to guest lecturing. They agreed so I split my Location Based Advertising project into 47 low level use cases and assigned one use case per student as homework (writing prototype code for the use case was optional extra credit).

To make a long story short, we were all surprised that the 47 independently developed use cases actually integrated into a cohesive system. I can clearly recall sitting in Barry’s office saying “you know, that’s not supposed to be possible” and Barry agreeing “yes, I know”. When we started investigating how the successful integration happened it seemed that we had made some fortunate choices of using a NoSQL database (Cassandra) and a REST API (Node JS), and giving all the students a code template that implemented the database access functions (aka CRUD functions) for a Cassandra collection that they could clone for their part of the database.

It turned out that having the domain model in place made communication across the large (47 student) team go pretty well, and having all of the database access functions available through a REST API allowed different pieces of the system (iOS app, Android app, web app) to integrate together with ease.  And when we studied the effort numbers it turned out that each of the 47 use cases took about 4 days to develop – a day on requirements analysis, a day on design, and two days of coding.

One of the student from that project joined the PhD program and implemented a code generator that turned domain models into Mongo DB and Node JS, and after using this successfully on several other projects we decided to start Parallel Agile.

So, to sum it up…having a visual model of the problem domain makes it easy for everybody to get on the same page about what’s being built.  Generating your database from this domain model, and having a uniform set of functions to Create, Read, Update and Delete items in the database makes it easy for everybody’s code to integrate together.  And that’s how a code generator enables large-scale parallel development.

Sparx Systems has been identified as an exemplar model regarding the firm's approach to Agile in an article published in the August issue of BA LENS online magazine.

The feature highlighted that in order to fully understand Agile, an organisation needs to embed the principles of Agile into it's DNA.

"Sparx Systems has built the agile mindset into the organization’s culture and to the delivery of the recognized products they provide to their global network of users."

In partnership with the International Institute of Business Analysis, Sparx Systems released the Tools & Techniques for BABOK Guide v3, a digital reference for IIBA's Business Analysis Body Of Knowledge. Tools & Techniques for BABOK Guide v3 can be accessed freely via the new Pro Cloud Server, viewed on any mobile device browser.

With the recent inclusion of OSLC RESTful API within Sparx Systems products, and increasing number of web-based integrations will be available to users of Enterprise Architect, Web EA and Pro Cloud Server in the near future. The Beta release of Enterprise Architect 14, slated for late 2017, will prove to be another quality product as a result of Agile methodologies and best practices.

Read the article in full on IIBA's BA LENS website

"Coming together is a beginning; keeping together is progress; working together is success." 

- Henry Ford

Ten years ago, Gartner published the Emerging Technology Hype Cycle Report, and identified “collective intelligence” as a technology that would have “the greatest impact” on business over the following decade. Now in 2016, a convergence of technologies has conspired to create a miasma of complexity so engulfing that there is no alternative but to adapt to it. Old responses to new norms are inadequate. So how is this challenge to be addressed to retain existing market share and build on achieved success?

A recent article “Let Go of What Made Your Company Great” in the Harvard Business Review (HBR) discussing organisational response states that “the appropriate solution to employ depends on the magnitude of the challenge and how much of the organization is affected by the challenge”.

The very organisational structures that sufficed to create success in the past now present the greatest risk to adaptive organisational response to the complexity challenge. The HBR goes on to demonstrate with business examples, that letting go of entrenched thinking requires bringing “the organizational reflex circuitry out of auto-pilot.” A survey on business agility recently reported that almost fifty percent of survey participants blamed opposition based company culture or philosophy for agile failures.

In “Collective Intelligence in Teams and Organizations” a paper by lead author Anita Williams Woolley from MIT, the team explores the ingredients required for the development of collective intelligence and describes collective intelligence as including “a group’s capability to collaborate and coordinate effectively” stating “this is often much more important for group performance than individual ability alone”.

Agile encourages enhanced communication, sharing of information and collaboration. A report in Forbes from 2015 by Steve Denning discusses how “Agile, Scrum and Lean arose as a deliberate response to the problems of hierarchical bureaucracy that is still pervasive in organizations today: falling rates of return on assets and on invested capital, a dispirited workforce, a decline in competitiveness and widespread disruption of existing business models.” In hierarchical models subordinates report upwardly to the bosses. In horizontal agile structures the team focusses on the customer and as Peter Drucker has stated, the single goal of a business is to create a customer.

The collaborative behaviour between self organising, cross functional teams has recognised similarities in swarm intelligence or stigmergy, the stimulation effect that individual effort has in guiding the work of co-workers and the behaviour that creates the shared outcome.

Through the agile software development methodology, the evolution of requirements and solutions supported by the collaboration activity patterns of agile teams is similar to those exhibited in stimergy. Team members are stimulated by the performance that they have achieved and they are also stigmergically stimulated by their environment which, apart from collaboration enabling technologies also includes management support.

Organizational theorist Ikujiro Nonaka suggests that innovation comes from serendipity. Knowledge is not created by information processing, but by “tapping the tacit and often highly subjective insights, intuitions, and hunches of individual employees and making those insights available for testing and use by the company as a whole". He adds “The key to this process is personal commitment, the employees’ sense of identity with the enterprise and its mission.”

Silos are the nemesis of serendipity. Different team members and stakeholders must be able to input information that is relevant to their roles and activities and that is useful to the other members of shared projects. This implies the necessity to capture this information in a model that is available to all team members overcoming their geographical limitation.

The emergence of new ideas, or innovation, through collaboration, has been commented on extensively. A single idea can lead to breakthroughs and competitive advantage and the idea of one person can be used by many others who can make small refinements or improvements to the idea or spark completely new ideas. These in turn become the normal as creativity destroys long accepted convention.

Collaboration is becoming a new enterprise standard. In the face of the challenges being presented by market uncertainty, successful transition to the most effective use of strategic information technology, is a priority for many organisations. Collaboration enables the enterprise to leverage the strengths of all its parts and by harnessing creative energy and increasing the chances of success, while reducing or eliminating process overlap and resource redundancy. The shared awareness of issues promoted through collaboration encourages trust and builds confidence in group stakeholders and synergises the collective response to problem resolution.

The mutual dependency of collaborative culture and Agile approaches, is essential for successful project delivery, which is ultimately decided by the customer. Whether the organisation is large or small, has not yet adopted Agile or is Agile progressive, a handful of factors are critical to success.

Flexible Planning
In a business environment where innovative disruption is encouraged and fail fast is the short term goal, it is essential that situational change gets a nimble response and to that end, flexibility must be built into planning. The World Development Report 2013 published by the World Bank notes that creative destruction is the mainstay of economic growth. A plan is essential but it is not indispensable and ought to be replaceable when a better idea presents itself. Adaptive schedule planning identifies milestones, but, maintains a flexible approach to get to them, while making allowances for the milestones to change.

Evolutionary Development
The evolutionary development approach is iterative and is accepted practice for Agile software development. Agile development principles are different. Change is accepted and expected and because Agile software developers accept change as a constant, they choose to work in this way. A central tenet of agile teams is that it is okay to fail and to try another method. Collaboration unites individual efforts enabling the team to accomplish goals. Failure is foundational to these efforts, as it provides opportunities for teams to review and re-organise strategies.

The Global Innovation Index (GII) has established itself as a leading reference on innovation and in 2015 published the eighth report titled “Effective Innovation Policies for Development”. This report stated that “Innovative enterprises are shown to be economically more successful than firms that rely on tried and true processes and approaches.” Agile processes embrace change, which translates as the customer’s competitive advantage.

Early Delivery
Early delivery is seen as a leading measure of progress and depends on several factors. Frequent releases of working software, to ensure shorter feedback cycles which in turn facilitate collaboration with customers. This development cycle also encourages discussion which reveals the status of development, uncovers problems and identifies ways of implementing solutions, while supporting learning and development of an understanding of the function of the system.

As implied earlier, higher revenue from stepped delivery is supported by Agile development philosophy which also promotes a culture of ‘perpetual beta’ or early and frequent releases. This high frequency iteration allows the customer to provide valuable feedback on a regular basis.

Continuous Improvement
Process improvement underpinned the successful growth of Toyota from its small company genesis to a global auto industry leader, over a relatively short period. Also known as Kaizen, continuous improvement, a lean based manufacturing approach, systematically seeks to achieve incremental changes in processes, in order to improve efficiency and quality.

Embracing Change
When change is viewed as an asset within an organisation, survivability and competitiveness are supported and the process of evolving to a future state is a cultural constant for such organizations. In the past, stability was seen as a positive attribute within an organisation and was the bulwark against change, which if possible was to be averted.

Today that strategy has been obliterated. Agile is the adaptability and responsiveness to change that is essential to successfully compete in the new competitive landscape. The iterative approach of customer driven Agile development teams, while reducing the size of the changes related to a software release, also increases the change frequency. Agile processes embrace change, which translates as the customer’s competitive advantage.