The most popular methodologies used world over for software development are Waterfall (the traditional approach) and Agile (which is often implemented using Scrum). The Waterfall methodology is thought to be fraught with problems and likely to run projects into chronic delays.
Its use is giving way to Agile methodology, which addresses the conceptual and implementation problems with Waterfall — and is considered superior among the growing number of companies, like Schneider Electric, that are adopting it.
The Waterfall methodology was designed with two objectives: to ensure clear accountability in the relationship between supplier (who is developing the software) and the customer (who will use it), and to ensure the process is highly stable, and that rework is minimal.
For the first need, freezing requirements before starting the project is an absolute must. Once requirements are frozen, the accountability for any effort or time overrun can be clearly traced back to either of the stakeholders.
The second need requires one to approach software development like one would development of a new physical product. Developing a new physical product requires the design to be complete before start of the actual building — allowing design to remain fluid during implementation can lead to uncontrolled rework and interruptions.
Strict processes are usually put in place as a “deterrent” against any rethink late in the process. However, when customer-testing is undertaken at the end of the entire project, “hindsight” clarity creates severe conflicts between customer and developer on what was “told” initially in the requirement phase and what was “understood”.
Practically speaking, late-scope redefinition is difficult to prevent, more so when the relationship between customer and supplier is not of equals. The result is massive rework, leading to uncontrolled delays. In this environment, therefore, contractual conflicts, delays, effort spiking and associated stress towards the end are quite common.
In sharp contrast, Agile takes a viewpoint that scope and design cannot be frozen upfront.
According to Schneider, it adopts a flexible working approach, which can embrace change much later in the development cycle. Instead of taking a “one perfect project delivery” viewpoint of software development, Agile believes in the principles of delivering usable features, good enough for customers to start using, and then keep improving based on frequent feedback.
The idea is to deliver workable software as soon as possible and get feedback for further iterative development. This way of working also takes away the need to freeze requirements and design upfront.
In the Agile world, one can move away from sequential working between phases of software development. The team can work as a self-organizing group, which can design, develop, test and deliver workable features in an iterative manner. Time is often managed by using the concept of sprints (widely used in the version of Agile called Scrum) — a “time box” of 15/30 days, is used to deliver small batches of usable software features. While the ongoing sprint is frozen, subsequent ones can be changed based on customer feedback.
When the Agile methodology evolved, many believed that the “silver bullet” had been found. However, there is little scientific support for many of the claims made by the Agile community.
Recent news has highlighted the increasing stress on developers, the ever-lengthening backlog of bugs and customer dissatisfaction with the usability of software. As a counter argument, proponents of the methodology have pointed out that implementation gaps, not conceptual gaps, are the primary reason for these woes. In order to validate these arguments, it is important to define the boundary conditions or assumptions of the theory and check if these are violated in a majority of cases.
The resultant effect of any Agile intervention is a re-organization of an erstwhile functional structure of design, development and testing into many small self-organizing teams, which are expected to be self-sufficient in all these tasks.
This assumption of self-sufficiency of small divided teams in terms of adequacy of high-end skills, particularly designing and requirement assessment, is highly questionable in most companies. High attrition rates, with many developers changing jobs every two to three years are hard realities of the industry, which is obsessed with outsourcing and reducing cost of development. The high attrition rate does not impact availability of generic skill resources like expertise of a programming language. But environment-specific skills like design and requirement analysis, which is only acquired with adequate experience, are scarce.
So it is highly likely, with skills decentralization after an Agile intervention that many Agile teams will fall short on skills, even though each team may have the required numbers to be declared “self-sufficient” as per records.
Two critical conditions can be used to resolve the inherent conflict of the software development process.
1. Minimizing flow backs. Organizing resource groups into requirements assessment team, design team, development and testing groups helps create the required division of labor for assembly line working. This allows the limited expert resources to be centralized in the requirements and the design groups. This grouping also helps in proper utilization of their capacity in type of work, which requires their expertise.
However, without clear definition of what constitutes end of requirement and end of design, the assembly line type sequential working between resource groups will never materialize due to flow backs. It is also important to put up a process check completions — this is imperative to break the bad habit of proceeding without completing the phases.
2. Minimizing the transfer batch. Just having an assembly line with delivery coming out after a period of six months or a year is also undesirable. When different customers require different features at different points of time, having one delivery date for a large set of features is of no use to anyone. It is unreasonable to expect the customer to wait till all other features are complete.
Moving individual features through the assembly line in order of priority ensures better flow — and early delivery of workable features that individual customers want.
Enjoy curated articles directly to your inbox.