agile practices & agile testing

The foundations of agile ways of working is the "Agile Manifesto" from 2001, in which a group of 17 software developers formulated a set of agile values (and principles) aimed at improving software development:

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

This leads to principles that advocate a collaborative, iterative, and incremental approach that can address current needs as well as future needs. Iterative refers to an approach that repeats a process until a desired result is achieved. Ideally, only an initial functional version of a product component is developed. This must meet the identified needs without being perfect. It can be tested under real conditions and subsequently improved. Incremental refers to a step-by-step approach in which the project grows organically. This is in contrast to waterfall models, which progress a project linearly, i.e. define different phases with a start and end point.

The advantages of such an agile approach are:

• Flexibility: Agile teams can react quickly to the unexpected and to newly discovered or emergent needs. The resulting effort is re-estimated by the team.
• Real-time project progress transparency: the customer can make adjustments and view resource consumption throughout the project.
• Regular exchanges create a high level of trust among team members and with the client(s), minimizing friction in day-to-day work.

Some terms and agile techniques are important for working in agile teams. Agile techniques are practices that have proven to be helpful in implementing agile values in daily work. We briefly explain some examples of best practices here: 

Design thinking describes a mindset of agile working in which the customer and his needs are at the center of innovative design processes. You can find out more about this way of thinking and working under the heading "Innovation and Design Sprints" on our website.

Continuous Integration describes the continuous merging of existing with newly developed components in software development. Thanks to automated tests and static analyses of the software quality of the individual components as well as the entire product (unit test, integration test, system test), it can be ensured during the entire development that all newly added elements do not have a negative impact on the executability of the software and that no errors occur. 

Continuous Delivery (CD) is a further development of this continuous integration. In this process, a new version of the software is delivered at certain intervals or when a certain quality metric is achieved.

Continuous Deployment refers to the final provision of an automated software release pipeline according to the DevOps principle. In this process, changes made by developers to the source code directory of an application are automatically checked and released for the production environment. The software is always developed, so to speak, in such a way that it can be released by the manufacturer at any time and (continuously) delivered to the user.

DevOps refers to the collaboration of developers and IT operations in a team throughout the entire product lifecycle - from development (Dev) and testing to deployment and operation (Operations/Ops). Since DevOps is an ongoing process, it is visualized with an infinite loop. Although the phases appear to be incremental, the infinite loop shows that collaboration and iterative improvements are essential throughout the lifecycle. At trendy, we've advanced DevOps to CustDevOps because our customers need to be part of our team, too, and constant interaction with them is part of our successful product. CustDevOps is the constant iteration of Design Sprint (Cust/Customer view), Development (Dev) and Production (Operations/Ops).

Kanban boards or task boards are supposed to make workload and workflow visible. They are simple overview tables where tasks queued on (colored) cards move from a column on the left side of the board (not yet started) to the right side of the board (completed). The simplest division is a three-column one of ToDo, Doing, Done. Depending on the team size and complexity, additional columns are added, e.g. Backlog, ToDo, Doing, Test, Done. In addition, there are team-specific rules for the maximum number of tasks per column (so-called work in progress limits). So instead of starting a lot of tasks whose work status has to be checked again and again, teams can jointly estimate efforts and prioritize which and how many tasks have to be started and finished first before new tasks can be started.

Scrum is an agile approach to project management in which there is no project management anymore, who distributes the tasks to the team members. In so-called sprints, which usually last two to four weeks, potentially deliverable products, so-called increments, are created, which are further developed with each subsequent sprint.
Scrum recognizes three roles: Product Owner (sets the technical requirements for the product, prioritizes the individual Product Backlog items and, when a story is completed, checks whether the increment meets the Definition of Done), Scrum Master (responsible for the smooth running of the Scrum process and supporting the team in achieving the sprint goals) and Development Team (responsible for implementation or development). All team members work independently, self-organized and have equal responsibility.
The Scrum process consists of several artifacts and ceremonies. The product owner keeps a list of requirements: the Product Backlog. Before each sprint, he decides which tasks will be implemented in the next iteration. In doing so, all requirements must be formulated in natural language and a few sentences according to the principle of "who am I and what do I want with what goal". This format is called user stories. The selected user stories are transferred to the so-called Sprint Backlog as selected for development during Sprint planning and disappear from the Product Backlog.
All user stories from the sprint backlog are discussed in a sprint planning meeting between the product owner and the development team. The Scrum Master moderates this meeting and ensures careful planning and the formulation of a Sprint Goal. Subsequently, the Development Team pulls tasks from the Sprint Backlog. In a daily 15-minute Daily Scrum Meeting, also called Daily Standup (since everyone involved completes it standing up), team members plan the day, update each other on the status of their respective task progress, any obstacles that have popped up, and express requests for help should anything stand in their way of completing their tasks. 
At the end of a Sprint, a Sprint Review and a Sprint Retrospective are conducted by the entire Scrum team:
The Sprint Review reflects on the past Sprint and serves to present the increment to the stakeholders and discuss the further roadmap with them. 
Afterwards, the sprint retrospective takes place in the development team with the Scrum Master present. With a view to the past sprint, problems encountered are discussed and successes celebrated. The retrospective serves to optimize the cooperation of the development team and to avoid repeating mistakes. Immediately after the retrospective, the next sprint begins until the product is completed.

The Scaled Agile Framework (SAFe) is an established framework for applying Scrum or Agile in larger dimensions, i.e. for scaling. SAFe offers agile solutions for all levels of an organization: from teams to divisions to corporate management. For this, agile is targeted at a higher level of abstraction: The Program Increment. At this level, requirements are formulated, meetings are lived and work is performed on interlocking backlogs.
LeSS (Large Scale Scrum) is an extension of the roles, ceremonies and artifacts of the Scrum framework for organizing multiple Scrum teams. The goal of a LeSS implementation is to reduce complexity and maximize agile principles throughout an organization so that the most valuable work can always get done. LeSS particularly invokes trial and error through experimentation according to the motto: there are no best practices, there are only practices that are good in a given context. Therefore, LeSS provides enough tangibles to get started and enough flexibility to scale.
In most cases, however, a scaling framework is not necessary to coordinate the different teams and resolve dependencies. Especially when only a handful of teams  are working together on a product, these challenges can be solved through intense communication, or something more institutionalized, in the form of a Scrum of Scrums. A Scrum of Scrums is an additional ceremony in the context of a Sprint, where, often directly after the Daily Scrums of the teams, representatives from the individual teams meet to coordinate their plans and resolve dependencies.

According to the SCRUM approach, the DoD must clearly define the criteria according to which something is considered to have been sufficiently worked on. Possible criteria for the Definition of Done can be acceptance criteria of the user story, complete documentation of the increment, the agreed tests (unit, integration, system, non-functional tests) have been successfully executed, mobile responsiveness or similar. These criteria are already defined by the Scrum team in the first sprint and continuously adjusted. The Definition of Done is particularly important for the development team, because they deliver the finished increment (i.e., the increment that corresponds to the DoD) to the product owner.

Extreme Programming (XP) is an agile framework for software development that uses established software development techniques in a particular way: constant reviews, continuous testing, continuous design and redesign as well as constant feedback, short release cycles and the strong involvement of the customer or contractor. Extreme programming is particularly suitable for projects whose requirements change frequently and quickly. Basically, risks such as missed deadlines, escalating costs and low software quality should be minimized.
The five values of XP are communication (in the team and at eye level), simplicity ("What is the simplest thing that will work?"), feedback (recognizing opportunities for improvement, adapting procedures), courage (effective action even in personally challenging issues) and respect (objective and appreciative cooperation).

Collective Code Ownership is the explicit agreement among all team members that each has not only the right, but the obligation to make changes to the code as needed. This may be to complete a development task, fix a bug, or improve the code overall. The Boy Scout Rule is often cited in this context: Always leave the code you are working on in a better condition than you found it.

Pair programming is a procedure in which two developers write code together on one computer; alternatively, it is also referred to as tandem programming. It is a very communicative, collaborative procedure, in which better code shall be achieved by mutual reviewing. One of the two developers writes the code and takes the role of the driver or pilot. The other thinks about the problem definition and the emerging solution, checks the written code and addresses things that strike him in the process. He takes over the role of the navigator or observer. Due to its positive teamwork effects, pair programming is also well suited for the training of less experienced developers by a mentor or for "pairing", in which two people of different skill backgrounds work together so that the joint product achieves a higher quality and both learn from and with each other.
 

Test-Driven Development is a practice from Extreme Programming that uses test cases to guide development. TDD is an iterative process in which the developer first writes an automated test case for the code to be implemented next. Of course, since no code has been written yet, this fails the first time it is executed (Red). After this, usually in a few short iterations, exactly enough code is developed so that the test case can be successfully executed (Green). 
Now the developer can adapt this part of the program without changing its functionality, since he can check this with the test case at any time. This allows him to improve the code, in particular to make it more maintainable and testable (refactoring). Once this is done, the process starts again.
The advantages of this approach are that only necessary code of higher quality is developed and extensive automated unit tests are available for every part of the system.
 

Agile techniques that guide development from a functional perspective through test cases are Acceptance Test Driven Development and Behaviour Driven Development. The practices are closely related and differ only in details.
In these practices, the team details the requirements using examples from the real application domain. These examples can then be automated in the form of acceptance test cases and serve as a guide for the developers to implement the domain-specific functionalities.
Another advantage is that these test cases simultaneously represent the domain-oriented specification of the system and, due to their executability, never lose their topicality, i.e. they represent a "living" documentation of the system. 
 

Feature Driven Development is a lean project management method for developing software that delivers value. The basis of the framework is the assumption that a feature contains value for the customer.
At the beginning of an FDD project, a technical overall model for the system to be developed is first developed together with the stakeholders. In the second step, features are derived step by step from the overall model, with each feature corresponding to one step of the business activity to be supported.
These features are now planned individually and then first designed iteratively and incrementally and then developed and tested. The aim is to implement a feature in less than two weeks.

Technical debt is the term used to describe future, additional effort resulting from the current delivery of - consciously or unconsciously - less than perfect agile software development products.

Retrospectives are team meetings in which, in a protected atmosphere, a retrospective assessment is made of what went well or less well in the previous teamwork and what can be learned from this for future collaboration. Agile methods rely on a regular, evolutionary improvement process in accordance with the "Inspect & Adapt" principle. Ideally, each sprint is followed by a retrospective with the entire team.

Through continuous feedback, teams can optimize their processes and incorporate customer feedback to improve the next release. External coaching, either selectively or tailored to a specific challenge, can also help agile teams to mirror their own working methods and receive valuable feedback for optimizing their own work. trendigs consultants are skilled and have many years of experience in supporting agile teams in their work in a way that values them and increases their success.