# Working Agile with Non-Agile Teams *How can you work with other teams that aren't agile?* 2022-11-11 | `agile` `xp` `communication` `team-management` > 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? --- ![blog-cover](/images/blog/2022-11-11/cover.jpg) 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](https://en.wikipedia.org//wiki/Domain-driven_design). You can find a lot of documentation about *DDD* in books (like *[Domain-Driven Design Distilled](/readings/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? ![blog-middle](/images/blog/2022-11-11/middle.jpg) > 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 - Communication - Feedback - Simplicity - Courage - Respect 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 - Diversity - Failure - Opportunity - Baby Steps - Quality - 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. ![blog-footer](/images/blog/2022-11-11/footer.jpg)