Let’s consider a real-world example of using EVM to measure against a baseline to determine variance in an agile software development project.  The cost variance and schedule variance tells you whether your project is on-budget and on-time, which is a common question from most clients.  I will explain below how Earned Value Management is helpful in calculating the project cost variance and schedule variance and the parameters needed to calculate the variances.


When looking at the success rates of software development projects many are surprised to learn that the success rate is around 39% ,  18% fail and a whopping 43% are challenged according to the  “Chaos Manifesto 2013″ report published by The Standish Group.

Even though each project has its own unique set of reasons for failure, majority of the failures are related to three areas:

  • Poor budgeting
  • Lack of communication and transparency
  • Resistance to change

So how do we address these three areas that seem to contribute to the project failure?


One of the most beneficial features of agile-based development is the extremely rapid response time that short development iterations provides. When you aren’t bound by strict contractual guidelines, you can respond freely to emerging issues as the software develops. Unforeseen problems can be detected and addressed quickly and efficiently. There is one area of software development that can especially benefit from this ability to respond to new information but it is often overlooked.


Simply put, scrum masters keep the team productive. This sounds easy enough but it is actually a multifaceted role with many responsibilities.  To make the best use of scrum and to have the most effective team possible, the scrum master should only be responsible for one team on a full-time basis at any given time. However, if you scale back the extent to which the scrum master is involved with the team, and scale back his or her proactive duties, a full time scrum master could have two or even three projects working simultaneously.


As I work on agile software development projects with new clients, I am seeing firsthand just how important trust is to the success of the projects. Clients who have never engaged in an agile software development project are usually skeptical and leery about the whole business. They can’t see past doing business without a contract or control over the project. Since agile is more about engaging in an open and productive dialogue, building trust is key.


As a scrum master, I put a strong value on the Agile Manifesto’s first value:

Individuals and interactions over processes and tools.

Many development teams can do everything correctly, but if they don’t “know” the people on their development team, then they are not following Agile’s primary principle and will fail.


“If you are afraid to change something it is clearly poorly designed.”
― Marin Fowler

One of the most important steps in agile development is the refactoring. Before actually getting involved in agile methodology, we should spend some time writing the legacy architecture of the project. I do not think we should use this methodology when starting a project; I strongly believe it should be another step before the famous sprint zero. You should design your project first. I clearly understand that a well engineered code is going to help in long term for every agile project in several ways. If you don’t want to be afraid to change your code in the future, it has to be well designed and structured. This is done by people who engineer code; there is a huge difference between just programming and engineer code.