Final thoughts

For my final research journal entry I would like to wrap up the learning I have inadvertently done whilst learning about automated testing tools in preparation for my PRJ701 course. This learning is about the Test-Driven Development (TDD) framework which comes under the Extreme Programming (XP) Agile framework.

As I have discussed in multiple previous blog posts (‘How can Agile methods and DevOps improve IT project success rates?’, ‘What is DevOps? and how does it relate to Agile methods?’, ‘What is Agile methods, Scrum, and Kanban?’ blogs) Agile methods is a mindset (you could also refer to it as a way of thinking) based on four values and 12 principles outlined in the Agile Manifesto which was written in 2001 (see here for the principles and values

The methodologies that follow the Agile mindset are called frameworks and XP is a framework.

XP is very much a technology focused framework due to its use of Peer programming, Test-Driven Development, Refactoring and Continuous Integration; all of these practices are software specific, as opposed to Scrum which can be applied to non-IT projects.

Test Driven Development is where the developer writes unit tests (these test a small chunk of the code for example a single function or small piece of functionality) before actually writing the code that will be tested. When I say the developer writes the test, this will be in a testing environment such as Selenium and these are automated tests plans. At this stage the test will fail because there is no code written yet for it to test.

The benefits of writing the test before starting the development phase are that it forms part of an executable documentation i.e. it is documenting the user requirements  because each unit test is based on the user requirements being broken down to their smallest component. So by writing the unit tests you are also documenting the user requirements at the same time.

Secondly you are ensuring that all software will be tested because the test is written before the feature itself is written meaning the developer can test as they go, they do not have to find time to write a test after the feature has been written.

And thirdly you ensure that the user requirements documented in the automated unit tests are met and no extra unnecessary code of features are added. This benefit of the TDD is basically keeping development time and costs down by focusing the development team.

Another thing to keep in mind with TDD is that refactoring takes place after the developer has written the code, and the unit test successfully passes.

Whereas BDD (as I discussed in my blog ‘What is the Behat Framework and the Repository design pattern?’) concentrates more heavily on the client rather than the development team and their agility.

BDD does this by attempting to make the on-going intra-team and inter-team communication (i.e. inside the development team and between the development team and the stakeholder specifically the client) easier through the development of a common glossary of terms known as the Ubiquitous Language.

These terms are already familiar to the client (because they are based on the problem domain that the system is being built for) but it is useful for the development team to use them so when developers with different levels of knowledge and experience in the problem domain collaborate or communicate they have a common set of terminology which they all understand. I would say that this is especially useful in a remote team, because I know having terms documented in the Koha Wiki (I work in the Koha team at Catalyst in Wellington) is incredibly helpful with my remote work because I can understand what people say without having to send a clarifying message or email which takes longer to get a reply from than if your are doing face-to-face communication.

In BDD the developer writes BDD behavior tests before the coding begins and these tests record a larger set of functionality than the unit tests written in TDD and the trouble with these tests is they are like a black box; you put in a specific input and expect a particular output and if you don’t get that particular output value then the test fails but you don’t know which function failed.

Whereas the TDD unit tests are more useful in troubleshooting because they are more fine grained and so it is easier to identify what is causing the error to be thrown. That being said unit tests are not the only automated tests written in TDD also Integration Tests are written to test if large parts of the system integrated together work as intended. The combination of Unit and Integration Tests in TDD is a great advantage from a troubleshooting point of view because you have both the fine grained and big picture tests provided.

So in conclusion in my opinion TDD is more development focused by making the troubleshooting failed tests easier through the combination of unit and integrated tests whilst BDD is more client focused and the troubleshooting following a failed behavior test is slightly harder to perform.

Thanks very much for reading, and thanks to Clare (hope you feel better soon) and Belma for teaching RES701 I have really enjoyed the thought-provoking topics and I am really glad I choose to take this paper  🙂



Farcic, V. (2013, December 20). Test Driven Development (TDD): Example Walkthrough | Technology Conversations. Retrieved June 8, 2017, from

Kumar, M. (2012, November 5). What is TDD, BDD & ATDD ? – Assert Selenium. Retrieved June 8, 2017, from

Test-driven development – Wikipedia. (2017, April 21). Retrieved May 29, 2017, from




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

What is Agile methods, Scrum, and Kanban?

In our WEB701 class Todd recommended we try implementing SCRUM methods into our group practice project work.

I have heard Belma talk about Scrum and another SYD related concept of Agile a lot over the last two years and I am intrigued to find out more about them because I believe we will be learning more about them in SYD701. This research journal entry will define my understanding of what Scrum and Agile and Kanban are, and how they can be implemented.

I started by going to YouTube, that great source of information, I use YouTube for quite a lot of my research, particularly computer/software troubleshooting because I find video tutorials where they show you every step of fixing the problem infinitely more useful than written tutorials which often make assumptions and/or do not show every step of the process.

(Shead, 2016)


What are Agile methods?


(“Full Comparison: Agile vs Scrum vs Waterfall vs Kanban,” n.d.)

Agile methods is not a systems development methodology, like for example Object Oriented Systems Analysis and Design (OOSAD), instead it is a set of ideas and values that govern how a team should make all development decisions when building an information system for a client.

The agile ideas and values promote an iterative, time focused and user centered systems development process.

The set of ideas and values that Agile methods lays out are defined in the Agile manifesto, which is a document containing 4 values (outlined below) and 12 principles determined by 17 software developers in 2001 (as outlined here:

4 Agile values:

  • “Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan”(Agile Manifesto Authors, 2001)


My thoughts on agile methods

Agile is iterative meaning that it uses the spiral model for cycling through the different systems development stages. This is the same approach that Object Oriented Systems Analysis and Design (OOSAD) takes.

I know that Structured Systems Analysis and Design (SSAD) uses the waterfall model where it is hard to go back to a previous stage, making it significantly harder to incorporate new client requirements into the product compared to the spiral model.

If agile and OOSAD both use the spiral model having iterations how do they differ? Well as I see it the major differentiator is the amount of time and effort put into diagramming and documentation.

In OOSAD to successfully plan out the OO system being developed a number of UML diagrams are produced, whereas in Agile development the focus is less on the development diagrams and documentation and more on the development of working software.

By keeping the amount of planning, diagramming and documentation to a minimum for the iteration that is currently being worked on agile, as the name suggests, promotes a speedy delivery of prototype versions of the product.

Meaning agile methods are generally faster than SSAD and OOSAD.

What are key features of Agile?

  • Frequent communication within the team, and with the client to determine if the client is happy with how the product is developing and if they have any new requirements that will need to be included.

Due to the incremental nature of Agile methods new client requirements elicited after the initial requirements gathering can easily be added to the product. However they are only added after the developers estimate the additional time and consequent cost to the client, and the client has agreed to putting in additional resources (if that is that case).

  • No specific toolset such as CASE tools ( Computer Aided Software Engineering) e.g. Visual Paradigm
  • Organized by time, known as time-boxed

I understand this to mean that instead of planning the project in terms of features being developed, the project manager of a team following agile methods will plan out the time schedule of the project in slots of 1-2 weeks known as sprints, and features will be added into these sprints.

  • Fast moving which is achieved through succinct documentation, shorter meetings and less milestones


Requirements for Agile methods to be successfully applied to a project:

  • Smart and engaged client who has time and resources to give frequent feedback (SourceSeek, 2013)

Pros of Agile development:

  • Greater likelihood of a successful product being developed because it has changed as the environment and client requirements have changed

Cons with Agile development:

  • It is harder to estimate a project cost with certainty (SourceSeek, 2013)


Two systems development methodologies that implement agile methods

  • Scrum
  • Kanban

What is Scrum?


(Rouse, 2017)

As I understand it Scrum is a systems development methodology that takes the ideas and values promoted by Agile methods and adds builds on them:

Major concepts in Scrum are:

  • Every member of the development team has a specific role. These roles are: scrum master, product owner and Scrum development team.
  • Daily meetings (called the daily scrum) are held to allow the team to discuss what they did since the previous meeting, discuss any problems they are having and potentially get help, and state what they plan to work on today.
  • Features for the product being developed are called user stories. User stories are allocated to specific sprints in a document called a sprint backlog.

What are those Scrum roles again?

Scrum master: This is the person who helps the team stay on task, and goal oriented making sure that agile ideas and values are followed.

Product owner: This is the representative of the customers making sure that the team is defining and keeping in mind the customers requirements at all times.

Scrum development team: This can include developers, testers, designers and anyone else involved in actually making the product.

What are the steps in a scrum systems development life-cycle?

  1. The product owner elicits client requirements and makes a collection of user stories in a document called the product backlog.
  2. Sprint planning is where the team as a whole allocates user stories from the product backlog to the sprint backlog to be completed in the next sprint.
  3. The development of software to address the user stories in the sprint backlog is undertaken by the scrum development team. Every day the daily scrum meeting is performed so everyone in the team is kept up to date with all other team members. This is where the team can identify issues and developers can request help.
  4. At the end of the sprint there is a software outcome which could be deployed.
  5. A sprint review/retrospective takes place to determine what went wrong in the immediately previous sprint and what actions can be taken in the next sprint to ensure the same mistakes don’t happen again.
  6. Then the cycle begins again.

Often the most important user stories are transformed into code in early sprints so that if they take longer than predicted they can be finished off in the next sprint, meaning if the project reaches its end point without all user stories transformed into code, then the most important features of the product are in place so it could be deployed (Scrum Alliance, 2015).


What is Kanban?


(“Kanban The Agile Coach,” n.d.)

Kanban is another systems development methodology that follows the agile methods ideas and values. Kanban was conceived in Japan by Toyota.

The central concept of Kanban is a visual representation of the user stories as sticky notes on a whiteboard. The uncompleted user stories start on the left hand side of the Kanban board and move their way over to the right hand side.

By having this visual representation of the progress that user stories are at means that it is easier to keep track of how the project is going. Particularly since there are limits to the number of user stories that can be in a specific stage of completion thereby preventing work bottlenecks.

Kanban teams do not have the same roles as a scrum team, instead the team is made up of a wide range of developers and designers, along with a product owner (effectively the project manager). In the case of Kanban the product owner is responsible for making sure all tasks are working their way through the Kanban board from uncompleted to completed.


I have found it very interesting to read up about agile methods, and its implementation in Scrum and Kanban.

Something that really stands out to me is the focus of both these three concepts and DevOps on communication. As I understand it DevOps is making sure there is greater communication between the developers and operational teams managing the production environment so that differences between the development and production environment are learnt early and addressed.

I will cover DevOps in more detail in a future research journal entry as I am interested to know more about it because another intern at my work was working on DevOps over the summer.


SourceSeek. (2013, July 14). What is Agile Development (Part 1): What is Agile Development? – YouTube. Retrieved March 15, 2017, from

Shead, M. (2016, May 31). What is Agile? – YouTube. Retrieved March 17, 2017, from

Agile Manifesto Authors. (2001, February). Manifesto for Agile Software Development. Retrieved March 17, 2017, from

Rosenblatt, H. J., & Shelly, G. B. (2014). Systems analysis and design (Tenth edition, Instructor’s edition). Boston, MA: Course Technology Cengage Learning.

Rouse, M. (2017, February). What is Scrum? – Definition from Retrieved March 19, 2017, from

Scrum Alliance. (2015, June 25). What is Scrum? – YouTube. Retrieved March 19, 2017, from

Kanban The Agile Coach. (n.d.). Retrieved March 19, 2017, from

SourceSeek. (2013, July 14). What is Agile Development (Part 1): What is Agile Development? – YouTube. Retrieved March 15, 2017, from

Full Comparison: Agile vs Scrum vs Waterfall vs Kanban. (n.d.). Retrieved March 19, 2017, from