Since decades military and political leaders have used a strategy of “divide and conquer” (from Latin “divide et impera” as implemented in the Roman Empire, to tackle complex challenges. Our interpretation of a recent article by McKinsey & Co. on large scale Software projects as well as our understanding of agile practices lead to the conclusion that the strategy already defined by the Romans is also of high value in today’s application development projects. The concept of tactical maneuvers to efficiently deal with a numerous opponent by dividing the opponents forces in smaller pieces and fighting the battle one by one is related with dividing a complex requirement for an application development into smaller, manageable steps such as Stories or Tasks. At the same time the military leader always needs to have the overview and be in control of the overall battle. In case of an application development this leads to the need for a strict governance / an stringent reporting to be in place. The winning combination offers “the best of both worlds”.
Exhibit 3: Divide (agile) plus conquer (classical) is the best choice for success of large SW projects as described in the pliXos article “Rigorously Agile”
There is a demand for sizeable, well-engineered software. Nevertheless, we continue to have large numbers of project failures. Software appears to be difficult to engineer on a large scale. Searching the World Wide Web (www) for failed IT or SW projects one will see that many or most of these failures are due to failures in project management.
Some other characteristics:
- The project was expensive (way over budget)
- The project was not coordinated properly (internally or between the client and the provider)
- The projects took long time to implement than the expected or desired time frame
- The project failures were not noticed on time
For further insights please read: IT Projects Management: Infamous Failures, Classic Mistakes, and Best Practices published in the MIS Quarterly Executive Vol. 6 No. 2 / June 2007 67.
Many players offer solutions addressing those reasons for failure of large software projects. One example is explained in the article “Achieving success in large, complex software projects” by McKinsey&Co.:
A joint study by McKinsey and Oxford University found that “large software projects on average run 66 percent over budget and 33 percent over schedule; as many as 17 percent of projects go so badly that they can threaten the very existence of the company”. Assuming large projects are defined as projects which have a completion time of more than 12 months and a large number of people are involved in the project with a large sum of capital input, we are convinced that also mid-sized SW projects are facing similar challenges and are major challenges, especially when the company considered itself small. Most common reason for a project to fail is the lack of coordination between business analyst, separate developers, separate testers, etc. when they are organized on the basis of function with multiple handoffs as shown in the Exhibit 1.
Exhibit 1: Traditional application-development teams are organized by function, with multiple handoffs. (Source: McKinsey&Co. article “Achieving success in large, complex software projects”)
Lack in coordination and the organization on the basis of function with multiple handoffs leads to certain uncertainties, confusion, lack of a perfect goal, lack of correct information in case of a change of the desired goal and lack of proper indication how the project will land up at the end. Certain lack of accountability and no information from the other departments on the same project are major factors, as shown in McKinsey&Co. article through Exhibit 1.
Exhibit 2: Work cells are organized by modules, with end-to-end ownership across functions. (Source: McKinsey&Co. article “Achieving success in large, complex software projects”)
According to those authors large, complex software projects are better served by work cells—cross functional teams with end-to-end ownership of application modules. The role of the project manager becomes ensuring that cells deliver their modules, rather than managing communications and handoffs between functional teams (Exhibit 2).
Getting all those involved in the project to the same team doing the end to end job (from understanding the requirements, development to testing and GoLive) is one of the keys to success. When using one team for the end to end process, the overall tasks needs to be broken down into smaller pieces which McKinsey&Co. calls modules. The requirements need to be broken down in small, understandable pieces (e.g. building on Use Cases). This is similar to User Stories and Task when doing agile according Scrum (this break down and tracking of the requirements can well be done with the pliXos Outsourcing Director).
Let us see how this relates to Scrum. We find that the concept of divide is in line with the need of the hour for the IT and SW Industry so that it can help them not fail in their projects big or small. The following are a few points where McKinsey and Scrum come together:
- Split organization into small, cross-functional, self-organizing teams (Work cells)
- Split work into a list of small, concrete deliverables. Sort the list by priority and estimate the relative effort of each item (End to end ownership)
- Optimize the release plan and update priorities in collaboration with the customer, based on insights gained by inspecting the release after each iteration. Optimize the process by having a retrospective after each iteration (Cells deliver their modules, rather than managing communications and handoffs between functional teams)
All the aforementioned topics are well aligned with the views pliXos already expressed in 2011 on how the best of Agile and Classical methods are to be build upon to benefit the SW industry:
Those views of Joerg Stimmer, founder and Managing Director of pliXos are described in his article to outsourcemag.com (article originally appeared in Outsource Magazine Issue #25 Autumn 2011) titled “Rigorously Agile”. The solution proposed is to take “the best of both worlds” – Agile methodologies as well as classical software engineering – in a way that keeps the benefits of both approaches but eliminates their drawbacks in the right combination.
Exhibit 3: Divide (agile) plus conquer (classical) is the best choice for success of large SW projects as described in the pliXos article “Rigorously Agile”
As already the Roman emperor understood by “divide and conquer”, building on the best of an agile approach as well as a strict governance, success for SW projects (in particular large and complex) ones will be achieved.
Comments or interested in digging deeper? Contact us directly at This email address is being protected from spambots. You need JavaScript enabled to view it. or This email address is being protected from spambots. You need JavaScript enabled to view it..
