Agile Tips for Working with Non-Agile Teams
Agile Tips for Working with Non-Agile Teams
During agile training, we’re taught that everyone in our team should operate within the agreed upon agile framework. However, the question remains: how should we operate when interacting with less predictable teams outside of our own?
Once we get into the agile groove, it’s easy to feel complacent. After all, we’re pushing along at a productive pace and delivering shippable features iteration after iteration. Having all our team members working together with the same principles, methods and frameworks is very comforting – so comforting, in fact, that we might be afraid to operate in any other way.
On the other hand, the world beyond our nice little agile haven is a terrifying, stagnant realm filled with waterfalls leading nowhere and rigid, outdated plans that bend the laws of time. It’s easy to fear interaction with the scary, non-agile world, and it’s also easy to get frustrated when our colleagues or customers don’t have the same liberating habits that we do.
However, for many of us it’s impossible to avoid working with non-agile teams completely – and, as a matter of principle, we shouldn’t refuse to work with others before giving them a fair shot. I’d be willing to bet that almost all of us have, at some point, been required to collaborate with an internal or external party that has little to no agile training, let alone any kind of certification.
While you may be unlikely to suddenly convert the other side to an agile framework overnight, there is still hope. To help you smooth the edges of these sometimes-difficult interactions, here are a few simple, agile tips for working with non-agile teams.
Try Simple Prioritization
If I had to prioritize my advice, I’d prioritize prioritization. The internet is filled with prioritization templates and agile prioritization templates, but you might want to start with something simpler.
If you’re working with an external customer, chances are you can’t afford to exclusively accept agile customers while telling the rest to find someone else to throw their money at. Similarly, if you’re working with a non-agile party internally, you may be equally unable to control their level of agile training.
One of the most common problems faced by non-agile teams is unmitigated scope creep in the form of numerous concurrent requests with limited direction in regards to priority. In this environment, almost everything seems important, and by the way, why didn’t you finish this other important task over here?
Well, as we all know, the answer to that question is that we were busy finishing a more important task that had a higher priority. But, can we pinpoint how that priority was determined in the first place? If the customer isn’t prioritizing their own requests, then your team will be doing most of the decision-making independently (with some level of external input, of course). The more your team prioritizes on its own, the less customer collaboration takes place – and, as we already know, customer collaboration is an important value in agile.
When dealing with a non-agile customer or colleague who does a poor job of conveying the priority of a task relative to other concurrent requests, it’s usually easy to quickly summarize a bulleted list of the current requests and ask the customer or colleague to rearrange them in order of priority. Without realizing it, they’ll start forming their own prioritized product backlog.
Want to take it a step further? Try using one of the many agile prioritization matrix templates available on the internet. I personally like to keep things as simple as possible, but for a larger project and a larger scale of requests, having additional structure may be helpful to some teams.
Emphasize Progress in Iterations
Some people get spooked when you show them early iterations designed to tackle shippable increments. For many non-agile folks, their instinctual reaction may be something along the lines of, “where’s the rest of it?” or “yes, but we still need x, y and z…” and so on.
In these situations, it’s important to explain the advantages of delivering through iterations. Remember, these colleagues or customers may have never used iterative approaches in their careers, so what seems obvious to us may be an uncomfortable shock for the uninitiated.
The advantages of iterative approaches are numerous, but here are some highlights which might help you to convince non-agile colleagues or customers of its practicality:
- Frequent demonstration of features and progress
- Frequent feedback and communication, which improves subsequent iterations
- Less likely to deviate from desired outcome
- Product can adapt to change quickly
- A cross-functional team can quickly shift resources as needed
You might not be able to get the non-agile party to obey a Scrum Master without question, but explaining the value of iterative and incremental development can plant the seeds of agile and ultimately pay off in the long run.
Suggest User Stories Before Solutions
Another pitfall for many non-agile colleagues and customers is the tendency to jump to a lengthy, prescribed solution without clearly and thoroughly explaining either the actual user need or the problem that needs to be solved. Rather than putting forth well-defined user stories that lead to constructive collaboration, this approach can often lead to the dreaded iterative waterfall that isn’t agile at all.
However, before you can expect a non-agile collaborator to write well-conceived user stories, you’ll first need to explain what user stories are and what their value is to the customer. Since the agile team needs to know what problem their work should be solving before they can build an effective solution, it’s in the customer’s best interest to write user stories that answer the “why” as extensively as possible before getting into too much of the “how.” Starting to develop the solution without clearly understanding the problem at hand is rarely a good idea in any setting, and the same holds true for your colleague or customer’s planning process.
Notice a Pattern?
When it comes to working with non-agile collaborators, the best way to ensure buy-in is to explain the value of agile processes. After all, why should someone be expected to adopt your methods if they haven’t yet seen how those methods can benefit them?
Prioritization, delivering over iterations and writing well-crafted user stories are just a few of the ways you can make your collaborative process more comfortable and effective when working with non-agile folks.
What are some of the challenges and solutions you and your team have noticed while collaborating with non-agile parties? What worked, and what didn’t work? Share your story in the comments section below.
Ken Shen Robinson is a senior product manager at Praetorian Digital, where he leads product management for EdTech products that make our communities smarter and safer.Learn More