Software Development Methodologies

Looking to add more structure to your software development workflow? Selecting the right software development methodology for your product organization depends largely on your team size, goals, and other factors. Here is an overview of the most widely utilized and recognized software development methodologies to help you decide which is right for your team.

1. Waterfall

When it comes to software development, Waterfall is the most traditional and sequential choice. Although it’s usually viewed as an ”old school” or outdated method, it’s helpful to understand the history and structure of Waterfall to better appreciate the flexibility of more modern methodologies. First created in 1970, Waterfall was one of the most prominent methodologies for several decades because of its plan-driven approach.

Waterfall requires plenty of structure and documentation up front. It is divided into self-contained stages or steps. The first stage is vital, requiring a full understanding by both developers and customers of the project’s demands and scope before anything begins. The stages are relatively rigid and often follow this sequence: determine the project’s requirements and scope, analyze those requirements, design, implement, test, deploy and finally, maintain.

There’s a lack of flexibility with this approach, meaning what is decided by the customer and developer at the beginning must be seen through. Should any changes need to be made or mistakes addressed toward the end stages, the Waterfall method generally requires a full restart.

Typically, one stage must be finished before the next can begin, which can help with organization and assignments. And because the full scope of the project is understood in advance, software progress can easily be measured. Waterfall is often utilized by large, plan-driven teams who have a very clear understanding of the project’s scope;—however, development teams who don’t operate in a vacuum will likely find better results with the flexibility and agility of more modern methodologies.

2. Feature-Driven Development

Why should you use a feature-driven development?

Have you ever met the term FDD and asked yourself what is FDD?

FDD meaning

FDD or feature-driven development is an Agile framework - a certain process that offers businesses feature-rich systems that support them in controlling their ever-growing nature. Even from its name, we may immediately guess that this framework organizes software development around making progress on features. As we know, the future mainly depends on customers and architecture, so these are essential points in this FDD process.

FDD in Agile

FDD is a model-driven, and short-iteration process that was developed around software engineering best practices including domain object modeling, developing by feature, and code ownership.

Feature-driven development begins with the establishment of an overall model that is expected to result in the feature list. These features are usually small yet useful and effective on the users’ eyes. Due to this tactic of product development, large teams are allowed to move products forward with a regular success that matters for the clients.

The general objective of FDD is to deliver concrete and flexible software in a short time. Its greatest advantage is that the process is scalable even for large teams. As a result, FDD is considered to be an effective solution to support the control of comparatively complex Agile projects.

Feature Driven Development Methodology

It is accepted to implement the FDD in several steps that form the feature-driven development methodology. I’m going to introduce these steps below.

Step №1. Developing an Overall Model

In the first stage, the development team members cooperate together to build an object model of the domain problem. The main goal is to propose a model for the domain area. The Chief Architect follows them and provides guidance. Once the teams proposed their own models, one of these models or a merge of models is chosen and it becomes the model created for that domain area. As a result, the team has a clear image of the entire project.

Step №2. Building a Feature List

After the development team built an object model, then it is time to identify the features that the user or client values. These features are meant to be the building barriers of the project that help the group members to navigate the processes.

Step №3. Planning by the Feature

The third stage turns around managing the features and the way the development team tends to implement them. As anticipated, it’s essential to consider the team workload, risks, as well as other important aspects in order to prevent any kind of complex issues from arising.

Step №4. Designing by the Feature

Everything planned pretends design. Using the knowledge from the first modeling process, the chief programmer selects all the features that the team should develop next and also identifies the domain classes. After the team starts working on the project, the domain expert analyzes and designs a solution to each feature.

Step №5. Building by the Feature

The last step is to put all the necessary items into action in order to support the design. In other words, once your team developed, tested and inspected the code, it is time to start developing the software.

Advantages of FDD

With the constant growth of the software system, software development becomes a more complex process that requires much. In such a sequence, your team will have to find the most efficient way to grab the issues they come across. Here FDD is the method that lets your team successfully run the project due to its advantages that we’ll together discuss below:

№1. Communication Improvement

Product development requires constant communication especially when large teams are considered. FDD provides the team members with an opportunity to communicate more easily, on the other hand, encouraging team creativity and innovation.

№2. Minimal Complexity of the System

The bigger the software system size is, the more complex the system faces. Complexity is one of the most repeated obstacles every software developer has to overcome as it quickly surpasses the capacity of the human brain.

FDD provides the development team with the ability to break the entire problem into many smaller issues that they can cope with within a smaller period of time. On the other hand, smaller problems minimize the needs of communication within the group as well as improve the communication flow.

№3. Maximum Quality

Every member of the team identifies quality in a unique way. An average user recognizes the quality taking into consideration the interface, reliability and response time. However, from the developers’ perspective, talking about the quality they consider the facility of software maintenance and enhancement. Yet, the ever-increasing requirements of the market prevent us from expressing the challenges in advance, and as a result, we have to struggle with and produce positive results of changes.

Nowadays the Feature Driven Development is gaining popularity in the IT world because:

✔ it is an excellent solution both for big and complex projects especially while dealing with critical situations

✔ the above-mentioned 5 processes help the new team members become familiar with the system in a short period of time

✔ Constant progress reporting which takes place at nearly any level of the project development, lets your team keep the path of success and track results

✔ FDD offers an opportunity for you to regularly keep your project up-to-date, observe any error, and provide your users/clients with valuable information at any time

✔ A deeper understanding of the software system lets you develop small parts one at a time. This decreases the risk and provides your safety from any unpleasant surprise.

3. Agile

The Agile methodology was developed as a response to growing frustrations with Waterfall and other highly structured, inflexible methodologies. This approach is designed to accommodate change and the need to produce software faster.

Organizations strive for agility so they can be more resilient against uncertainty. Companies believe that if they have agile teams, they have a greater chance of success in today’s dynamic and demanding business landscape. If development teams are able to deliver projects and build products effectively using Agile software development, then being agile must be the formula to success. But what exactly is it?

Agile Values & Principles

Agile development methodology is a different way of managing software development projects. This approach follows Agile principles that differ from the more traditional Waterfall approach. What’s wrong with Waterfall? There came a time when developers need a better way to develop software that addresses both the customer’s and the developer’s requirements. The Waterfall methodology is not flexible enough to be a solution.

So, a group of software developers agreed to craft a manifesto that values individuals and interactions, working software, and customer collaboration, and responds to change more than the values highly prioritized in Waterfall, which are processes and tools, documentation, contract negotiation, and plans. From these Agile values, they stated the following principles:

Customer satisfaction is the highest priority.
Changing of requirements is welcome at any development stage.
Deliver working software frequently at shorter timescales.
Business users and developers should collaborate daily throughout the project.
Trust and support motivated individuals to find solutions.
Face-to-face conversation is the best method of conveying information.
A working software is the primary measure of progress.
Agile processes promote a sustainable environment.
Continuous attention to technical excellence and good design enhances agility.
Simplicity is essential.
The best architectures, requirements, and designs emerge from self-organizing teams.
The team regularly reflects on how to become more effective and adjusts accordingly.

Examples of Methodologies & Standards in Software Development

Software development projects follow methodologies and standards to ensure that teams deliver them on time, within budget, within scope, and with an acceptable quality. Methodologies guide developers to actually build the product they planned to build in the most efficient way. There are several methodologies and standards that address the various aspects of software development. For instance, there is PRINCE2 for project management, Use Cases/UML for analysis and design, and ISEB for testing. Agile software development is flexible and can apply elements of these same methods in its various development stages.

We have listed the top 3 agile project management software available on the market right now. As Agile software development is one of the most popular and in-demand methodologies these days, this list will be very helpful to learn, decide, and manage projects using the Agile software development methodology.

Agile Development Methodology

Attempts to find an alternative to the Waterfall methodology predates the Agile Manifesto. But the Agile principles strengthened a growing movement that further supported and reinforced several iterative development methodologies now classified as Agile.

Dynamic Systems Development Method (DSDM) is close to the original method that reflects Agile development principles. DSDM was around before the term Agile development was invented, but it’s based on all the Agile principles we have come to know as Agile software development.
Scrum is also an Agile development method, which concentrates particularly on how to manage tasks within a team-based development environment.
Extreme Programming (XP) is a more radical Agile methodology that focuses on the software development process. It addresses the analysis, development, and test phases with novel approaches aimed at making a substantial difference to the quality of the end product.
DSDM is almost synonymous to Agile methodology, whereas Scrum and XP are easier to implement and complementary because they tackle different aspects of development projects. Both Scrum and XP conform to the same principles of Agile development.

Choosing A Methodology

In reality, there is no magic bullet for software development. The real trick is to know multiple techniques from various Waterfall and Agile development methods and to select a mixture of the best approaches that are most appropriate for any given situation. To do this reliably with any degree of success requires solid experience and skill.

In Agile software development, project management takes a slightly different form. It relies more on the project manager’s skills in communication, facilitation, and coordination, with less emphasis on planning and control.

Agile software development can be a very exciting and invigorating approach. Agile project management principles will show that some projects suit Agile development more than others. Collaboration and visibility, which are key principles of Agile methodology, can provide a richer and more rewarding experience for teams to develop great software products. The less flexible Waterfall approach puts greater focus on documentation. Creating software using Agile development methodology can be more enjoyable than the staid Waterfall approach. And when people enjoy their work, it is amazing what they can achieve.

4. Scrum

Another way to implement the Agile approach, Scrum borrows from Agile’s foundational beliefs and philosophy that teams and developers should collaborate heavily and daily.

With Scrum, software is developed using an iterative approach in which the team is front and center—experienced and disciplined workers on smaller teams might find the most success with this method, as it requires self-organization and self-management.

What is Scrum?
A brief History on Scrum Jeff-Sutherland In 1993, Jeff Sutherland and his team at Easel Corporation created the Scrum process to be used in software development processes by combining the concepts of the 1986 article with the concepts of object-oriented development, empirical process control, iterative development and incremental, software processes and productivity improvement, as well as the development of complex and dynamic systems.

“Doing half of something is, essentially, doing nothing.” – Jeff Sutherland
Scrum Methodology & Process
Different Roles in Scrum“It is the Scrum Master’s job to guide the team toward continuous improvement – to ask with regularity, “How can we do what we do better?” – Jeff SutherlandCLICK TO TWEETBenefits of Scrum Methodology
Events in Scrum“The goal of retrospectives is help teams to continuously improve their way of working.” – Ben LindersCLICK TO TWEETScrum Artifacts
Planning in Scrum

Scrum is an agile development methodology used in the development of Software based on an iterative and incremental processes. Scrum is adaptable, fast, flexible and effective agile framework that is designed to deliver value to the customer throughout the development of the project. The primary objective of Scrum is to satisfy the customer’s need through an environment of transparency in communication, collective responsibility and continuous progress. The development starts from a general idea of what needs to be built, elaborating a list of characteristics ordered by priority (product backlog) that the owner of the product wants to obtain.

The history of Scrum can be traced back to 1986 in the Harvard Business Review (HBR) article titled, “The New Product Development Game” by Hirotaka Takeuchi & Ikujiro Nonaka. This article describes how companies such as Honda, Canon, and Fuji-Xerox produce new products worldwide using a scalable and team-based approach to product development. This approach emphasizes the importance of empowering self-organized teams.

The article was an influence to develop many of the concepts that gave birth to what we now call Scrum. Scrum is a term drawn from Rugby, which refers to how the game is restarted after a foul or when the ball has left the game.

Scrum is precisely an evolution of Agile Management. Scrum methodology is based on a set of very defined practices and roles that must be involved during the software development process. It is a flexible methodology that rewards the application of the 12 agile principles in a context agreed by all the team members of the product.

Scrum is executed in temporary blocks that are short and periodic, called Sprints, which usually range from 2 to 4 weeks, which is the term for feedback and reflection. Each Sprint is an entity in itself, that is, it provides a complete result, a variation of the final product that must be able to be delivered to the client with the least possible effort when requested.

The process has as a starting point, a list of objectives/ requirements that make up the project plan. It is the client of the project that prioritizes these objectives considering a balance of the value and the cost thereof, that is how the iterations and consequent deliveries are determined.

On the one hand the market demands quality, fast delivery at lower costs, for which a company must be very agile and flexible in the development of products, to achieve short development cycles that can meet the demand of customers without undermining the quality of the result. It is a very easy methodology to implement and very popular for the quick results it gets.

Scrum methodology is used mainly for software development, but other sectors are also taking advantage of its benefits by implementing this methodology in their organizational models such as sales, marketing, & HR teams etc.

In Scrum, the team focuses on building quality software. The owner of a Scrum project focuses on defining what are the characteristics that the product must have to build (what to build, what not and in what order) and to overcome any obstacle that could hinder the task of the development team.

The Scrum team consists of the following roles:

Scrum master: The person who leads the team guiding them to comply with the rules and processes of the methodology. Scrum master manages the reduction of impediments of the project and works with the Product Owner to maximize the ROI. The Scrum Master is in charge of keeping Scrum up to date, providing coaching, mentoring and training to the teams in case it needs it.

Product owner (PO): Is the representative of the stakeholders and customers who use the software. They focus on the business part and is responsible for the ROI of the project. They Translate the vision of the project to the team, validate the benefits in stories to be incorporated into the Product Backlog and prioritize them on a regular basis.

Team: A group of professionals with the necessary technical knowledge who develop the project jointly carrying out the stories they commit to at the start of each sprint.

Scrum has many advantages over other agile development methodologies. It is currently the most used and trusted framework of reference in the software industry. Below are some of the known benefits of Scrum:

Easily Scalable: Scrum processes are iterative and are handled within specific work periods, which makes it easier for the team to focus on definite functionalities for each period. This not only has the benefit of achieving better deliverables in line with the needs of the user, but also gives the ability to the teams to scale the modules in terms of functionality, design, scope and characteristics in an orderly, transparent and simple manner.

Compliance of expectations: The client establishes their expectations indicating the value that each requirement/ history of the project brings, the team estimates them and with this information the Product Owner establishes its priority. On a regular basis, in the sprint demos, the Product Owner verifies that the requirements have been met and transmits feedback to the team.

Flexible to changes: Quick reaction to changes in requirements generated by customer needs or market developments. The methodology is designed to adapt to the changing requirements that complex projects entail.

Time to Market reduction: The client can start using the most important functionalities of the project before the product is completely ready.

Higher software quality: The working method and the need to obtain a functional version after each iteration, helps to obtain a higher quality software.

Timely Prediction: Using this methodology, we know the average speed of the team by sprint (story points), with which, consequently, it is possible to estimate when a certain functionality that is still in the backlog will be available.

Reduction of risks: The fact of carrying out the most valuable functionalities in the first place and of knowing the speed with which the team advances in the project, allows to clear risks effectively in advance.

Each of the Scrum events facilitates the adaptation of some of the aspects of the process, the product, progress or relationships.

Sprint: Sprint is the basic unit of work for a Scrum team. This is the main feature that marks the difference between Scrum and other models for agile development.

Sprint Planning: The goal of the Sprint Planning is to define what is going to be done in the Sprint and how it is going to be done. This meeting is held at the beginning of each Sprint and is defined how it will approach the project coming from the Product Backlog stages and deadlines. Each Sprint is composed of different features.

Daily Scrum: The objective of the Daily Scrum is to evaluate the progress and trend until the end of the Sprint, synchronizing the activities and creating a plan for the next 24 hours. It is a brief meeting that takes place daily during the Sprint period. Three questions are answered individually: What did I do yesterday? What am I going to do today? What help do I need? The Scrum Master should try to solve problems or obstacles that arise.

Sprint Review: The goal of the sprint review is to show what work has been completed with regards to the product backlog for future deliveries. The finished sprint is reviewed, and there should already be a clear and tangible advancement in the product to present to the client.

Sprint Retrospective: The team reviews the completed goals of the finished sprint, write down the good and the bad, so as not to repeat the mistakes again. This stage serves to implement improvements from the point of view of the development process. The goal of the sprint retrospective is to identify possible process improvements and generate a plan to implement them in the next Sprint.

Scrum Artifacts are designed to guarantee the transparency of key information in decision making.

Product Backlog (PB): The product backlog is a list that collects everything the product needs to satisfy the potential customers. It is prepared by the product owner and the functions are prioritized according to what is more and less important for the business. The goal is for the product owner to answer the question “What should be done”.

Sprint Backlog (SB): It is a subset of items of the product backlog, which are selected by the team to perform during the sprint on which they are going to work. The team establishes the duration of each Sprint. Usually the sprint backlog, is displayed on physical boards called as Scrum board – that makes the development process visible to everyone who enters the development area.

Increment: The Increment is the sum of all the tasks, use cases, user stories, product backlogs and any element that was developed during the sprint and that will be made available to the end user in the form of Software.

The Sprint Planning Meeting is held at the beginning of each Sprint. All the members of the Team participate in the meeting, i.e., the Product Owner, Scrum Master and all the Development Team. The entire Scrum team must understand and define what objective should be obtained in that Sprint (Sprint Goal). From this point the development team must design a work plan to achieve the objective. This planning should allow you to see if the sprint goal involves a workload according to the duration stipulated for the Sprints (which is 2 to 4 weeks).

The client shows the result to be achieved in that Sprint and the requirements of the deliverable product. Here you have to carry out a discussion in which the development team evaluates what elements of the list can be delivered.

Both the Scrum Master and the Product Owner must collaborate to clarify any aspect of the requirements. Finally, the development team must explain how they will organize the team’s work to achieve the Sprint goal.

5. Extreme Programming (XP)

Extreme Programming: Values, Principles, and Practices

With software engineering existing in such a fast-paced environment, traditional project management approaches are no longer viable. That means that IT professionals must find new ways to handle frequently changing development tasks.

Sharing this idea and focusing on the existing incremental development techniques, 17 software specialists introduced the Agile project management philosophy in 2001. Principles of flexible, fast, and collaboration-centered software development were outlined in the Agile Manifesto.

Extreme Programming (XP) is one of the numerous Agile frameworks applied by IT companies. But its key feature — emphasis on technical aspects of software development — distinguishes XP from the other approaches.

Software engineer Ken Beck introduced XP in the 90s with the goal of finding ways to write high-qualitative software quickly and being able to adapt to customers’ changing requirements. In 1999, he refined XP approaches in the book Extreme Programming Explained: Embrace Change.

XP is a set of engineering practices. Developers have to go beyond their capabilities while performing these practices. That’s where the “extreme” in the framework’s title comes from. To get a better understanding of these practices, we’ll start with describing XP’s lifecycle and the roles engaged in the process.

The process and roles of extreme programming

The XP framework normally involves 5 phases or stages of the development process that iterate continuously:

Planning, the first stage, is when the customer meets the development team and presents the requirements in the form of user stories to describe the desired result. The team then estimates the stories and creates a release plan broken down into iterations needed to cover the required functionality part after part. If one or more of the stories can’t be estimated, so-called spikes can be introduced which means that further research is needed.
Designing is actually a part of the planning process, but can be set apart to emphasize its importance. It’s related to one of the main XP values that we’ll discuss below — simplicity. A good design brings logic and structure to the system and allows to avoid unnecessary complexities and redundancies.
Coding is the phase during which the actual code is created by implementing specific XP practices such as coding standards, pair programming, continuous integration, and collective code ownership (the entire list is described below).
Testing is the core of extreme programming. It is the regular activity that involves both unit tests (automated testing to determine if the developed feature works properly) and acceptance tests (customer testing to verify that the overall system is created according to the initial requirements).
Listening is all about constant communication and feedback. The customers and project managers are involved to describe the business logic and value that is expected.

Such a development process entails the cooperation between several participants, each having his or her own tasks and responsibilities. Extreme programming puts people in the center of the system, emphasizing the value and importance of such social skills as communication, cooperation, responsiveness, and feedback. So, these roles are commonly associated with XP:

Customers are expected to be heavily engaged in the development process by creating user stories, providing continuous feedback, and making all the necessary business decisions related to the project.
Programmers or developers are the team members that actually create the product. They are responsible for implementing user stories and conducting user tests (sometimes a separate Tester role is set apart). Since XP is usually associated with cross-functional teams, the skill set of such members can be different.
Trackers or managers link customers and developers. It’s not a required role and can be performed by one of the developers. These people organize the meetups, regulate discussions, and keep track of important progress KPIs.
Coaches can be included in the teams as mentors to help with understanding the XP practices. It’s usually an outside assistant or external consultant who is not involved in the development process, but has used XP before and so can help avoid mistakes.

Values and principles of extreme programming

In the late 90s, Ken Beck summarized a set of certain values and principles that describe extreme programming and lead to more effective cooperation within the team and, ultimately, higher product quality.

Values of extreme programming

XP has simple rules that are based on 5 values to guide the teamwork:

Communication. Everyone on a team works jointly at every stage of the project.
Simplicity. Developers strive to write simple code bringing more value to a product, as it saves time and effort.
Feedback. Team members deliver software frequently, get feedback about it, and improve a product according to the new requirements.
Respect. Every person assigned to a project contributes to a common goal.
Courage. Programmers objectively evaluate their own results without making excuses and are always ready to respond to changes.

These values represent a specific mindset of motivated team players who do their best on the way to achieving a common goal. XP principles derive from these values and reflect them in more concrete ways.

Principles of extreme programming

Most researchers denote 5 XP principles as:

Rapid feedback. Team members understand the given feedback and react to it right away.
Assumed simplicity. Developers need to focus on the job that is important at the moment and follow YAGNI (You Ain’t Gonna Need It) and DRY (Don’t Repeat Yourself) principles.
Incremental changes. Small changes made to a product step by step work better than big ones made at once.
Embracing change. If a client thinks a product needs to be changed, programmers should support this decision and plan how to implement new requirements.
Quality work. A team that works well, makes a valuable product and feels proud of it.

Having discussed the main values and principles of XP, let’s take a closer look at the practices inherent in this framework.

Extreme programming practices

The practices of XP are a set of specific rules and methods that distinguishes it from other methodologies. When used in conjunction, they reinforce each other, help mitigate the risks of the development process, and lead to the expected high-quality result. XP suggests using 12 practices while developing software which can be clustered into four groups.

Test-Driven Development

Is it possible to write a clear code quickly? The answer is yes, according to XP practitioners. The quality of software derives from short development cycles that, in turn, allow for receiving frequent feedback. And valuable feedback comes from good testing. XP teams practice test-driven development technique (TDD) that entails writing an automated unit test before the code itself. According to this approach, every piece of code must pass the test to be released. So, software engineers thereby focus on writing code that can accomplish the needed function. That’s the way TDD allows programmers to use immediate feedback to produce reliable software.

The Planning Game

This is a meeting that occurs at the beginning of an iteration cycle. The development team and the customer get together to discuss and approve a product’s features. At the end of the planning game, developers plan for the upcoming iteration and release, assigning tasks for each of them.

On-site Customer

As we already mentioned, according to XP, the end customer should fully participate in development. The customer should be present all the time to answer team questions, set priorities, and resolve disputes if necessary.

Pair Programming

This practice requires two programmers to work jointly on the same code. While the first developer focuses on writing, the other one reviews code, suggests improvements, and fixes mistakes along the way. Such teamwork results in high-quality software and faster knowledge sharing but takes about 15 percent more time. In this regard, it’s more reasonable trying pair programming for long-term projects.

Code Refactoring

To deliver business value with well-designed software in every short iteration, XP teams also use refactoring. The goal of this technique is to continuously improve code. Refactoring is about removing redundancy, eliminating unnecessary functions, increasing code coherency, and at the same time decoupling elements. Keep your code clean and simple, so you can easily understand and modify it when required would be the advice of any XP team member.

Continuous Integration

Developers always keep the system fully integrated. XP teams take iterative development to another level because they commit code multiple times a day, which is also called continuous delivery. XP practitioners understand the importance of communication. Programmers discuss which parts of the code can be re-used or shared. This way, they know exactly what functionality they need to develop. The policy of shared code helps eliminate integration problems. In addition, automated testing allows developers to detect and fix errors before deployment.

Small Releases

This practice suggests releasing the MVP quickly and further developing the product by making small and incremental updates. Small releases allow developers to frequently receive feedback, detect bugs early, and monitor how the product works in production. One of the methods of doing so is the continuous integration practice (CI) we mentioned before.

Simple Design

The best design for software is the simplest one that works. If any complexity is found, it should be removed. The right design should pass all tests, have no duplicate code, and contain the fewest possible methods and classes. It should also clearly reflect the programmer’s intent.

XP practitioners highlight that chances to simplify design are higher after the product has been in production for some time. Don Wells advises writing code for those features you plan to implement right away rather than writing it in advance for other future features: “The best approach is to create code only for the features you are implementing while you search for enough knowledge to reveal the simplest design. Then refactor incrementally to implement your new understanding and design.”

Coding Standards

A team must have common sets of coding practices, using the same formats and styles for code writing. Application of standards allows all team members to read, share, and refactor code with ease, track who worked on certain pieces of code, as well as make the learning faster for other programmers. Code written according to the same rules encourages collective ownership.

Collective Code Ownership

This practice declares a whole team’s responsibility for the design of a system. Each team member can review and update code. Developers that have access to code won’t get into a situation in which they don’t know the right place to add a new feature. The practice helps avoid code duplication. The implementation of collective code ownership encourages the team to cooperate more and feel free to bring new ideas.

System Metaphor

System metaphor stands for a simple design that has a set of certain qualities. First, a design and its structure must be understandable to new people. They should be able to start working on it without spending too much time examining specifications. Second, the naming of classes and methods should be coherent. Developers should aim at naming an object as if it already existed, which makes the overall system design understandable.

40-Hour Week

XP projects require developers to work fast, be efficient, and sustain the product’s quality. To adhere to these requirements, they should feel well and rested. Keeping the work-life balance prevents professionals from burnout. In XP, the optimal number of work hours must not exceed 45 hours a week. One overtime a week is possible only if there will be none the week after.

Advantages and disadvantages of XP

XP practices have been debated upon for decades, as its approach and methods are rather controversial in a number of aspects and can’t be applied in just any project. Here, we’ll try to define the pros and cons of XP methodology.

Extreme programming advantages

So, the XP framework can be beneficial and help reduce development time and costs for the following reasons:

Continuous testing and refactoring practices help create stable well-performing systems with minimal debugging;
Simplicity value implies creating a clear, concise code that is easy to read and change in the future if needed;
The minimalistic iterative approach to development ensures that the workable results can be delivered very soon and only necessary features are built;
Documentation is reduced as bulky requirements documents are substituted by user stories;
No or very little overtime is practiced;
Constant communication provides a high level of visibility and accountability and allows all team members to keep up with the project progress;
Pair programming has proven to result in higher-quality products with fewer bugs; most research participants also reported enjoying such collaboration more and feeling more confident about their job;
Customer engagement ensures their satisfaction as their participation in the development and testing process can directly influence the result, getting them exactly what they wanted.

Extreme programming disadvantages

On the other hand, XP has a number of disadvantages that have to be considered when deciding on which framework to choose for your next project:

In many instances, the customer has no clear picture of the end result, which makes it almost unrealistic to accurately estimate scope, cost, and time;
Regular meetings with customers often take a great deal of time that could instead be spent on actual code writing;
Documentation can be scarce and lack clear requirements and specifications, leading to project scope creep;
The rapid transition from traditional methods of software development to extreme programming demands significant cultural and structural changes;
Pair programming takes more time and doesn’t always work right due to the human factor and character incompatibility;
XP works best with collocated teams and customers present in person to conduct face-to-face meetings, limiting its application with distributed teams;
Sometimes customers have neither the desire, time, nor expertise to participate in product development. Considering tight deadlines, it can become a source of stress as either no valuable feedback is provided, or a non-technical representative attempts to manage tech specialists with little or no knowledge on the process;
Some authors also mention overfocusing on code over design, lack of quality assurance, code duplication, and poor results with inexperienced developers.

Any company can apply the XP principles in its projects; however, it’s important to understand both the good and the bad sides. Read on to find out how XP is different from other methodologies and when applying its techniques would be the best choice.

Comparison of XP to other frameworks

As we mentioned above, XP is part of the agile methodology. It shares the main agile principles, i.e., frequent releases, short development cycles, constant communication with the customer, cross-functional teams, and so on. For this reason, XP is often confused with other popular Agile frameworks such as Scrum, Kanban, and Lean. Check our detailed whitepaper to get more in-depth information or the infographics. Here, we’ll briefly compare them and see what the main differences are.

But before we dive in, it’s important to note that XP is not really a project management framework, even though a lot of its practices overlap with those from the project management domain. So, its primary focus is on the technical aspects of development and the implementation of specific practices rather than the management and organizational sides.

Extreme programming vs Scrum

Scrum is commonly associated with self-organizing teams. It also usually has sprints that are 2 to 4 weeks long, while XP iterations are shorter, taking 1 to 2 weeks. Besides, XP is much more flexible with possible changes within iterations, while Scrum doesn’t allow any modifications after the sprint backlog is set. Another difference is that in XP the customer prioritizes features and decides on the order of their development, but in Scrum the team itself determines what to work on first.

Scrum’s main roles are Product Owner, Scrum Master, and Scrum Team, which are different from those in XP.

However, there is no need to choose between XP and Scrum. Incorporating XP practices and Scrum techniques is considered quite effective with XP focusing on engineering aspects and Scrum organizing the process.

Extreme programming vs Kanban

Kanban puts a lot of focus on visualizing the development process and strictly limits the number of features developed at a time. It’s also characterized by a continuous workflow while XP has separate iterations, even though both suggest small frequent releases and a high level of flexibility and adaptiveness to the changing requirements.

The roles in Kanban are not strictly defined.

Extreme programming vs Lean

It’s hard to actually compare XP and Lean because the latter is more of a philosophy or approach to the development process and bringing value to the customer. Its core principles include eliminating waste, deciding as late as possible, delivering as early as possible, and so on. So, Lean’s main focus is not on time-boxed iterations or specific engineering practices as in XP, but largely on a fast MVP delivery and reducing time waste.

When to use XP

Now that we discussed the XP methodology pros and cons and identified its place among other agile frameworks, we can talk about the cases when it’s applicable. It’s important to make sure a company’s size, structure, and expertise, as well as the staff’s knowledge base allow for applying XP practices. These are the factors to consider.

Highly-adaptive development. Some systems don’t have constant functionality features and implies frequent changes. XP was designed to help development teams adapt to fast-changing requirements.

Risky projects. Teams applying XP practices are more likely to avoid problems connected with working on a new system, especially when a customer sets strict deadlines for a project. Additionally, a high level of customer engagement reduces the risk of their not accepting the end product.

Small teams. XP practices are efficient for teams that don’t exceed 12 people. Managing such groups is usually easier, communication is more efficient, and it takes less time to conduct meetings and brainstorming sessions.

Automated testing. Another factor that can influence the choice of XP is the developers’ ability to create and run unit tests, as well as availability of the necessary testing tools.

Readiness to accept new culture and knowledge. XP is different from traditional approaches to software development, and the way some of its practices should be implemented might not be obvious. So, it’s important that your organization and team members are ready to embrace change. It’s also worth inviting an experienced coach if you don’t have previous involvement with XP.

Customer participation. As XP requires customers, developers and managers to work side-by-side, make sure your client is always available to provide input until a project ends.

Agility principles are becoming increasingly popular as they prove their effectiveness. Even though extreme programming is not the most widespread methodology, it offers a lot of sensible practices that can benefit software development and are worth considering for implementation in your projects.

6. Lean

What Is Lean Management? Definition & Benefits

The Lean methodology relies on 3 very simple ideas:
deliver value from your customer’s perspective
eliminate waste (things that don’t bring value to the end product)
continuous improvement
So now, when you know the core idea, let’s dig deeper and get to know the basic principles of Lean management and where it comes from.

What is Lean Management, and How Did It Start?

Before you start with the basic Lean principles, you need to realize that the Lean methodology is about continuously improving work processes, purposes, and people.

Instead of holding total control of work processes and keeping the spotlight, Lean management encourages shared responsibility and shared leadership.

This is why the two main pillars of the Lean methodology are:

Respect for people
Continuous improvements

lean pillars

"The Lean Pillars"

After all, a good idea or initiative can be born at any level of the hierarchy, and Lean trusts the people who are doing the job to say how it should be done.

Currently, Lean management is a concept that is widely adopted across various industries. However, it has actually derived from the Toyota Production System, established around 70 years ago.

The Birth of Lean

In the late 1940s, when Toyota put the foundations of Lean manufacturing, they aimed to reduce processes that don’t bring value to the end product.

By doing so, they succeeded in achieving significant improvements in productivity, efficiency, cycle time, and cost-efficiency.

Thanks to this notable impact, Lean thinking has spread across many industries and evolved to 5 basic Lean management principles as described by the Lean Management Institute.

Indeed, the term Lean was made up by John Krafcik (currently CEO of Google’s self-driving car project Waymo) in his 1988 article “Triumph of the Lean Production System”.

Lean software development

In 2003, Mary and Tom Poppendieck published their book “Lean software development: an Agile Toolkit”. The book describes how you can apply the initial principles of the Lean methodology to software development.

At the end of the day, Lean software development comes down to 7 principles. In the beginning, it didn’t gain popularity, but a few years later, it became one of the most popular software development methods.

The Lean Startup (What is Lean in Business?)

Eric Ries, an engineer and serial entrepreneur developed a methodology based on the Lean principles to help startups succeed. In 2011, he packed his ideas in a book called “The Lean Startup”. The concept consists of 5 basic principles that aim to help startups be more flexible and responsive to changes.

From a business point of view, Lean's is to shorten product development cycles and rapidly discover if a given business concept is viable. This methodology is also employed by government structures, marketing professionals, and others.

As you can see, Lean management was not created in a moment. Instead, it is evolving gradually, thanks to many observations and people's desire for continuous improvement.

So, let’s get to the basic principles of Lean management.

The 5 Basic Lean Principles (How to Create a Lean System?)

1. Identify Value

What does every company strive to do? To offer a product/service that a customer is ready to pay for. To do so, a company needs to add value defined by its customers’ needs.

The value lies in the problem you are trying to solve for the customer. More specifically, in the part of the solution that your customer is actively willing to pay. Any other activity or process that doesn’t bring value to the end product is considered waste.

So you first need to identify the value you want to deliver and then proceed to the next step.

2. Value Stream Mapping

This is the point where you literally need to map the workflow of your company. It has to include all actions and people involved in delivering the end product to the customer. By doing so, you will be able to identify what parts of the process bring no value.

Applying the Lean principle of value stream mapping will show you where value is being generated and in what proportion different parts of the process do or do not produce value.

When you have your value stream mapped, it will be much easier for you to see which processes are owned by what teams and who is responsible for measuring, evaluating, and improving that process. This big-picture will enable you to detect the steps that don’t bring value and eliminate them.

3. Create Continuous Workflow

After you mastered your value stream, you need to make sure that each team's workflow remains smooth. Keep in mind that it may take a while.

Developing a product/service will often include cross-functional teamwork. Bottlenecks and interruptions may appear at any time. However, by breaking up work into smaller batches and visualizing the workflow, you can easily detect and remove process roadblocks.

4. Create a Pull System

Having a stable workflow guarantees that your teams can deliver work tasks much faster with less effort. However, in order to secure a stable workflow, make sure to create a pull system when it comes to the Lean methodology.

In such a system, the work is pulled only if there is a demand for it. This lets you optimize resources’ capacity and deliver products/services only if there is an actual need.

Let’s take a restaurant, for example. You go there and order a pizza. The baker pulls your order and starts making your pizza. He doesn’t prepare tons of dishes in advance because there isn’t actual demand, and these tons of dishes can turn into a waste of resources.

5. Continuous Improvement

After going through all previous steps, you already built your Lean management system. However, don’t forget to pay attention to this last step, probably the most important one.

Remember, your system is not isolated and static. Problems may occur at any of the previous steps. This is why you need to make sure that employees on every level are involved in continuously improving the process.

There are different techniques to encourage continuous improvement. For example, every team may have a daily stand up meeting to discuss what has been done, what needs to be done, and possible obstacles—an easy way to process improvements daily.

Benefits of Lean Management

The growing popularity of the Lean principles comes from the fact that they actually focus on improving every aspect of a work process and involve all levels of a company’s hierarchy.

There are a few major advantages that managers can benefit from.

Focus. By applying the Lean methodology, you will be able to reduce waste activities. Therefore, your workforce will be focused on activities that bring value.
Improving productivity & efficiency. When employees are focused on delivering value, they will be more productive and efficient because they won’t be distracted by unclear tasks.
Smarter process (pull system). By establishing a pull system, you will able to deliver work only if there is actual demand. This leads to the next one.
Better use of resources. When your production is based on actual demand, you will be able to use only as many resources as needed.

As a result, your company (team) will be much more flexible and able to respond to consumers' requirements much faster. In the end, Lean management principles will let you create a stable production system (Lean system) with a higher chance of improving overall performance.

In Summary

Lean management is more like a guide for building a stable organization that evolves constantly and helps to identify actual problems and remove them.

The main purpose of Lean management is creating value to the customer by optimizing resources.
Lean management principles aims to create a stable workflow based on actual customer’s demand.
Continuous improvement is a major part of Lean management, ensuring that every employee is involved in the process of improving.

________________________________

Manual Testing Course-Day 4