Principles Behind the Agile Manifesto states, "Working software is the primary measure of progress." For multi-disciplinary Agile teams, the scope of working software is not the exclusive responsibility of software engineers. It is dependent on specialists from many domains.
Are you responsible for working content? Do you deliver working insights? Who's responsible for a working information architecture? What about the experience design? Are you the go-to for working UI design and interactions? How about working analytics or working objectives?
Know what needs to work from your perspective and ensure that your contributions and skills are considered in the planning. When this is achieved, teams go beyond working software to software that works.
As your agile-based team recognizes working software as more than just functioning code, executing as a highly responsive unit presents a few challenges. In particular, the best implementations of Agile practices fall victim to occasional misalignment and dysfunction. If unchecked, these will keep teams from meeting quality standards and desired outcomes, not to mention cultivating a stressful working atmosphere.
To protect yourself and your team against such risks, consider the following principles for navigating common Agile challenges and creating effective software sooner rather than later.
- Agile advocates agility, which is arguably its core cross-discipline principle.
- Working software is software that works for everyone. If "working software is the primary measure of progress," software that works for everyone is the ultimate measure. The software should work for people who consume it, create it, and support its continued operation.
- Ambiguity is not a feature of Agile. Expect coherent objectives, as they are the ultimate enablers of agility.
- User stories should never be handed down. As a contributor to "working software," participate in creating and/or validating user stories to scope sprint activities and secure desirable outcomes.
- Delineate discovery activities from solution activities to demonstrate "cause and effect. While it’s possible to deliver solutions, it’s difficult to architect sustainable solutions without a grounded understanding of the domain and its participants.
- Push back on chaos. Agile gives less importance to process, documentation, contract negotiations, and planning. However, any credible implementation of Agile in large-scale organizations will have an operational framework complete with process, documentation, a working plan, and accommodation for unforeseen circumstances and change requests.
- Challenge yourself to break down your vision into smaller chunks. Agile promotes value by reducing complexity into smaller portions. If you think in systems, ask yourself, how can your plan be implemented in stages? This exercise often helps to create a more elegant system design by exposing less obvious scenarios.
- Insulate yourself from short-range thinking by stepping back and questioning whether the pieces of your efforts still contribute to the whole. Periodically schedule sprints that evaluate and align your objectives with other dependent teams.
- Agile and its implementation are not the same. Agile is a set of principles. Scrum and Kanban are examples of how Agile can be put into practice.
- Agile is intended to produce value. As you develop strategy and solutions, seek approaches that help to demonstrate value. For example, structural design (information architecture) analytics is a powerful way to connect design and content strategy to key business drivers with the following sprints: 1) structural design baseline, 2) structural benchmarks, and 3) impact measurement.
