To use methodologies or not? What does your intuition tell you?
It is a set of techniques and tools that can be used to solve a problem. It provides structure, guidance and understanding in the method used. ‘Method’ being the operative word, you’ve guessed right – I’m going to demonstrate how methodism can be a hurdle in software projects, but if used properly, methodologies could also bring positive benefits to projects.
So what exactly is a methodology? “Methodology is seen as the inflexible and stifling way of solving problems. It appears as being very structured and generally people want to shy away from it. The observations are perceived to be true, however stifling methodism has its benefits. Methodology can provide safety, predictability and a calculated outcome which discourages creativity,” (Introna and Whitley, 1997).
Lucas D Introna and Dr Edgar A Whitley (1997) elucidate methodology as a necessity that is sufficient for information systems’ development success. This is the belief that everything that is required to analyse and specify a problem situation, and all that is required to design a solution, can be found in a suitably designed methodology.
According to Introna and Whitley (1997) there is an alternative school of thought against methodism. Some system developers tend to use parts of methodologies (often, parts taken from a variety of different methodologies) rather than following all the steps required by a particular method (1997:31).
Firstly, developing an understanding instead of focusing on the tools used is the basis for this school of thought. They suggest that “the successful use of methodology itself depends on a broader, already present, tacit understanding of the world, an understanding not to be found in any one particular methodology” (Introna and Whitley, 1997:31).
Secondly, this school of thought suggests that a system developer should investigate the problem first in order to choose the appropriate methodology or the relevant parts of a particular methodology. Consequently, this leads to using the most effective tools, as opposed to using all the available tools that may delay a process.
Lastly, this school of thought raises an awareness of the limitations of methodism so that a system developer is able to know when to break the rules. Therefore, Introna and Whitley (1997) pose this open-ended question: is there any point to developing complete methodologies if people tend to pick and choose parts of methodologies and discard others?
Methods vs intuition
As a business analyst who has been in the industry for several years, I have been observing and I’ve also been involved in a variety of projects. Some of the projects I had observed and worked on have failed or run over time due to following methods. I am in no way advocating that the use of methodologies is bad for projects. The point I am trying to make is that it provides a narrow way to deliver on a software project. It also does not accommodate any unexpected state of affairs as a step-by-step approach is used.
More often than not, projects frequently have unforeseen circumstances and sticking to methods may lead to project delays which result in project failures. Again, based on my observations, most of these failures occur because methods were followed instead of intuition and drive for progress. Some of software development methodologies include, but are not limited to Waterfall, Agile, Joint Application Development (JAD) etc.
The agile methodology is frequently praised for its flexibility, quick feedback, efficient communication, and frequent showcases; however, it is not the best methodology for every project.
This methodology puts emphasis on person to person communication instead of written emails and documents. It also requires all resources to be under one roof (Dyba and Dingsoyr 2008). These resources must include business analysts, developers etc.
There exist several disadvantages to this model:
While frequent communication and involvement amongst team members can have a huge positive impact on the development, there is a potential problem here, as some team members won’t be able to participate so actively in the development because they might not be able to attend all daily stand ups as per agile manifesto.
Agile prioritizes working code over documentation, and while that may be a positive thing, some projects just end up lacking proper documentation. This is a BIG issue because there’s barely any documentation when it comes a time to handover a solution developed using the agile methodology. Agile doesn’t encourage transfer of knowledge as user stories are written in a way that’s not simple to understand, it is purely for technical people and cannot be easily understood by anyone should the author of the user stories get hit by the bus, furthermore it is not properly structured as user stories are written for each system function and these are also stored in different locations on the agile documenting platforms.
When methodologies fail
Other methodologies require documentation to be completed before the development starts. Although this is a positive thing as it provides a clear structure, the issue here is a language barrier, which makes documenting really challenging. The business and functional requirements use English only. The English language requires a business analyst to use certain language rules such as grammar, punctuation, syntax, style etc. Most people articulate themselves better in their mother tongue. The reality is that most underprivileged individuals in the South Africa context have never had the prospect of studying English as a first language. The expectation from the workplace then becomes very unfair given that two people coming from two different backgrounds are measured on the same key performance indications.
Furthermore, it has been evident in my observations that the time taken to document all requirements tends to be longer as most of these documents go under scrutiny to identify the smallest of mistakes, which in most cases do not hinder the project initiation. While most of these documents provide some relevant information, it creates unnecessary delays at the same time.
Politics of conformance
We are living in world where everyone is expected to follow a set method. Those who defy methods are labelled as rebellious and thus frowned upon by society. Conformance has resulted in many people and organisations not achieving their set objectives as they apply the method used by the next person/organisation in their own lives and circumstances.
Instead of an institution or individual applying concepts that have been used before, a thorough SWOT (Strengths, Weaknesses, Opportunities, Threats) analysis needs to be conducted (Humphrey, Albert, 2005).
Methodologies that are developed often do not have situation specific information to provide the best procedures and methodologies in that given situation. In this instance the company or individual needs to analyse the strengths and weaknesses within the individual or company.
In the case of a company, it would need to be aware of what competitive edge it has over other companies This knowledge must be incorporated in the decisions that the company makes regarding the projects that it decides to undertake and the methods followed thereof. Knowledge of strengths can also help the company with the staffing requirements, capacity planning and project implementation.
The company also needs to be aware of its weaknesses to ensure that the necessary precautions are taken when undertaking projects that may be in an area of weakness, in which case it may be necessary to outsource staffing for that specific function.
On an external environment perspective, the company needs to be aware of the trends in their specific industries and take advantage of opportunities that present themselves to the company at different periods. This knowledge may lead to the birth of projects that may enhance the company’s market share and possibly increase profits.
The company also needs to be aware of competition through projects and initiatives conducted by other companies. This will ensure that the company stays on track with client expectations and that its operations are not threatened.
A holistic assessment of these factors will ensure that methodologies applied during projects are not done blindly.
Best of both?
While methodism is not ideal in most cases because it limits creativity and does not accommodate unexpected issues that arise on software development projects, it is not all bad. In order for it to work, a SWOT analysis has to be done before selecting a method to ensure that the method achieves project objectives, provides safety, predictability and a calculated outcome creativity. Ever mindful of the ability to accommodating the unforeseen situations that happens in software projects.
Introna, L. D and Whitley, E. A (1997), Against Method-ism: Exploring the Limits of Method Information Technology and People, 10 (1), 31-45.
Humphrey, Albert (December 2005). “SWOT Analysis for Management Consulting” (PDF). SRI Alumni Newsletter (SRI International).
Lucas D. Introna and Edgar A. Whitley (August 1997) ”Against method-ism”- Exploring the limits of method”
Tore Dyba and Torgeir Dingsoyr (January 2008)” Empirical studies of Agile software development” A systematic review”
by Hanyani Makumbani