The article “Scrum: An Introduction for Developers” specifically deals with the rules of the game, events, and roles that agility equips in a framework. When companies think about taking the leap into agility, the discussion is usually first about frameworks, processes, and efficiency. Agility is often equated with Scrum, and other aspects that shouldn’t be neglected are pushed into the background. “If we do Scrum, we are automatically agile,” is what we often hear from companies’ management levels. But that is definitely not the case. Scrum is a powerful tool that can support a company on its way to agility. But knowing the rules, roles, and events and incorporating them into the daily software development routine is not enough to achieve desirable results such as efficiency, improved productivity, high-quality software, self-organizing teams, a better understanding of the target picture, and continuous improvement.
STAY TUNED
Learn more about DevOpsCon
When aligning yourself towards agility, do not forget that while on the way, familiar and outdated structures and procedures will be questioned, and perhaps even broken up.
In order to make this transition as easy as possible and for the benefit of everyone involved, it is imperative that everyone from management to the development team have a common understanding of the agile values, anchoring them deeply in their mindset over time. When we talk about agile values, it’s important to distinguish between the four values of the Agile Manifesto and the five Scrum values (which are also often conveyed as agile values). This article focuses on the values in the Agile Manifeso.
Fig. 1: Agile values at a glance
In 2001, 17 thought leaders met, including Kent Beck, one of the three co-founders of the extreme programming method. He was in good company with Ken Schwaber and Jeff Sutherland, who shaped the Scrum process together in the nineties. The meeting’s goal was to explore better development opportunities, addressing the time lag between customer requirements and solution delivery in software that was ubiquitous in the ‘90s. During the meeting, they wrote down four agile values in the “Manifesto for Agile Software Development” (Fig. 1):
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
These values made an enormous impression and even today, they cannot be overestimated. But what do these values mean for development teams?
1. Individuals and interactions over processes and tools
The first of the four values makes it clear that employees and the development team are no longer governed by processes and tools in their approach. Agile approaches value people more highly than a pure focus on processes and tool deployment. This applies to the development team too. The decisive factor for success in product development is not simply the best possible set of processes and tools. It is much more important to assemble the right team of people that can master the tasks and challenges ahead. How these people interact with each other is also important. Successful team interactions help everyone involved work together and solve problems as they arise. Emphasizing individuals puts people and their motivation, innovation, and problem-solving abilities front and center. They use processes and tools in the agile environment, which can be optimized within the team and translated directly to improvements in product development. In agile, processes and tools are valued despite the focus on individuals and interactions. The resulting advantages for the development team are obvious. Development teams can organize themselves and are no longer completely subject to corporate guidelines. Nevertheless, the word “over” (meaning more important than) in the agile values cannot be ignored. The fact that individuals and interactions are considered more important than processes and tools doesn’t mean that the team is no longer subject to any corporate guidelines. If certain tools or frameworks are given, such as Visual Studio as the development environment, C# as the programming language, and .NET as the development platform, in this case, the word “over” fulfills its scope and the development team will have to tackle other processes or tools for a change.
However, development teams have far greater opportunities to innovate by decoupling from a rigidly prescribed process and tool landscape. Many teams decide to repeatedly create added value for the customer along the development by evaluating introducing new software components or frameworks when needed. The fact that development teams can customize their tools and processes as needed gives teams a great degree of freedom and helps them feel more responsible for the product.
2. Working software over comprehensive documentation
The next agile value introduces the topic of responsibility. The developer was and is still responsible for a large part of the document. Focusing on functioning software shifts the prioritization of some documentation. Primarily, it is about implementing the requirements specified by the customer and delivering a working piece of software. Agile methods are not opposed to the idea of documentation. Teams are simply encouraged not to document more than necessary and to keep documentation as simple as possible when it is needed. Documentation is still considered important if it helps us understand the work that needs to be done and the best way to do it. However, in the face of constant change, it isn’t possible to continuously document all requirements at the beginning of the process up to the finished software. In an agile process, it is less important to have comprehensive documentation than to bring working products to market in order to use customer feedback and support the product’s continuous improvement.
The most important thing is focusing on the information within the documentation. As with requirements elicitation, writing documentation is not an end in itself. You determine what information should be made available, assuming that this information will support the finished piece of software. For example, a team may decide to trim the source code’s documentation or architecture in order to place more emphasis on test documentation.
3. Customer collaboration over contract negotiation
With a focus on a working piece of software, the third agile value was included in the Agile Manifesto. Development teams are aware of non-agile project management. The customer, together with a responsible person from the company, puts a great deal of effort into defining the contract details and, above all, the scope of services for the delivered software. The customer is usually only involved in the specification phase, in the event of changes to the project’s scope or content, and in the acceptance of the finished project, or sections of it.
Experience shows that the majority of projects fail to meet the market’s needs, which may have changed by the time the project is delivered.
A study by the Standish Group in 1996 found that 46 percent of features are never used by users (Fig. 2). Furthermore, in 2010, the follow-up study found that 50 percent of features are hardly ever used.
Fig 2: Standish Group Chaos Report 2018 [1]
You can conclude that with agile development, you should focus on permanent collaboration with the customers and requesters. This way, you ensure that with every delivered piece of software you are as close as possible to meeting customer and market requirements. This also avoids placing – and developing – features in a contract that won’t be applied anyway.
Of course, during this, the development team’s tasks and responsibilities also change. In agile development, entire volumes of specifications give way to straightforward requirements that are usually tailored to a maximum four-week delivery cycle. As we described in the first part of this article series in the section “Product Backlog and User Stories instead of Specifications or Requirement and Performance Specifications” [2], requirements in user stories are often deliberately kept short and formulated in everyday language. The development team is directly involved in the formulation, scope, and editing of the user stories, often exchanging information with the customer or requester.
4. Responding to change over following a plan
The last of the four values is derived from close collaboration with customers and requesters and a shift in focus from an initial tightening of requirements to agile methods. A quote attributed to Heraclitus states, “The only constant in life is change.” This is especially true in product development. One of the goals in agile is to maximize the added value of each finished piece of software. At the same time, it is almost impossible to plan all the content and functions of a software product in advance in a meaningful way. Agility promotes the acceptance of changes in the function and scope of the product first and the possibility of introducing new ideas along with the needs of the market in order to increase the product’s added value second. For the development team, responding to change means being highly adaptable. The reward for this is the prospect of co-designing the software, processes, and gaining knowledge and experience. Encourage openness to change and embrace it when needed. But this should not obscure the fact that an existing plan is the basis for an eventual response to change. However, as shown in the second article of the series “Agile Estimating and Planning” [3], plans are not set in stone. Adapting the plan is a conscious decision when there are new insights or needs in the market, legal changes, or infrastructural adjustments.
The high value placed on reacting to change becomes clear when using Scrum as a framework. The Scrum Guide defines “adaptation” as one of the empirical Scrum pillars. Planning and regularly reviewing processes gives us insights and new information. These are powerful tools for identifying and responding to change. Development teams can be heavily involved during reviewing and responding to change, making valuable contributions in experiencing the value of agile.
Looking towards the four values we described and their effects that they can have on development teams, it’s obvious that using a framework alone cannot transition a company to agile. Companies should also strive to build an agile mindset across all departments and roles involved. Basing this on the four values from the Agile Manifesto is a good start.
Links & Literature
[1] https://www.standishgroup.com/sample_research_files/Modernization.pdf
[2] Haban, Rouven: “Scrum: An Introduction for Developers”, Windows Developer 1.2021
[3] Haban, Rouven: “Agile Estimation and Planning”, Windows Developer 2.2021
