7 Agile Practices Your Non-Development Team
Agile teams produce benefits, such as faster time to market, customer-focused products, and innovation. The question is often, could non-technology teams also use agile? Agile is a bit different than most ways to work. Unlike operational processes like Waterfall, the focus is not on doing the process better; it’s about better outcomes. Agile values only those activities that enable benefits to be delivered smoothly. Agile practices, activities, tools, and approaches should be tailored to your unique context, including non-technology teams. Let’s review how non-technology teams utilize agile practices.
Every team develops a product or service for either an external customer or an internal customer. If a team’s product or service is not technology (software or infrastructure), a team can still use agile practices to improve performance.
Agile Practices
Daily Standup (aka daily scrum)
Standups enable clear communication, alignment, and support. It spurs the team to internally support each other as they solve challenges on a consistent cadence. Don’t put on a show or a parade. Ask yourself, is this ceremony adding value? How can you improve on it? Focus on the end goal, the Sprint commitments.
In an extreme example, a small development team co-locates daily at one large table. The team continuously discusses, synchronizes, and keeps its agile tool updated with the current status. Therefore, a 15-minute scrum would add no value. You should keep the daily scrum if everything is not transparent and known.
Demo
Before sprints, the team and stakeholders decide how to show progress toward objectives. At the end of the Sprint, the team demonstrates the completed work. This demo enables the team to gather stakeholder and end-user feedback often and incrementally.
A demo of the software is easy – does it work or not? Identify your equivalent to “working software” and how to demo it in your domain. For instance, an account management team uses their demo to tell stories of their customer interactions and what they’ve learned from the feedback.
Retrospective
Nothing can replace continuous learning and subsequent improvement from those learnings. A retrospective is an agile event where the working group reviews themselves to find areas to improve. The team asks themselves: What should we continue doing? Stop doing? Start doing? The discussion ends with improvement actions placed in backlogs for future sprints.
In a retrospective (retro), a sales team bemoaned the length of time needed to transfer information from their sales calls into their CRM database. The Scrum Master contacted Salesforce and discovered an affordable add-on module to solve their issue. As a result, the Sales team now dictates information as they drive to the next meeting and posts their notes with one click to the CRM.
Backlog grooming and Sprint planning
The intent of the agile team’s efforts needs to be clear. Backlog grooming enables stories to be pulled into sprints. Therefore, agile teams use a standard format for user stories. “As__ I want to _ so I can _“ identifies the end-user, the desired function, and the benefit.
It is a small problem statement that can be tested quickly. This practice provides just enough detail to begin work and uncovers dependencies/constraints. A story has just enough detail to estimate effort to place within the team’s capacity in the next Sprint.
Well-composed user stories enable campaign components to be completed independently without incurring lag time between components on a marketing team. This provides the opportunity for robust AB testing and final campaign improvements.
Pair Programming in non-technology teams (shadowing)
Other types of teams can even use the classic pair programming of software development teams. Shadowing a colleague offers similar benefits while improving team members’ skills, speeding delivery, and reducing errors.
Agile visualization tools
Tools like Jira support the work. They should not demand an inordinate amount of time to maintain, nor should they get in the way of the work.
To illustrate, an automobile service team’s Kanban board instantly shows the active work, reasons for delays, and work in progress (WIP). An agile tool should radiate useful information while keeping the team focused on their work undisrupted.
Metrics
Metrics are a necessary component of continuous improvement. Especially with non-technology teams, it’s critical to measure efforts correctly. We monitor metrics so we can improve.
A marketing team demonstrates clicks per view metric improvement. That metric alone doesn’t provide enough information to measure value and progress. Are campaigns being delivered faster and are aligned with the product delivery team? This would be a more useful metric.
Conclusion
Becoming agile is not like turning on a switch. It begins with training and experimentation of agile practices. Start small and adapt some of these agile activities on your team. If you need help implementing, consider working with an Agile coach. They can help you tailor agile for your team and organization
Are you interested in applying agile to your non-technology team? Read how to successfully apply agile values and agile principles.