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,
why,
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:
http://en.wikipedia.org/wiki/TRIZ
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.
Eternal Sunshine of the IS Mind 
You must be logged in to post a comment.