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:
Course Contents
Section 1: Agile Project Management
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