How to Translate Agile Principles for your Non-Development Team
This is the second article in a series on Agile for non-technology teams. In the first part in this series we discuss adapting Agile values for non-technology teams.
Put Agile into action for your Non-Technology Team with the 12 Agile Principles
Agile focuses on the delivery of value (i.e. any type of product or service). Agile is not limited to software development. Other functions, such as accounting, recruiting, and marketing, bring innovative customer-focused services and products to market quicker and more efficiently with an agile mindset.
By adopting the agile principles for your non-development team, you can put the Agile Manifesto’s values into action and realize the benefits of agile for your organization too. As you apply the principles to your specific context, don’t get hung up on the semantics. First, identify the principle’s intent and translate the development-focused wording to your domain, whether marketing, education, or any team that delivers value to an end-user.
No translation needed
Many of the agile principles need no translation to apply with non-development teams. As you read the actionable principles, consider how they can be applied to your team and organization.
Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
Business people and developers must work together daily throughout the project.
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Simplicity–the art of maximizing the amount of work not done–is essential.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Translating Agile Principles for non-technology teams
Some principles can be translated to extract the intent for your domain and understanding for teams who don’t work in software development. Likewise just replacing a word or phrase will do the trick.
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
In both of the above principles, translate the word ‘software’ to your product or service. For example, a non-fiction author chooses to release their book online one chapter at a time, replacing software with “a chapter.” As reader comments flow in, the agile author may adjust future chapters. The readers are satisfied early, often, and continuously with improvements on a regular cadence.
Working software is the primary measure of progress.
For teams who don’t work in software development, replace the word ‘software’ with the smallest increment of value that can be delivered and used by the customer. Staying with our publishing example, an educational publishing team could translate this to “state-specific chapter content.”
Continuous attention to technical excellence and good design enhances agility.
Meanwhile, translate ‘technical excellence and good design’ into domain-specific language that focuses on the same intent of excellence that designs to reduce errors and future re-work. For example, an agile accounting team translated this principle. They concentrate on automated data collection (financial data excellence) and consistent logical formulaic calculations of clean data (design).
The best architectures, requirements, and designs emerge from self-organizing teams.
It’s well documented that self-organizing teams outperform micro-managed teams. For non-technology teams, replace ‘best architectures, requirements, and designs’ with domain-specific language with the same intent of excellence in your context. To demonstrate, consider a lab team focused on testing thousands of samples daily is better positioned to develop high-quality systemic requirements than an executive sitting behind a desk removed from the process. Those who do the work know the work, and agile teams will innovate to improve.
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
Although the meaning of the principle easily relates to non-technology development teams, we will update it for the times. Today’s teams may effectively create ‘face-to-face’ interactions through video chats or IM. The majority of workers today are digital natives who skillfully navigate the digital connection. Again, it depends on your culture, environment, and people.
Make Agile Work for You
Do you get hung up on agile terminology? Don’t. Be agile and modify the label while keeping the intent of the value or principle.
Some teams we’ve worked with have revised standard agile terms to how they think and talk. Language matters, and it should resonate with your team.
The value is in the clarity of the intent and purpose. Agile coaches can help tailor Agile for your non-technology team.
Agile is not a dogma. It’s flexible and focused on valued delivery to the customer while embracing change and listening to the customer. Agile is designed to be tailored to the specific context of an environment, culture, and goals. If you aren’t sure how to tailor it to your organization, work with an Agile coach that can guide you.