Working agile with non-agile teams
How can you work with other teams that aren't agile?November 11, 2022 - 873 words - 5 mins Found a typo? Edit me
Let’s assume you already know what the agile manifesto is. Let’s consider that you apply most of the “extreme programming” values, principles, and practices. How can you work with other teams that aren’t agile?
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
You’re using short feedback loops, where things are constantly changing. You can feel that the team is alive and every one is essential.
You embrace the change to the point that you enjoy going out of your comfort zone whenever needed. Seeking to create value for your team and its dynamics, and always considering personal growth.
But sure, let’s assume all that -and everything else I might have missed regarding “agility,” how could you work with an external team that is not agile? How could your “perfectly agile team” work with another group of people with nothing to do with software? For example, a doctor.
A doctor has no time to learn about your “agile values and principles for software development.” A doctor has no time to learn about “extreme programming.” Similarly, they don’t have time to learn about testing, design, architecture, and good practices related to software in general.
How could you create a bridge between that doctor and your software team?
How could you work agile with that doctor?
If you need to work with that doctor is because he/she should be a domain expert. I suggest getting one or two of your team members to meet with that expert for 30/60 min, so they can talk and share their impressions. And then repeat this as much as possible to shorten the feedback loop. For example, once a week.
Collecting those requirements and impressions from the experts and then driving the design of your software according to that is Domain-Driven Design. You can find a lot of documentation about DDD in books (like Domain-Driven Design Distilled) or in many blogs on the Internet.
However, the critical aspect here is not what requirements or impressions are being resolved but how. How could you work agile with that doctor?
Agile is about quick feedback. It’s about effective communication and reducing waste while aiming for simplicity.
By truly applying these five values, you’re already acting agile
These abstract goals apply to any profession - and even life, not just software.
Continuous communication helps shorten the feedback loop, which simplifies the tasks. Always with the courage to address the truth and respect for each other.
Practices are the things that you do
- Sit Together
- Pair Programming
- Test First
- Incremental Design
- and many more
And despite having a technical name, they might apply to any profession:
- Sit Together & Pair Programming: think and do with other peers
- Test First: verify your assumptions first, then solve the problem
- Incremental Design: whatever you do, make it better incrementally
Principles guide and motivate the practices to the values
- Mutual Benefit
- Baby Steps
- and many more
Mutual benefit is the most important because it’s about finding practices that benefit us now, us later, and the customer too.
Other principles include the diversity of ideas. Don’t be afraid of failure. Look at everything you do as an opportunity for learning. Avoid giant steps because they have a higher risk of failing. Aim for a high-quality system because they are more predictable and easier to change.
The question remains: are you agile?
I truly believe an agile team is the one who can cope with change at team level. Therefore, you must first master agile within your team, and then you can collaborate with other teams in an “agile way”.
Once you have internalized these points above, you can apply them while working with anyone from any team.
While these isolated ideas are good, they are even more powerful when combined. They create an atmosphere of curiosity and active learning. It might even wake up some passion for your profession that builds an aura of team cohesion, and just like that, the team breathes on its own.
Everyone cares and takes full responsibility for keeping the team healthy by building trust. There is no fear of healthy conflicts. They feel empowered and accountable to their commitments. The team celebrates their results and learns from their mistakes; there is no need for masks anymore.
That’s when the magic starts to happen, and suddenly you can work agile with any team, especially yours.
- Update your team to be more extreme. How can you help your peers to embrace the change?
- Understanding people. Misunderstandings, effective communication, and self-reflection
- Clean Agile by Robert C. Martin
- Extreme Programming Explained by Kent Beck
- The Five Dysfunctions of a Team by Patrick M. Lencioni