Archive | Agile Methods of Software Development RSS feed for this section

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.


11 Mar

Scrum is an iterative and incremental agile software development framework for managing software projects and product or application development.

 Scrum has three fundamental roles: Product Owner, ScrumMaster, and team member.

  • Product Owner: In Scrum, the Product Owner is responsible for communicating the vision of the product to the development team. He or she must also represent the customer’s interests through requirements and prioritization. Because the Product Owner has the most authority of the three roles, it’s also the role with the most responsibility. In other words, the Product Owner is the single individual who must face the music when a project goes awry.The tension between authority and responsibility means that it’s hard for Product Owners to strike the right balance of involvement. Product Owners must be available to answer questions from the team.
  • ScrumMaster: The ScrumMaster acts as a facilitator for the Product Owner and the team. The ScrumMaster does not manage the team. Instead, he or she works to remove any impediments that are obstructing the team from achieving its sprint goals. In short, this role helps the team remain creative and productive, while making sure its successes are visible to the Product Owner.
  • Team Member: In the Scrum methodology, the team is responsible for completing work. Ideally, teams consist of seven cross-functional members, plus or minus two individuals. For software projects, a typical team includes a mix of software engineers, architects, programmers, analysts, QA experts, testers and designers. Each sprint, the team is responsible for determining how it will accomplish the work to be completed. This grants teams a great deal of autonomy, but, similar to the Product Owner’s situation, that freedom is accompanied by a responsibility to meet the goals of the sprint.





Agile Unified Process (AUP)

10 Mar

Agile Unified Process is a simplified version of the Rational Unified Process (RUP).  It describes a simple, easy to understand approach to developing business application software using agile techniques and concepts yet still remaining true to the RUP.

The serial nature of Agile UP is captured in its four phases :

  1. Inception.
  2. Elaboration.
  3. Construction.
  4. Transition.

Disciplines are performed in an iterative manner, defining the activities which development team members perform to build, validate, and deliver working software which meets the needs of their stakeholders. The disciplines are:

  • Model.  The goal of this discipline is to understand the business of the organization, the problem domain being addressed by the project, and to identify a viable solution to address the problem domain.
  • Implementation.  The goal of this discipline is to transform your model(s) into executable code and to perform a basic level of testing, in particular unit testing.
  • Test.  The goal of this discipline is to perform an objective evaluation to ensure quality. This includes finding defects, validating that the system works as designed, and verifying that the requirements are met.
  • Deployment.  The goal of this discipline is to plan for the delivery of the system and to execute the plan to make the system available to end users.
  • Configuration Management.  The goal of this discipline is to manage access to your project artifacts. This includes not only tracking artifact versions over time but also controlling and managing changes to them.
  • Project Management.  The goal of this discipline is to direct the activities that takes place on the project. This includes managing risks, directing people (assigning tasks, tracking progress, etc.), and coordinating with people and systems outside the scope of the project to be sure that it is delivered on time and within budget.
  • Environment. The goal of this discipline is to support the rest of the effort by ensuring that the proper process, guidance (standards and guidelines), and tools (hardware, software, etc.) are available for the team as needed.

The Agile UP is based on the following principles:

  1. Your staff knows what they’re doing.
  2. Simplicity.
  3. Agility.
  4. Focus on high-value activities.
  5. Tool independence.
  6. You’ll want to tailor this product to meet your own needs.

Agile Software Development (Kanban) (vi)

10 Mar

This post will focus on Kanban vs SCRUM. There are many similarities between Kanban and SCRUM. These are as follows:

· Both are Lean and Agile
· Both use pull scheduling
· Both limit WIP
· Both use transparency to drive process improvement
· Both focus on delivering releasable software early and often
· Both are based on self-organizing teams
· Both require breaking the work into pieces
· In both, release plan is continuously optimized based on empirical data (velocity / lead time)


They are differentiated by the rules for the development team as to how they should work on a project. The Scrum process is quite prescriptive while Kanban is more open and this difference is visible from the rules of scrum and kanban, which are as follows:

  • The product owner organizes and managers the product backlog.
  • There are cross-functional teams
  • Once a sprint has been created, the tickets (tasks decided) cannot be changed or interrupted.
  • Each sprint is time bound, usually 2 weeks depending on the team and project.
  • Everyday, there should be a daily scrum meeting where every team member has to answer three questions, what was done yesterday, what will be done today and lastly, were there any roadblocks to accomplish yesterday’s task.
  • Burn-down charts are used to measure the progress of the sprint.
  • At the end of each sprint, a demo is given to the stakeholders by the team.

Kanban is comparatively much flexible and it has two rules only making it open.

  • Workflow is has to be visualized before work is started.
  • Work in progress is limited to a number of tasks.


Real Life Agile

10 Mar


Hi IS World

Hope you’re all not devastated at the thought of our blog assignment closing date; it’s ok though I have a few more blog posts planned before then so we can enjoy each other’s knowledge of I.S until then.

As I have been running on the theme of success factors in IS for my last two blogs (well worth a read cause they’re epic!) I’ve decided to set out some real life examples of how these factors can lead to a success in Agile Software Development.

I have to confess that this weeks blog wasn’t devine inspiration and so I highly recommend looking up the link the blog that inspired me at the end of this amazing blog post.

An example of a company that has adopted an agile software development project successfully would be British Airways. British Airways adopted agile software development methods to enhance they’re R&D into new revenue streams in 2008. They achieve this by implementing Agile Software  for business staff, the airline was able to  with enhance this speed to which  revenue streams can be appraised, costed and initiated.While BA initally had some problems and issues with intergrating Agile Software Development into their project they soon had started to expand its use once programmers understood the methods and the benefits.

Well I’m afraid that’s all this time, please don’t cry I’ll be back soon with another  blog before you know it. I think my next blog will be another example of Agile Software development in companies because I feel that this will be extremely benefitcial for an overall knowledge of everything Agile. So until next time

Good Bye IS World


The Capability Maturity Model

10 Mar

The Capability Maturity Model (or CMM) was, in the beginning, designed as a tool to objectively assess an organisation’s ability to carry out a software development project. It was originally meant to assist the US government in choosing which firm to contract to produce a particular piece of software by providing an empirical comparison between competitors. So how does this apply to Agile Software Development? Paulk (2001) says that CMM “describes good management practices and prescribes improvement priorities for software organizations [and] mainly focuses on large projects and large organizations”. As I discussed in my previous blog post, Agile development tends not to be as effective in large organisations.

The five levels of maturity that classify organisations in the CMM are the initial, repeatable, defined, managed, and optimised stages. The higher the organisation is on the chain, the better the chances of them producing software that is “consistent, predictable, and reliable”. CMM is built on several aspects which guide  the development team throughout the development process. These are as follows:

  • Key Practices: These refer to the elements of production and worker practice that maximise the efficiency of the development team.
  • Key Process Areas: These refer to a cluster of activities that lead to the accomplishment of a goal. These could be the actions of several members of a team (activities) which lead to the solving of an unexpected problem (goal).
  • Common Features: These are practices that implement and institutionalize a key process area. They can be anything that highlights a problem, or a way of communicating between various branches of the overall development team.
  • Goals: These are the various milestones the development team must reach in order to complete the project as a whole.

You may have noticed a somewhat glaring contradiction by now. How can a development process which values organisation and documentation synergise with Agile software development? In my last blog post I outlined that the main reason why Agile was not very effective when used by large organisations. The incorporation of the Capability Maturity Model would provide a structure from which Agile teams could operate as efficiently as they could in a smaller group by facilitating the division of the team as a whole into smaller sub-teams which will deal with key process areas individually. The managers within the organisation would serve as the go-between for the sub-teams. This allows for both the efficiency of large organisations as well as the agility of small teams to work together to accomplish complex and comprehensive software development projects.


  • Paulk, M. C., “Extreme Programming from a CMM Perspective,” IEEE Software, vol. 18, no. 6, pp. 19-26, 2001.

Spiral: Competition for Agile!

10 Mar

In this blog, I will take a look at the Spiral model which is a traditional method of software development. I will explain the basis of and the processes used by the Spiral model as well as comparing it to Agile.

The Spiral model was developed in the 1980’s and is one of the traditional methods of software development. The Spiral model is usually associated with large firms who are undertaking complex projects and new technology can often be required. Because of these factors, the Spiral model is expensive to run and often ends in failure as some of the projects undertaken became so complex. Here is a link to a blog which I found which gives a great insight into the Spiral model and how it works.

I will now outline the four stages involved in the Spiral model:

  1. Planning: This stage of the development process involves identifying the different objectives that need to be achieved by the end of the project, the different methods that could be used to implement various aspects of the project. Any future problems are also identified at this stage.
  2. Risk Analysis: This is where the risk of every possible option that could be used during the course of the project is assessed and evaluated. This is a vital stage of the project because if the wrong options are chosen here then the whole project could end in failure further down the line and this has happened to many firms in the past.
  3. Engineering: This is the stage where the product is developed to meet the design specifications and the software specifications. It will then be  rechecked to ensure it is functioning properly.
  4. Evaluation: The next phase will be planned at this stage whether it be an integration plan or whatever the case may be.


Furthermore, the Spiral model has some attractive advantages such as the high amount of risk analysis that is involved, the development of software early on in the project and the fact that it is best suited to large scale organisations. But there are some drawbacks to it as well such as the high costs involved in using it, the risk analysis requires highly skilled experts to conduct it and the success of the project largely depends on the risk analysis phase.

In summary, the spiral model is best suited to large organisations who can spend large amounts of money and are prepared to take a risk.

%d bloggers like this: