Lets Talk

It’s Not Just About Process

  • Article, Scrum, Technical Practices

Agile software practitioners focus a lot of attention on people, communication, collaboration, and strong values. In many environments, these are unquestionably the best opportunities for improvement. Inevitably, though, all software development teams reach a point where their greatest opportunity for improving the way they implement and deliver a product are of a technical nature. There is no single standard set of universal technical practices, and Best Practices really need to be thought out in the context in which they would be used. Each team should look at what is most appropriate for their context.

Practices

Here are the core practices we see used by high-performing Agile teams:

Agile Testing

Agile testing is a core part of applying the lean principle of Build Quality In as we develop products. Testing in Agile involves applying testing in a way that increases collaboration and understanding, improves feedback, and helps implement quality products quicker. While the use of automation is an important practice, ensuring we can do the types of manual testing not easily automated, but provide valuable feedback, are just as important.

The key practices and principles here are:

Other Resources:

Test-Driven Development

For most teams automated testing is not new. Some form of unit testing or functional testing is common, but to get a better return on our testing investment, there is a need to level up. We can increase the level and timeliness of feedback by adopting the practice of Test-Driven Development (TDD). In addition to earlier feedback, TDD leverages tests to give the team design feedback that influences better and less wasteful implementation of features than is usually found by testing after implementation.

Test driven development processThe same TDD workflow that is most often applied to Unit Testing can be applied to different levels of tests. The most common TDD related testing activities are:

Other Resources:

Continuous Integration

Software implementation involves the combined efforts of one or more people brought together to form something that is ultimately deliverable. Feedback should be given at the earliest point possible to tell us when new features do not cleanly integrate with existing ones, or the behavior of the system has changed in an unexpected way. While merging and integrating code lines is often considered painful, doing it more often and in smaller increments makes is easier, as well as provides earlier feedback.

The most common practices within Continuous Integration are:

  • Use a single source repository or main code line
  • Automate the build
  • Test each build
  • Commit to the mainline frequently (daily)
  • Drive integration, build, etc from every commit

Other Resources:

Continuous Delivery

Continuous Delivery is in many ways an evolution or extension of Continuous Integration to extend benefits of frequent feedback and automation to packaging and deployment. This means continually delivering code to relevant environments (even production) as soon as it is ready by leveraging deployment and infrastructure automation. This is often where much of DevOps is focused to support collaboration, sharing, and feedback between development and operations.

With Continuous Delivery we mean:

Other Resources:

Refactoring

The goal of Code Refactoring is to restructure existing code in order to improve its readability, reduce complexity, improve maintainability, and make it more extensible without changing the external behavior of the code. This is done by relying on automated tests to ensure the behavior of the code stays the same while making a series of small, incremental changes to the internal structure of the code.

Many modern Integrated Development Environments (IDEs) and code editors provide functionality for assisting with applying common patterns of refactoring such as extracting a new class from an existing one or renaming a method across a code base for clarity/readability.

Refactoring is a key part of Test-Driven Development but can also be performed outside of the cycle when necessary. Normally, the observation of a Code Smell is the driver for performing refactoring.

Other Resources:

Peer Review

Agile Teams are always looking for frequent feedback and knowledge sharing and achieving both at the same time is a big win. By increasing the number of eyes that see and understand any given part of a code base, design, architecture, infrastructure, etc., we apply more knowledge, perspective, and experience to a solution and increase the number of people effectively working in that area.

Core Practices:

Emergent Design

Developers, architects, and teams often struggle with how and when to approach design. In contrast to the more waterfall style of Big Design Up Front in a designated phase, Agile teams tend to design all the time and let the design emerge as features are added. This certainly happens continually through refactoring as part of Test-Driven Development, but other elements of design also take place in planning sessions and designated design sessions. By employing emergent design throughout, we reduce the waste or rework associated with unvalidated or unused designs.

Some key practices and concepts are:

Other Resources:

DevOps

DevOps is often discussed as an outside yet complementary practice to Agile. But its focus on collaboration, shared understanding, and shared responsibilities across Development and Operations are much like the Agile team struggles between Developers and Testers or other combinations of Roles. For Agile teams, DevOps is a key part of achieving Continuous Deployment and Continuous Delivery. These practices are also important for improving consistency, reducing wait time and other wastes, and sharing knowledge between roles that traditionally have been very siloed.

While collaboration and communication are critical, the key technical practices involved are:

Practices for Improvement

Whether you are Agile or Lean, use Scrum or Kanban, or none of the above, these practices and principles and others like them should be considerations for your toolbox and for initiating team improvement.

Related Posts