What is the Agile Declaration of Interdependence and how does it impact the Scrum Development Team? What are the sections of the declaration?
The Agile Declaration of Interdependence
A 59 Seconds Agile Video Animation
The Agile Declaration of Interdependence for Developers
A 59 Seconds Agile Article
In software development, the Declaration of Interdependence is a document that discusses the core ways that pieces of Agile depend on each other. A software development team is not a single person with a specific task. It is a complex and faceted structure that requires many concurrent events to work properly.
Declaration of Interdependence – Section 1
The first item of the document states that “we increase return on investment by making a continuous flow of value our focus.” As a general rule of thumb, return on investment depends on increasing value. Since any request for software has an expected return on investment, it is up to the Scrum team to deliver a return on investment to the stakeholders in the form of value. Since developers are the role responsible for creating new features, they are the driving force behind generating value.
However, developers require the direction of other roles to determine what features are most valuable. The most efficient team of developers in the world may fail to create significant value if they constantly work on less valuable requests. Therefore, developers rely on the product owner and stakeholders to know what features would add the most value to a product. These roles are interdependent in generating value for stakeholders, making it a key point in the document.
Declaration of Interdependence – Section 2
Second is “We deliver reliable results by engaging customers in frequent interactions and shared ownership.” One of the biggest differences between Agile and traditional software development is how Agile gets constant feedback from stakeholders, while traditional development sticks rigidly to a contract. There are numerous benefits to this, but one of the most evident is that results are more “reliable”. Stakeholders can depend on being satisfied with each new release because every release contains the most valuable features that developers could finish. This establishes an interdependence between developers and stakeholders. Developers depend on stakeholders to remain in constant communication and voice what they want from the product. In return, stakeholders depend on developers to listen to feedback and incorporate it into development.
Declaration of Interdependence – Section 3
The third says, “We expect uncertainty and manage for it through iterations, anticipation, and adaptation.” One of the most unique parts of Scrum is how it runs in cycles. This cyclical nature gives several benefits over the once and done style of traditional development. With numerous iterations, development is divided into contained segments. The Scrum team releases an updated product with new features at the end of each sprint. This gets working software into the hands of stakeholders earlier, and more frequently.
Anticipation and adaptation work together to create a more responsive team. Instead of sticking to a contract, the adaptive style of Agile creates a product closer to what stakeholders want. How does this relate to interdependence? The short iterations of Agile require all parties to work effectively together in order to get work done quickly. For traditional software development, features could take months or even years to release, and that is considered acceptable. In Agile, most sprints last a few weeks at most. Every role, developers included, rely on each other to do their jobs so that the process runs smoothly.
Declaration of Interdependence – Section 4
Fourth of the parts of the document reads, “We unleash creativity and innovation by recognizing that individuals are the ultimate source of value, and creating an environment where they can make a difference.” Developers in traditional environments are typically considered interchangeable. Despite differences in ability and specialty, developers often receive assignments at the discretion of management. This often results in developers working on features that they may be less than familiar with. In contrast, Agile development allows teams to organize themselves. One consequence of this is that developers gravitate toward features they are more familiar with, and thus can more effectively work on. The interdependence of this item exists between developers. Each developer must understand his or her abilities, and communicate with other developers to determine who should work on which requests.
User Stories Applied by Mike Cohn is one of our favourite books on Agile User Stories. The book starts with an overview into user stories, and details what a user story is and the different aspects of them. He then discusses how to go about writing a user story, and provides details of the INVEST criteria that can be used to determine if the story is meeting all of its objectives. Next Mike gives an in depth discussion of who user stories are written for and where to begin when gathering the details for them. The book then discusses acceptance testing user stories, including how to go about specifying these criteria and the responsibilities of the development team and customers during this process.
Our Favourite Agile Books
We found these books great for finding out more information on Agile Scrum: