Back

Agile Declaration of Interdependence

 The Declaration of Interdependence (DOI) was created back in 2005 by “a community of project leaders that are highly successful at delivering results.” It was made as an extension of The Agile Manifesto, with the intent of guiding project managers, product managers, and other project leaders, and consists of six management principles.

#1 – We increase return on investment by making continuous flow of value our focus

Strategizing to deliver value to customers includes analysing the target market, determining the product’s value proposition, studying the competition, and identifying core business capabilities. When it comes to bringing that value to the customer, the Scrum framework is designed for continuous delivery of that value. The time-boxed Sprints ensures the concrete definition of project tasks and the Sprint ceremonies facilitate the inspect and adapt activities.

It is part of the tester’s responsibilities to help ensure that this product increment will indeed be usable for the customers and that they will not experience any inconvenience. This can be done by collaborating with the scrum team to ensure that everyone understands the requirements as well as checking the system for defects.



#2 – We deliver reliable results by engaging customers in frequent interactions and shared ownership.

More than just deriving requirements from the customers at the beginning of the project, Agile also encourages closely working with them throughout the project. This means involving them in reviews to get feedback from them, or having regular checkpoints with them to see how the product is performing for them.

Testers can help by being one of the people who reaches out to the customers and making them feel that they are part of the process. By understanding their needs and getting feedback from these interactions, they can give their insights to the rest of the team so they can understand the customers themselves.

#3 – We expect uncertainty and manage for it through iterations, anticipation, and adaptation.

A variety of events and reasons can set the product to new directions, including:

  • Arrival of findings from usage analytics that show feature adoption and user engagement
  • Emerging trends and technological advances that the business and customer can benefit from
  • Customers not liking or complaining about a particular feature in the application

Anything can happen to influence changes in requirements and the work environment, so Scrum  teams should always anticipate and be ready to respond to them. There must be room for adapting, as plans are not set in stone.

In traditional projects, testers have an allotted time for carrying out their tasks throughout the project timeline. But in Agile, their tasks for analysis, design, and execution of testing need to be done simultaneously. By having the mindset that change is inevitable and having strategies in place, scrum teams will have a better chance of effectively keeping up and building the product right.

Recommended Further Reading

The following materials may assist you in order to get the most out of this course:

Section 2: Using the Agile Manifesto to Deliver Change

Section 3: The 12 Agile Principles

Section 4: The Agile Fundamentals

Section 5: The Declaration of Interdependence

Section 6: Agile Development Frameworks

Section 7: Introduction to Scrum

Section 8: Scrum Projects

Section 9: Scrum Project Roles

Section 10: Meet the Scrum Team

Section 11: Building the Scrum Team

Section 12: Scrum in Projects, Programs & Portfolios

Section 13: How to Manage an Agile Project

Section 14: Leadership Styles

Section 15: The Agile Project Life-cycle

Section 16: Business Justification with Agile

Section 17: Calculating the Benefits With Agile

Section 18: Quality in Agile

Section 19: Acceptance Criteria and the Prioritised Product Backlog

Section 20: Quality Management in Scrum

Section 21: Change in Scrum

Section 22: Integrating Change in Scrum

Section 23: Managing Change in Scrum

Section 24: Risk in Scrum

Section 25: Risk Assessment Techniques

Section 26: Initiating an Agile Project

Section 27: Forming the Scrum Team

Section 28: Epics and Personas

Section 29: Creating the Prioritised Product Backlog

Section 30: Conduct Release Planning

Section 31: The Project Business Case

Section 32: Planning in Scrum

Section 33: Scrum Boards

Section 34: Sprint Planning

Section 35: User Stories

Section 36: User Stories and Tasks

Section 37: The Sprint Backlog

Section 38: Implementation of Scrum

Section 39: The Daily Scrum

Section 40: The Product Backlog

Section 41: Scrum Charts

Section 42: Review and Retrospective

Section 43: Scrum of Scrums

Section 44: Validating a Sprint

Section 45: Retrospective Sprint

Section 46: Releasing the Product

Section 47: Project Retrospective

Section 48: The Communication Plan

Section 49: Formal Business Sign-off

Section 50: Scaling Scrum

Section 51: Stakeholders

Section 52: Programs and Portfolios

Translate »