How can Agile methods and DevOps improve IT project success rates?

The statistics about IT projects success rates are shocking, to me the most interesting statistic in this article is:

“On average, large IT projects run 45 percent over budget and 7 percent over time, while delivering 56 percent less value than predicted” (Bloch, Blumberg, & Laartz, 2012).

In this research journal entry I want to investigate what are the potential causes of these high failure rates and if the implementation of the principles and values in Agile methods and DevOps at the deployment end of software development projects can help in reducing these failure rates.

What are the issues causing the high IT project failure rates?

As we discussed in SYD701 a few weeks ago the likely cause of why there is such a high IT project failure rate is that projects are so complex nowadays that we do not have the methodologies or thinking paradigms to successfully build the systems on time, on budget and within or above expectations.

What do I mean by the projects being complex? Well the needs IT systems are attempting to solve nowadays are not easily definable,  there are many ways the system can be developed and many different solutions that could meet the requirements, whilst the end result is not always agreeable to all stakeholders. In other words the need that the IT system being developed is trying to solve is a mess, meaning it is not easily definable, and there multiple processes and outcomes that could be produced.

The Linear systems thinking paradigm that spawned the Structured Systems Analysis and Design Methods (SSADM) is not designed to help development teams design and develop systems from messes, because the mindset of this train of thinking was you could understand a need necessitating a system by dividing it down to its smallest parts. However how can you divide down a problem/need when you do not understand it.

You can’t and that’s part of the reason why the SSADM is not suitable for systems development of the modern, complex systems we build nowadays.

Lets see some hard facts of IT project failures from a study performed by the consulting company McKinsey & Company and Oxford University:

IT issues.png

(Bloch, Blumberg, & Laartz, 2012)

Something important to note in all these ‘failed’ systems is the common characteristic that they all had high risks in terms of financial, temporal and benefits (Benni, 2012), where there are high risks, particularly where the risks change frequently then a non-iterative systems development methodology is not ideal as it is developed to address the risks identified at the start of the SDLC and will not identify and address risks that appear later on in the SDLC, and that is the reason I believe that the study found “Every additional year (in a projects development) increases the expected cost overrun by 16.8% and schedule overrun by 4.8%” (Benni, 2012)

This McKensey and Oxford study performed qualitative research on IT executives to identify what they believed the solution to these IT project issues was and they came to the following conclusions of what is required for a successful IT project:

  • “focusing on managing strategy and stakeholders instead of exclusively concentrating on budget and scheduling
  • mastering technology and project content by securing critical internal and external talent
  • building effective teams by aligning their incentives with the overall goals of projects
  • excelling at core project-management practices, such as short delivery cycles and rigorous quality checks”  (Bloch, Blumberg, & Laartz, 2012)


Does the SSADM align with these 4 fixes?

Clearly the SSADM does not meet the first and last of those fixes; after the initial elicitation of client requirements in the Systems Analysis stage of the SDLC there is little client requirement  elicitation throughout the rest of the project. It is hard for the SSADM to manage stakeholders to ensure the product meets their requirements due to its non-iterative nature, meaning if the requirements change then the system itself cannot change to meet them,

Additionally SSADM does not have short delivery cycles but instead it releases the product in large chunks, this can create a headache for the operations team that have to make sure the product developed in the development environment actually works in the production environment before it is released to the users. I believe this mammoth release of software at the end of the SSADM was part of the reason that the concept of DevOps was first conceived to create a change of mindset to the paradigm of small, frequent releases of software to the operations team.

So due to the non-iterative nature of the Waterfall model which the SSADM follows each project is effectively ‘stuck’ with the requirements identified in the systems analysis stage at the start of the SDLC, thereby not making this methodology useful in environments where user and business requirements change or if there is a high risk of change.

And as we have seen in the research entry journal about DevOps, this deployment model works through the deployment of software from the development to the production environment in small features frequently which are easier for the operations team to test, troubleshot and deploy.

Can Agile and DevOps can help?

Now in my opinion at this stage of my knowledge about Agile methods the implementation of Agile Methods would help enormously in fixing most of the issues related to because:

  1. Agile methods is timeboxed meaning it promotes that a project is split up based on blocks of time known as sprints. By focusing on time rather than features and due to its iterative nature producing prototypes that can theoretically be ready for deployment at the end of each sprint the Project Manager can ensure that there will be a deployeable product at the end of the project.

This product will likely have the most important features in it, because Agile systems development methodologies such as Scrum generally place the most important features (known as user stories) in the earlier sprints to ensure they will be completed.

2. Now going 45% over budget can be partially attributed to going 7% over time however the difference in the percentages means there is obviously other factors  involved and I have to be honest and at this stage say I am not sure how the implementation of Agile methods could help with this.

3. However Agile methods are very likely able to improve the missing focus statistics because there is constant communication between the development team and the clients throughout the agile project.

However in our SYD701 class last week we looked at the history of computer systems and the quote from the paper we were looking at A Short History of Systems Development interested me:

“The problems with systems today are no different than fifty years ago:

  • End-user information requirements are not satisfied.
  • Systems lack documentation, making maintenance and upgrades difficult.
  • Systems lack integration.
  • Data redundancy plaques corporate data bases.
  • Projects are rarely delivered on time and within budget.
  • Quality suffers.
  • Development personnel are constantly fighting fires.
  • The backlog of improvements never seems to diminish, but rather increases.”(Bryce, 2006)

This is interesting because it shows that the implementation of Agile methods will not solve all of the problems. The second issue in the list; a lack of documentation with modern systems; could easily be perpetrated by Agile methods which focuses on working software over documentation.

As I am working on the Koha Library Management System at work I understand how important it is to have good documentation to understand how a system you didn’t build works as a whole (we are lucky with the Koha project because being an open source project there is a lot of documentation to make it easier for new developers to contribute and so we have a wiki for Koha development).

This is an example of how Agile methods and DevOps is not the silver bullet, they do not solve all of the problems facing modern systems development.


Interesting resources on IT project failures:



Bloch, M., Blumberg, S., & Laartz, J. (2012, October). Delivering large-scale IT projects on time, on budget, and on value | McKinsey & Company. Retrieved March 24, 2017, from

Benni, E. (2012, April). Transforming the company Avoiding the Black Swans – Success Factorsa dn core beliefs in Value Assurance. Mobily CIO Summit, Istanbul. Retrieved from

Bryce, T. (2006, March 14). A Short History of Systems Development. Retrieved March 31, 2017, from


What is DevOps? and how does it relate to Agile methods?

Along with myself there were several other full-time summer IT interns at work over the summer, including one that was in the DevOps. When I heard he was working in that team I wondered what is DevOps?

Like I said in my previous research journal I am going to investigate what DevOps is, but I also want to see how (if at all) it relates to Agile methods.

What is DevOps?


(Vashishtha, n.d.)

The above image illustrates the key idea of DevOps beautifully. Put simply DevOps is the increase in communication, collaboration and automation in and between the development and production environments.

What is the current software deployment model?

To understand DevOps I wanted to understand where we are with traditional systems deployment and what the issues are that DevOps attempts to solve.

Software development companies are generally structured in teams (I know from my experience this is an important concept in modern development organizations).

The work of two teams in particular affects the profitability of the companies software, these teams are:

  • Development team – They actually build the software in the development environment
  • Operations team – They deploy the software to the production environment which they maintain.

Now in traditional software development companies (I am referring to companies that have not implemented the use of DevOps) there is on a level of mistrust due to the major issue:

  • The development environment (that developers work in) and production environments (that operations maintain) are configured differently meaning when code is deployed into the production environment it takes time for the operations team to get it working successfully slowing down the whole software deployment process

Now I would have thought it was common sense for the development and production environments to be as identical as possible so systems/features built in the development environment could be seamlessly deployed to the production environment but this has not been the case.

The sorts of problems having dissimilar environments are the production environment is less forgiving to software exceptions than the development environment, and so an exception that causes no observable error or warning in the development environment can crash the system in the production environment. Not good when trying to deploy software on a tight deadline.

It is the operations team that have to fix up the code for the production environment before it can be released to the customer and because this just adds another job to their tasklist this is why there is a level of mistrust between the development and production environments.

The development team, meanwhile gets a level of annoyance at the operations team because the time it takes to deploy the code they write holds up the development team from deploying new systems/features.

This gridlock slows down the whole software development deployment which has a business cost, because remember IT is just there to help businesses and organizations. The detrimental business cost is that competitive advantage of meeting a customers needs or filling a business niche may be taken by a faster deploying competitor.

How can DevOps help?

I look at DevOps as a metaphorical combination of a communication course and the equivalent of an industrial revolution in software deployment.

What? Let me explain with several points:

  1. DevOps attempts to increase the collaboration of the development and operations teams  thereby speeding up the time it takes to deploy software to the customer. This collaboration is like a communication course of sorts as it is making the two teams communicate more so their systems can become more alike.

2. DevOps attempts to free up more time for both teams by automating the software deployment process as much as possible. This means automating the testing, deploying, and monitoring of software in both the development and production environments using a set of tools.

Therefore I view DevOps as the industrial revolution of IT systems development, because like with the Industrial Revolution of the 18th and 19th centuries DevOps tries to automate as many tasks as possible allowing the workers to work on what can’t be automated.

Another change that DevOps does is it attempts to change the mindset of both teams because instead of working on big new features for existing systems, it promotes the development of small code releases that can be quickly tested, deployed and monitored in the production environment by automated tools.

The benefit of getting small chunks of software out to the customer quickly, rather than big chunks of software more slowly is that the company can gain the competitive advantage by filling a business niche with its quickly evolving system as opposed to missing out to faster competitors.

What are the tools that DevOps use to implement these 4 points?

To be able to build small chunks of code and automate the testing of them the organization will need to implement a tool like Jenkins ( (Rackspace, 2013).

They will also need a source control tool such as Git (Rackspace, 2013).

Tools that allow them to configure their environments, and automate the deployment of code to servers in the production environments  will be tools like Puppet ( (Rackspace, 2013).

The tools they use for application monitoring will be monitoring the system logs, these tools will be things like New Relic. The benefits of this tool is that it can monitor the system logs of thousands of servers and inform both teams of any issues of the new code  in the production environment (Rackspace, 2013).

Basically tools like New Relic make sense of vast quantities of data in much the same way (obviously on a much smaller scale and without the machine learning aspect) as systems like IBM Watson which trawl through vast quantities of data finding patterns and presenting insights (Rackspace, 2013).

How do the principles and values of DevOps and the Agile methods work together?

So Agile methods as I discussed in a a previous research journal entry are a set of values and principles to help development teams make decisions in the development of a product for a user.

This interesting YouTube video describes that the relationship between Agile and DevOps is that an Agile mindset exists from the:

  • User to the development team
  • and DevOps is from the Development team to the Operations team.

In other words they do not exists at the same time, this view is further backed up by this article in Information Week (

Now having looked at these resources my own opinion is even though there are minor differences in the way these two concepts are implemented, for example documentation is not viewed as highly as working software in Agile methods, whereas in DevOps documentation is required because the development team is handing the product to a new team (the operations team to deploy); the operations team has not worked on the product and so they require documentation to understand the system; something anyone who has worked on developing for an existing system they didn’t build will understand.

However, despite these minor differences I am amazed at the similarity in many ways of DevOps to Agile methods. DevOps changes the mindset of a software development organization so that it deploys software faster, which allows the development and production environments to use a more Agile methods approach to developing and deploying the small releases which happen more frequently than before DevOps was implemented.

So I believe that yes Agile and DevOps cover different parts of the systems development life cycle, with Agile methods covering the initial development of the product whilst DevOps covering the deployment of the product however the common fundamental concepts of smaller more frequent releases/deployment of software over one huge release, and increased communication between and within teams link these concepts together.

Interesting DevOps resources:


Vashishtha, S. (n.d.). Demystifying DevOps : Difference between Agile and DevOps. Retrieved March 21, 2017, from

Rackspace. (2013, December 12). What is DevOps? – In Simple English – YouTube. Retrieved March 24, 2017, from