IT Recruiter Training Understanding Software Development Methodologies

In my previous six posts of this software development lifecycle miniseries, I explained that the SDLC is a framework that engineering teams follow to produce high-quality software in a systematic and cost-effective way.  I went on to explain that adopting the SDLC provides a framework for software engineering teams to work together more efficiently and formalize communication. Without following a structured framework, the risk of producing a subpar application increases as project teams can suffer from customers’ ever-changing requests (amongst many other factors), resulting in wasted time, money, and effort.

As with my prior posts, my goal with this blog is to enhance recruiter knowledge including their candidate interviewing capabilities as well as sales knowledge so that IT staffing professionals may share and speak a common language with their candidates (IT professionals) and customers (IT hiring managers) and  provide an engaging experience for the candidates and customers they serve.

Throughout the years, various project management methodologies have been introduced to more effectively manage software development projects. Today, most companies agree that employing a methodology is crucial for project success. However, how does one know methodology which is best? 

Each methodology has its pros and cons. Adopting the best methodology depends on the team structure, project requirements, and the goals and objectives of the project. Keep in mind, it’s also possible to use different methodologies for different projects. 

This blog post gives IT recruiters and IT staffing sales reps an overview of the two most common methodologies for managing software development projects, Waterfall and Iterative including Agile.

My intention and goal with this blog post is to enhance the technical and business acumen of IT recruiters and IT staffing sales professionals and enable them to create a more engaging customer and candidate experience by sharing and speaking a common language.

Waterfall Methodology

Waterfall is the most traditional and sequential software development methodology. Although it’s now viewed as an ”old school” or outdated methodology, it’s helpful to understand the structure and history of Waterfall to better appreciate the flexibility of more modern methodologies. 

Waterfall follows a linear design approach where progress flows downwards in one direction, like a waterfall. A project is delivered through a set of ordered stages. All activity within the current stage must be completed and approved before advancing to the next stage.

While specific steps in Waterfall have different names across different sources, all of them have a similar underlying logic and series of steps. The first stage is vital, where both developers and customers must reach a full understanding of the project’s demands and scope before anything begins. From there, the stages are rigid and follow this sequence:  Requirements Gathering and Documentation, System Design, Implementation, Testing, Deployment, Maintenance and Support.

Waterfall makes the assumption that all requirements can be gathered up front during the requirements gathering and documentation phase. Communication with the customer or end user is front-loaded into this phase, as the Project Manager does their best to get a detailed understanding of the user's requirements. 

Waterfall leaves almost no room for unexpected changes or revisions. If a team has reached the end of a project, but then discovers a roadblock that necessitates a change, pivoting is difficult and expensive. A sudden change to the parameters of the project could render much of the completed work useless, which can throw off the entire project timeline and budget. 

The Waterfall methodology originated out of the manufacturing and construction industries, to which you can attribute its stringent process. Building a physical structure such as a house, building, or interstate highway is highly predictable. You design it once and build it. But imagine trying to change the design of a house after building the frame or installing the roof. Making changes would result in delays in the project and high costs. 

Waterfall was highly popular during the early days of programming due to the high certainty in project scope. However, the rigidity of its structure contributes to a high failure rate due to changing business requirements and miscommunications between the customer and engineers. 

For software development teams, the major drawback to Waterfall methodology is lack of flexibility. What is decided by the customer and the project team at the beginning must be seen through to the end. Any changes that need to be made during the middle and later stages require starting over from the beginning. 

Advantages of Waterfall Methodology

One of the advantages of Waterfall is that it has a fixed timeline and budget. This is because the project goals are specific and delineated from the start. Once the goal of the project is established, the Waterfall methodology does not involve frequent feedback or collaboration from the client, apart from established milestones or deliverables for each phase. This makes it easier for project managers to plan and communicate with stakeholders or business partners. However, while this can help with planning, it is also only practical when a client has a clear and fixed end goal and does not need to be involved in the process of the project’s development.

Because Waterfall relies on teams following a sequence of steps and never moving forward until the previous phase has been completed, this methodology is well suited for smaller projects with deliverables that are easy to define from the start.

Disadvantages of Waterfall

Making Changes is Difficult
Waterfall is based entirely on following a set of linear steps that focuses on keeping project teams moving forward. The methodology, in its traditional form, leaves almost no room for unexpected changes or revisions. For example, challenges in the implementation phase could indicate a poor design. But with Waterfall, you might not ever figure that out until you go to test or implement the software, at which point making changes would be difficult, timely and costly.  

Excludes the Customer/End Users
The main purpose of Waterfall has always been to support internal project teams to manage projects more efficiently. Waterfall is not well suited for customers or end users who want to be involved in the project, share their opinions or clarify what they want as the project moves forward.

Delays Testing Until After Development
Saving the testing phase until the last half of a project is risky, but Waterfall insists that teams wait until step four out of six to test their products. At this point, considerable time has been spent on the project, so large revisions (from testing) could cause significant delays.

Iterative 

Iterative development is a type of software development process that makes progress through successive refinement. Each refinement is called a product iteration. The customer gives feedback on the software after each iteration, which improves the product as more functionality is built in. With iterative development, the initial implementation of a product is simple and may have limited features. The following iterations progressively gain complexity and a broader feature set until the final system is complete. The purpose of working iteratively is to allow for more flexibility to address changes. 

Advantages of Iterative Development

• Iterative software development means building the product step by step. This allows for defect identification and correction during the early stages, to prevent their downward flow into further processes and later stages
• At the end of each stage or sprint, engineers get user feedback. User feedback could include how users see the product now and what they are expecting it to look like in the future. This allows project teams to make any necessary improvements and amendments.
• Iterative development saves time on documentation. The project team is able to focus more on designing the product

The Dawning of Agile 

During the 1990s, software development teams were finding that highly-structured methodologies, like Waterfall, weren’t cutting it when it came to the way they needed to work. Waterfall’s lack of flexibility, adaptability, and even autonomy, made it more difficult for engineers to respond to changes or incorporate their learning as they worked. Since project plans were outlined at the beginning, there was no room for deviation and change orders were costly. Many software development projects were failing or taking far too long to complete. Industry leaders realized they needed to find a new, innovative approach. 

Unlike an assembly line, where the manufacturing process is consistent, change is a fundamental component of software development projects. Changing customer requirements and test results often reveal that the application doesn’t perform according to the original design specification. Instead of being held captive by the requirements defined at the beginning, agile allows teams to take those changes into consideration. This helps teams make the best possible product. To do this, they need shorter development cycles, a more iterative process, and continuous feedback and testing.

In 2001, several representatives convened to find an alternative to traditional methodologies. The Manifesto for Agile Software Development was created and signed by representatives from other Agile approaches, including Extreme Programming, Scrum, DSDM, Adaptive Software Development, Crystal, feature-driven development, and pragmatic programming. 

These representatives, called the Agile Alliance, formed the beginning of today’s agile methodologies. At first, agile was primarily for managing software development projects. However, it has evolved to handle project management across all industries, organizations, and markets.

What is Agile?

In recent years, agile has been and continues to be the most popular software development methodology. With agile, tasks are broken into short sprints that take about 1 to 4 weeks to complete. It’s an iterative model that involves multiple tests throughout development. Developers continuously seek feedback from customers and make changes to the software. 

Agile is an iterative approach to project management and software development. Agile helps teams deliver value to their customers faster and with fewer headaches. Instead of betting everything on a "big bang" launch, an agile team delivers work in small consumable increments. Requirements, plans, and results are evaluated continuously so teams have a natural mechanism for responding to change quickly. Agile focuses on continuous product releases and incorporates customer feedback with every iteration.

Unlike Waterfall, agile recognizes the volatility of software development. It provides a methodology for teams to respond to change without going off the rails. Agile ensures feedback can be acted on quickly and that responsive changes can be made at each stage of a sprint or product cycle. This allows project teams to quickly adapt to change, and work collaboratively within the timeframe and budget of a project.

But agile is far more than just a methodology. Agile is a set of guiding principles for developing software. According to the Agile Manifesto, Agile values: 

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over sticking to the plan

With the traditional waterfall approach, only one discipline contributes to the project at a time and when that team’s work is complete it is "thrown over the wall" for the next team to contribute. Agile enables collaborative cross-functional teams. Open communication, collaboration, adaptation, and trust amongst team members are at the heart of agile. Although the project lead or product owner typically prioritizes the work to be delivered, the team takes the lead on deciding how the work will get done. 

Software teams that embrace agile increase their development speed, expand collaboration, and can better respond to market trends. With agile, communication between developers, customers, and end users is the priority. Agile focuses on how to satisfy the users instead of emphasizing documentation and rigid procedures.

Conceptually, agile is fairly simple to understand. But implementing Agile and getting teams to adopt Agile is difficult. This is because Agile is a set of values and principles. Agile is more about how you think and less about how you work. For these reasons, implementing Agile, and gaining adoption, typically requires significant organizational change. Teams can’t just decide to go Agile overnight because it takes a lot more to change the way you think than it does to change the way you work.

In my final installment of this blog miniseries I will discuss Agile frameworks Scrum, Kanban and Extreme Programming (XP)

To further hone your candidate qualification skills, check out our eBook, Executing the Candidate Interview, Five Pillars to Effective Candidate Qualification.