Even Agile can fail!

11 Mar

There is no doubt that Agile software development is an improvement on traditional development methods, but is it perfect? Does every team to implement agile techniques and practices suddenly learn to move mountains, part the ocean? Unfortunately not. While project fail rates have been reduced from the catastrophic pre-Agile rate of 60%, about 40% of projects still fail, and still cost the economy tens of billions of dollars per year, a fact that is not widely reported.

I hope to show in this blog post that in most, if not all cases, when Agile fails it is due to poor implementation of methods rather than any fundamental flaws in the Agile methodology itself.

In a way, Agile ideals are the cause of its problems. The most well-known benefit of Agile is an exponential increase in the speed at which actual working iterations of software are created. Unfortunately (and this will become a pattern throughout this post), in many cases those who chose to implement Agile methods read about them and took away “It’s fast. Software will be finished quickly if we have a lot of meetings and don’t waste time documenting everything.” Job done, right? Wrong. Agile has never placed an emphasis on speed. The truth is that it’s founders know that if you try to do the right thing the right way every time, more than likely once it’s done, it’s done. No changes, patches, bug fixes, and definitely no scrapping the whole project and starting again. This will result in finished, fully functional software that satisfies the needs of the end user and does add value to a business, and the team will get there faster than if they barrelled through for two years, only to find out upon completion
that the end users hate the UI and that the program cannot perform it’s intended function.


Agile methods are so well documented, intense, and focused on participation and communication that it is quite easy for a team to focus more on how stringently they are following their chosen method than on the ideas being generated, or work being produced. The Agile concept is derived from a very organic situation; Some programmers that work together by choice on a project, and discuss what they are working on very regularly, purely out of interest. The benefits of this organic process are obvious, and while it does take effort to replicate processes such as Agile, in truth, it was never meant to be applied to every software development project or every team in the same way. Agile was created by ‘star’ programmers, those who love what they do. The aim of Agile is to replicate the enthousiasm for a project that creates great software, by highlighting problems affecting a team, like a mother in law constantly pointing out shortcomings. The secret to success is to respond well to these red flags. For example, a team’s work may be affected due to not gathering enough information on business requirements. After their first iteration of working software is released, feedback from the shareholders will show that their requirements were not sufficient, and will help to further define them. This results in an improved performance in the second sprint, and so on. To sum up, good feedback reduces the timeframe of a project, as things will not have to be repaired, or started from scratch. Do the right things, do them right, do them now.

The other aspect affecting the timeframe of a project is the level of craftsmanship or expertise of those involved. This is comprised of two elements: Domain knowledge and expertise. Domain knowledge refers to each team members knowledge of WHY they are developing this project.

‘Everyone should clearly understand what we are doing,


and why it is important at this very moment in time.’

It is hardly surpsising that developers know more about writing code than about, for example, the processes of the insurance providers they are writing a program for, and vice versa. However, in order for good programmes to be written, it is important that developers learn about the business that their software will be supporting. WHY must our program fulfill these requirements? Likewise, the shareholders would benefit from learning a little about the workings of the programs they demand, as this would result in clearer, more understandable requirements. Finally, the project manager must understand why he is implementing agile methodologies. Many ‘Scrum Alliance’ courses offer to certify managers as scrum masters in as little as two days, which is not possible. Managers with this level of experience should consider themselves apprentices, and seek out further guidance. Issues that may otherwise result include too little emphasis on documentation, incorrect sequencing of tasks, or too little emphasis on how problems are solved.

Documentation should be produced as and when it is needed. In waterfall methods, documentation is produced upfront at the beginning of a project. Many teams feel with Agile that documentation is an unnecessary waste of time, which is not the case. It should merely be done at appropriate times, where the cost of producing it is less than the benefit it gives.

Though less effective than face to face communication, it is a key principle that will give Agile scalability, and aid it in overcoming the issue of large or distributed teams.

Regarding task sequencing, while Agile emphasises adjustment over static plans, a general architecture of the project must be maintained, with sprints sequenced correctly to allow feedback, comparison to the overview, and finally, the adjustments that make Agile what it is. This is the main purpose of the project manager, to choose the specific times new or different requirements and feedback are incorporated into the original plan. Agile does NOT mean forgetting about the big picture.

TRIZ is a problem solving methodology which is highly applicable to Agile, and will aid the production of effective software, as it can be used to solve problems with applying Agile methods, problems with developing software, and answering the question of what software to produce. TRIZ is a very detailed idea and so I will provide a link:


The main issue affecting Agile is how different it is. In order for it to reach full potential, many large organisations would have to make drastic and costly changes such as allowing their basic information support systems to be updated continuously, only working in small, localized groups, and most importantly, being more open and less suceptible to mediocrity. If a team or team member is underperforming in an Agile situation, it is obvious very quickly. The need for excellence at all times may never be achieved. Managers in general do not like this idea. Agile’s supporters (mainly software developers) do not attempt to understand the barriers to changes of this scale in large organisations that are already profitable. It is the gap and resultant lack of understanding of each of these opposing mindsets, one could say a lack of domain knowledge, that stands in the way of Agile reaching it’s potential, and the value that it could add to business as a whole. Perfection is a direction, not a destination.


Developing information systems

11 Mar

There are various approaches to developing information systems. These include examples such as traditional systems life cycle, prototyping, software packages, end user development and outsourcing. Firsty SDLC involves building the system by completing 6 stages sequentially:

  1. Project Definition
  2. Systems Study
  3. Design
  4. Programming
  5. Installation
  6. Post-implementation

Prototyping involves building an experimental system quickly and cheaply and is good as it is fast and has alot of user involvement. Software packages involve purchasing programs that have been written and tested and are good as they are cost saving, there’s limited technical skills and clear expectations. End-user development then involves building the system by end-users with little or no formal technical assistance. Finally, outsourcing means using an external vendor to develop or operate an organisation’s I.S.

Each approach should be safeguarded by security and quality assurance. I.S security includes, data, hardware and network security and also a recovery plan. Quality assurance includes, development methodology, quality measurements, programming standards, testing, development tools and quality audits.

Thanks for reading 🙂


The Spiral Model

11 Mar

Modern day Information systems used by businesses follow models of development I would like to examine one such model in detail. This is a commonly used model called the Spiral Model.

The spiral model, also known as the spiral lifecycle model, is a systems development lifecycle (SDLC) model used in information technology (IT). This model of development combines the features of the prototyping model and the Waterfall Model. The spiral model is favored for large, expensive, and complicated projects. This model is often used by large multinational companies and is very expensive to implement firms such as KPMG have utilized this model to great effect.

The steps in the spiral model can be generalized as follows:

  • The new system requirements are defined in as much detail as possible. This usually involves interviewing a number of users representing all the external or internal users and other aspects of the existing system.
  • A preliminary design is created for the new system. Based on the requirements of the company.
  • A first prototype of the new system is constructed from the preliminary design. This is usually a scaled-down system, and represents an approximation of the characteristics of the final product. It will take time for all the minor details of the information system to be ironed out, this will be achieved through discussions and company meetings to decide the best design to go with.
  • A second prototype is evolved by a fourfold procedure: (1) evaluating the first prototype in terms of its strengths, weaknesses, and risks; (2) defining the requirements of the second prototype; (3) planning and designing the second prototype; (4) constructing and testing the second prototype. This prototype should be close to the final information system.
  • At the customer’s option, the entire project can be aborted if the risk is deemed too great. Risk factors might involve development cost overruns, operating-cost miscalculation, or any other factor that could, in the customer’s judgment, result in a less-than-satisfactory final product. This is a critical step as if the company goes ahead with the project and it fails it can lead to the firm loosing a large amount of revenue.
  • The existing prototype is evaluated in the same manner as was the previous prototype, and, if necessary, another prototype is developed from it according to the fourfold procedure outlined above.
  • The preceding steps are iterated until the customer is satisfied that the refined prototype represents the final product desired.

The final system is constructed, based on the refined prototype. The Spiral Model is a well regarded method that is used worldwide and has proven to be effective.




Advantages & Disadvantages of the Spiral Model

11 Mar

Advantages of Spiral model:

  • High amount of risk analysis hence, avoidance of Risk is enhanced.
  • Good for large and mission-critical projects.
  • Strong approval and documentation control.
  • Additional Functionality can be added at a later date.
  • Software is produced early in the software life cycle. 

Disadvantages of Spiral model:

  • Can be a costly model to use.
  • Risk analysis requires highly specific expertise.
  • Project’s success is highly dependent on the risk analysis phase.
  • Doesn’t work well for smaller projects.

 When to use Spiral model:

  • When costs and risk evaluation is important
  • For medium to high-risk projects
  • Long-term project commitment unwise because of potential changes to economic priorities
  • Users are unsure of their needs
  • Requirements are complex
  • New product line
  • Significant changes are expected (research and exploration)




Spiral Model

11 Mar


In order to overcome the disadvantages of older models such as the waterfall model, it was necessary to develop a new Software Development Model, which could help in ensuring the success of a software project. The Spiral model incorporated the common methodologies followed in the waterfall model, but it also eliminated almost every possible/known risk factors from it.

There are four phases in this model which are: Planning, Evaluation, Risk Analysis and Engineering. These four phases are iteratively followed one after another in order to eliminate all the problems, which were faced in the waterfall model. Iterating the phases helps in understating the problems associated with a phase and dealing with those problems when the same phase is repeated next time, planning and developing strategies to be followed while iterating through the phases. The phases are:

  • Plan: In this phase, the objectives, alternatives and constraints of the project are determined and are documented. The objectives and other specifications are fixed
  • Risk Analysis: This phase is the most important part of spiral model. In this phase, all possible (and available) alternatives, which can help in developing a cost-effective project are analyzed and strategies are decided so as to use them. This phase has been added specially in order to identify and resolve all the possible risks in the project development. If risks indicate any kind of uncertainty in requirements, prototyping may be used to proceed with the available data and find out a possible solution in order to deal with the potential changes in the requirements.
  • Engineering: In this phase, the actual development of the project is carried out. The output of this phase is passed through all the phases iteratively in order to obtain improvements in the same.
  • Customer Evaluation: In this phase, developed product is passed on to the customer in order to receive customer’s comments and suggestions which can help in identifying and resolving potential problems/errors in the software developed. This phase is very much similar to ‘testing’ phase.


The process progresses in spiral sense to indicate the iterative path followed, progressively a more complete software is built as we go on iterating through all four phases. The first iteration in this model is considered to be most important, as in the first iteration, almost all possible risk factors, constraints, requirements are identified and in the next iterations, all known strategies are used to bring up a complete software system. The radical dimensions indicate evolution of the product towards a complete system.

However, as every system has its own pros and cons, the spiral model does have its pros and cons too. As this model is developed to overcome the disadvantages of the waterfall model, to follow spiral model, highly skilled people in the area of planning, risk analysis and mitigation, development, customer relation etc., are required. This along with the fact that, the process needs to be iterated more than once, demands more time and is somehow an expensive task.

I know that this is technically a late submission, i would appreciate if we could overcome this. Thank you.




Final blog: Advantages of being a systems analyst:

11 Mar

As it is the end of the blog I felt that I would give a few advantages of been a systems analyst. This information is good for those who would be interested in the pacific career.

Advantages of being a systems analyst:

•Full-time computer systems analysts usually receive benefits. The typical benefits include health insurance, paid vacation, and sick leave. Some employers also pay tuition for computer training courses and offer a retirement plan.

•Much of the demand for systems analysts is the result of advances in computer technology. New computers can accomplish more difficult tasks and process more information. As a result, businesses are upgrading their computer systems or adding new systems. This gives a very demanding need for systems analysts within many big and small firms.
•The computer industry appears to be one of the fastest growing areas; there are often available jobs for system analysts so the unemployment rate for that pacific job is very low.

•They have a moderate level of social contact. They work with staff, but also spend time alone while programming.

•They always work as part of a team.

•They usually work at least 40 hours a week.

•They also get to travel to trade shows, seminars, and trainings.



Summery of “The Value Of Information”

11 Mar

With this being my final blog I decided to give a brief summery on the topic ” The Value of Information”.

From doing this project I now understand that information is vital for organisations to become a market leader and to be able to earn the maximum profits available. Whether it is just acquiring the relevant information or the sufficient amount, firms need to ensure they research that information fully. Any “half-assed” attempts when acquiring information will have a negative effect on the topic/project. I have also learned that its not only business firms that benefit from acquiring information, but that  schools and sports clubs etc do to.

Firms need to ensure that any information gathered contains the five characteristics, ( accurate, timely, relevant, just sufficient, worth its cost), so that it can be considered good information. It not worth the firms time to make decisions using information that does not contain these elements.

I have found that one way “good information” can aid a firm is when they want to learn more about their competition. This information can be key for firms trying to get one-step ahead of their competition. Another area in which information can benefit a firm is if they are looking to expand, it is essential to gather enough “good information” to see if its financially favorable to expand.

Overall I have enjoyed completing this project as it has helped me to understand “The value of Information” a lot more by making me go and find out about it myself.

I hope ye have enjoyed reading my blogs over the past few weeks!

%d bloggers like this: