What are some common agile anti-patterns and how do you avoid them?

There are several ways to identify these patterns. A common thing to look for is how frequently you’re delivering. If your team delivers frequently, lets say daily. You’re not doing waterfall. There is a difference in delivering for a VCS and for an audience. Look to deliver to your audience frequently with small increments.

Converting story points directly into hours is an agile anti-pattern and contradicts the original purpose of story points. "Story points were invented to obfuscate duration so that certain managers would not pressure the team over estimates." - Ron Jeffries Instead of estimating work with hours, Allen Holub recommends using the scale "trivial, easy, normal, hard, herculean, don't know."

Agile anti-patterns often disguise waterfall processes, emphasizing upfront planning and fixed roles. Embracing iterative, incremental methods fosters true agility, with frequent delivery and adaptive responses to feedback.

Instead of planning everything upfront, break the project into smaller parts and deliver them one at a time. Work closely with others and be open to changes along the way. Let team members help in different areas, rather than sticking to fixed roles. Always ask for feedback and use it to make improvements. Focus on delivering small, useful parts of the project often, rather than waiting for a big reveal. Follow Agile principles, which emphasize flexibility and continuous improvement.

In my tenure as the CEO of Digiryte, I've encountered several agile anti-patterns that can significantly hinder the effectiveness of agile practices. Recognising and addressing these anti-patterns is crucial for maintaining the agility and productivity of our teams. Here, I will share some of the common pitfalls we've faced and the strategies we've implemented to overcome them. One of the most deceptive anti-patterns is "Waterfall in disguise," where teams adopt agile ceremonies but continue to follow a sequential development process. This often manifests as long sprint cycles and delayed testing phases.

Using sprints and defining the amount of work expected to be finished during that sprint in an agile anti-pattern. Sprints are timeboxed iterations to allow foster feedback to the business and allow development to continually make sure they are working on the most important thing the app doesn't do. Any attempt to commit to delivering a fixed amount of work in a sprint shows that you are applying waterfall processes under a new name.

Overloading sprints comes from 1. the team overestimating their capacity 2. product owners pushing for additional urgent work without getting enough push back 3. the fear that if something is not 'in the sprint' it has to wait for another 2 to 3 weeks before it can be worked on. Keep a prioritized backlog, commit to the most important thing, and keep enough slack that you will be able to pick up work that is identified as important and urgent later.

Overloading sprints with excessive tasks leads to missed deadlines and burnout. Prioritize tasks by value, estimate realistically, and monitor progress for sustainable delivery.

First, focus on picking the most important tasks for the project. Don't try to do everything all at once. Second, be realistic when estimating how long each task will take. It's better to overestimate than to underestimate. Third, commit to only what your team can handle within the sprint timeframe. Don't take on too much work. Lastly, keep an eye on how things are going during the sprint. If it seems like you're falling behind, adjust your plans accordingly. By following these steps, you can prevent your team from feeling overwhelmed and ensure you're making steady progress without burning out.

Sprint overload occurs when teams commit to more work than they can realistically deliver in one sprint. This often leads to burnout and reduced product quality. At Digiryte, we tackle this by rigorously prioritising our backlogs and involving the whole team in the sprint planning process to ensure commitments are realistic. We also monitor our velocity and adjust future commitments based on past performance to prevent overload.

Neglecting testing in Agile leads to poor quality and increased technical debt. Embracing TDD/BDD and automation ensures consistent quality and minimizes rework in the development cycle.

Skipping or minimizing testing can lead to buggy software and increased technical debt. To address this, incorporate testing into every stage of development, including unit testing, integration testing, and user acceptance testing. Encourage a culture of quality assurance where testing is viewed as integral to the development process rather than an afterthought.

Test-Driven Development (TDD) and Behavior-Driven Development (BDD) help avoid anti-Agile patterns by emphasizing: TDD: Writing tests before code to clarify requirements, validate functionality early, and promote incremental development. BDD: Collaboration and user-focused testing through shared understanding of system behavior, creation of executable specifications, and automation of tests based on user scenarios. Both approaches ensure alignment with Agile principles, facilitating iterative development and delivering value to stakeholders.

In agile environments, bypassing adequate testing can lead to significant technical debt and buggy releases. We emphasise a Test-Driven Development (TDD) approach, where tests are written before the actual code. This not only improves code quality but also enhances design and maintainability. Our continuous integration system automatically runs these tests, ensuring issues are caught early and often.

Silos, either in thought or practice, are anathema to the foundational principles of agile methodologies. At its core, agile thrives on iterative feedback, constant communication, and an unwavering commitment to collaborative problem-solving. When teams work in silos, they inadvertently counteract the very agility they're striving for. The risk is not just redundancy or inconsistency; it's the stifling of innovation. The greatest ideas often emerge from the confluence of diverse perspectives, from the merging of different expertise, and from the unexpected intersections of seemingly unrelated problems and solutions.

The silo mentality in agile teams hampers collaboration and efficiency. Foster transparency and teamwork through open communication and tools like daily stand-ups to overcome this challenge.

When teams operate in silos, communication and collaboration suffer, leading to inefficiencies and misunderstandings. To overcome this, foster a culture of collaboration and transparency where teams work cross-functionally and share knowledge freely. Encourage open communication channels and regular meetings to facilitate alignment and coordination.

Agile thrives on collaboration, yet a silo mentality can develop when teams work in isolation without cross-departmental interactions. To break down these barriers, Digiryte promotes cross-functional teams and utilises tools like JIRA and Confluence to enhance communication. Regular open forums and inter-team meetings ensure transparency and the sharing of insights across the board.

Resisting change in agile development inhibits progress by clinging to original plans, and disregarding valuable input. Embracing change fosters improvement, leveraging techniques like user stories and product demos to validate assumptions and adapt seamlessly.

Resistance to change is natural, but in an agile setting, it can be a major roadblock. To address this, we foster a culture where change is viewed as an opportunity for improvement rather than a threat. Training sessions, workshops, and regular retrospectives are conducted to ensure everyone understands the benefits of agile methodologies and is equipped to adapt to new processes and tools.

Skipping continuous improvement in agile leads to stagnation. Adopting a kaizen mindset fosters ongoing learning and enhancement. Utilizing retrospectives, experiments, and feedback loops helps in assessing performance and making informed improvements. From experience, this proactive approach not only elevates team dynamics but also significantly boosts project outcomes, avoiding the pitfall of becoming complacent with current methodologies. Continuous improvement is the heart of agility, ensuring practices evolve to meet ever-changing project demands effectively.

Teams need room to innovate; if you trust your teams and allow them to improve continuously, then it's doubtful that all your teams will do the same thing. Teams that are trusted and allowed to innovate will look different from every other team in the organization. This can be very scary and make management difficult, but it is essential to find out what works.

Neglecting continuous improvement in agile practices leads to stagnation and mediocrity. Embracing a kaizen mindset and utilizing practices like retrospectives and feedback loops are essential for sustained success and growth.

Keeping feedback to the retros is one of the biggest anti-patterns of 'cargo-cult-agile/scrum'. While it is useful to pencil in time to reflect on how to work with the team, that is no excuse to not address issues when they come up. The whole point of being agile is to react to feedback quickly. The retro is there to train that muscle, not to limit discussions and introduce a cadence in which the team can adapt.

The absence of continuous improvement mechanisms can stall progress and lead to stagnant practices. At Digiryte, continuous improvement is part of our DNA. We conduct regular retrospectives not just to reflect on what went wrong, but to actively devise and implement strategies for improvement. These insights are documented and revisited to ensure we are constantly moving forward.

Anti-patterns: Using the word "sprint". Training everyone in Scrum and letting Development figure out incremental engineering in their own.

Fundamental Agile anti pattern is to not define what agility is needed by the business in measurable terms. This is the primary reason for many organizations to keep on "Doing Agile" and not "Being Agile". Tools / Processes / Ceremonies etc. are all means to an end, which is Business Agility. You need to be able to look back at your adoption and have a clear answer whether it is successful or not in business terms.

Rarely considered but always essential for success is thinking of your technical architecture. Conway's law says how we communicate, and trust determines our technical architecture. Your current architecture was built around your current culture. This is not trivial; pay attention to your architecture and its constraints. In many cases, you have to find ways to de-scale and develop more robust interfaces between products before you can truly provide end-to-end value in short iterations.

Consider WIP limits , work in progress limits how many stories or hours are assigned to a resource. Only giving them a steady flow of work they can actually complete so they don't have a backlog. That way work assigned is always work completed based on the limit of their skills and dev capacity.

A critical agile anti-pattern often missed is neglecting user feedback during development cycles. Agile methodology thrives on customer collaboration over contract negotiation, emphasizing the importance of integrating user feedback continuously. This oversight can lead to a product that, although technically sound, fails to meet user needs or expectations. To counter this, regularly incorporate user testing sessions and feedback channels into your agile processes. Engage directly with users through beta testing, surveys, or user story mapping sessions. This approach ensures that the product evolves in alignment with real user requirements, enhancing both its relevance and value in the market.