Agile Anti Patterns

When traditional organisations and managers embark on an agile journey they often apply agile with a traditional mindset that leads them to violate the agile values and principles. This article describes some of the fundamental agile anti-patterns so you can avoid them. An antipattern is a common response to a recurring problem that is usually ineffective and risks being highly counterproductive.

While it is possible to give a list of common violations of the scrum rules as others have done, I will take a more fundamental approach and look at anti patterns from the point of view of the agile manifesto which defines what agile is.

Agile value anti patterns

Agile is a philosophy based on working together to uncover better ways of delivering value to customers. A good agile implementation is an evolutionary process tailored to the organisations context. Over time it may require major changes to the organisations structure, culture and processes.

One common anti pattern is to apply agile locally in the development team without the leadership support required to change the rest of the organisation. When the agile team is blocked by structure, culture, funding or waterfall processes the agile implementation stops and is often rolled back by command and control managers.

Another anti pattern is to take the agile ways of working developed by another organisation and apply it in a big bang, top down, cookie cutter change focused on cutting costs. This is a very disruptive, high risk approach that can cause a lot of damage before it pays off. If there is no real change in the way the work is organised those costs will come back somewhere else, usually as expensive consultants and contractors.

Processes and tools over individuals and interactions

Good agile teams focus on individuals and interactions. A common anti pattern is for Managers to use JIRA and daily stand ups to micro manage the team. Coaching groups become the new methods police dictating agile processes and tools. Real agile is about removing blockers and empowering teams with new ways of working so they can continuously improve.

Comprehensive documentation over working product

Good agile teams focus on creating valuable products instead of documentation. A common anti pattern is for agile teams to be embedded in a waterfall process that requires comprehensive documentation for downstream teams. If you want to get the benefits of agile you have to change your structure to allow teams to deliver a value stream from idea to implementation. Agile teams produce just enough documentation, just in time.

Contract negotiation over customer collaboration

Good agile teams co-design solutions with customers and partners throughout the product life cycle. But many agile teams never talk to a real customer. They rely on managers to tell them what the customers wants and they lock customers and vendors into fixed price, fixed scope contracts that cause adversarial relationships. Open up to collaborate.

Following a plan over responding to change

An agile organisation makes change easy so that teams can learn and adapt. A common anti pattern is for managers to demand that agile teams commit to a fixed scope, design, time and cost developed up front. Often organisations apply agile in their development teams and leave the rest of their waterfall process intact. Adversarial contracts and annual budget commitments prevent change and increase time and cost. Real agile teams do just enough planning, just in time.


Agile Principle anti patterns

Deliver value slowly

Good agile teams deliver valuable product features early and often. Unfortunately its still common for organisations to spend many months designing and planning a project before the agile team starts and then to deliver releases in big blocks every six to 12 months. To get the benefits of agile you need to apply it to the whole product development life cycle from concept to cash.

Prevent change or don’t control it

Agile teams work with stakeholders and partners to get the best business value possible from the time and budget available. A common problem is for managers to demand that agile teams deliver a fixed scope in a fixed time and budget. This forces teams back into waterfall delivery to defend themselves. On the other hand new agile teams can get confused about how to manage scope and end up going over budget trying to give stakeholders every little thing they asked for. This isn’t agile either.

Big bang delivery

Good agile teams deliver valuable products to customers every few weeks. A common anti pattern is for organisations to make agile teams deliver to downstream test, deployment and operations teams. This forces teams back into a big bank waterfall deployment every six to 12 months. In an agile organisation teams do their own test, deployment and operations so they can deploy to production every day if necessary.

Departments prevent collaboration

In an agile organisation stakeholders, partners and delivery teams work together in cross functional, co-located, client focused teams that deliver valuable products to production.

A common anti pattern is to implement agile in the software team while leaving everything else the same. This leaves all the traditional conflict, delays and costs created by a department structure and waterfall process in place.  It’s common in this situation for technical teams to appoint their own product owners because business people aren’t available to work closely with the team. As a result stakeholders lose confidence that the team are delivering what they want.

Command and control

Agile managers trust and support their teams. They explain the mission and ask the team to work out how to achieve it. They provide resources and remove blockers when asked.

An anti pattern is for managers to use JIRA and the agile processes to micromanage teams. Micro management forces people to spend a lot of time providing updates and justifying their approach when they could be doing work. It forces them to work at an unsustainable pace leading to serious quality issues and burn out. It turns teams into passive, stupid machines unable to take responsibility and  improve the way they work. Agile managers coach and support their teams, they don’t command and control them.

Poor communication

In an agile organisation people work in cross functional, collocated teams so they can have face-to-face conversations. If people are remote they are on persistent video conferences with the rest of the team.

A common anti pattern is for teams to be made up of people from different departments and companies with different interests and different values in different locations. Most communication is via documents, email, phone and video conference. The ball is dropped a lot. Leaders manage perception and hide issues so that things look better than they really are. Issues get worse until they blow up and cause serious damage.

Focus on tasks

Agile organisations measure progress by how much value they deliver to customers. Often organisations don’t understand or measure the value they deliver so they focus on measuring the number of features and stories produced. This turns the agile team into a factory mindlessly churning out features that managers want but customers don’t. Ultimately executives question the value of the team and remove funding because they cant see the value delivered.

Unsustainable pace

In agile organisations the work flows smoothly and people work normal hours. An anti pattern is for managers to drive the team to work long hours to meet impossible time frames developed up front. Product owners don’t prioritise the backlog and managers focus on maximising utilisation. High pressure, bottle necks and long hours lead to conflict, mistakes, poor quality, rework, long delays, high costs and burn out.

Technical Debt

Good agile teams invest in excellent technical practices and good design because it increases their speed, efficiency and flexibility.

An anti pattern is for agile teams to sacrifice design and technical excellence to rush through stories as quickly as possible. Often teams resist agile technical practices like XP, OODD, Refactoring, BDD and DevOps because they don’t understand them. This leads to rigid, poorly designed solutions with lots of defects, rework and technical debt.

Overly complex solutions

Agile teams deliver high value quickly by focusing on delivering the features that deliver the most value to customers. When they have tested these in the market they develop the next most important features.

A common anti pattern is for Product Owners to insist that 80% of features are must haves. Then designers and architects create a complex solution that delivers everything in one big, complex, expensive solution. The team doesn’t find out what customers really want until they have invested a considerable amount of time and money. Only then do they find that a considerable amount of their investment was wasted on things customers didn’t care about.

Micro management

Agile organisations structure teams so that they can take responsibility for designing solutions and delivering value to stakeholders. A common anti pattern is for teams to be set up so that they cant take responsibility for end to end delivery. In these organisations managers drive the team, run the meetings and manage dependencies. Managers use agile and JIRA to micro manage the team. Team members become passive, defensive and demoralized, robotically producing mediocre results.

Ignore important issues

Agile organisations continuously improve by collaborating regularly to identify blockers and resolve them. If the team cant resolve the issue themselves they ask managers to resolve it at the organisation level.

It’s a common anti pattern for managers to refuse to allow teams the time to hold real retrospectives.  It’s also common for major organisational blockers to remain unresolved because senior managers don’t want to admit there is a problem or do anything about it.  If individuals or teams raise issues to management they are ignored or punished. This often happens in organisations that have a culture of manipulation, favoritism and perception management. Eventually issues get so bad that they cause serious damage to the organisation. Real agile organisations discuss sensitive issues openly and honestly, resolving them quickly and rationally. If you’re organisation isn’t prepared to be honest agile may not be the right fit.



There are a large number of fake agile and bad agile implementations out there that don’t deliver the benefits expected. Often this is a transition stage from traditional ways of thinking to agile ways of working. The solution is to go back to basics and work together to uncover better ways of delivering value to customers using the agile values and principles. You can do it if you try.

Contact me on murrayr3128 at gmail dot com if you want some help.


Further reading

What’s Missing In The Agile Manifesto: Mindset

Breaking bad agile transformations in 5 minutes

Better outcomes in software development

Requirements are untested hypotheses about customer needs

In agile our highest priority is to satisfy the customer through early and continuous delivery of valuable products and services. We achieve this through rapid build, measure, learn cycles.

Research shows that 80% of features are rarely if ever used. Managers don’t know what customers want so they put in everything they think customers might want. This means that business requirements are untested hypotheses about customer needs.

Screen Shot 2018-12-20 at 1.45.01 PM

In agile we believe that simplicity is essential. If you can focus on what customers really want you can cut project time and cost by 80%. To achieve this you need to test your requirements and design concepts early and often.

No alt text provided for this imageThis is why you should be deploying to production every sprint. If you cant deploy a feature then watch how customers are using your product, show them a design concept or prototype and find out what they think.

Product Owner v Product Manager – what’s the difference?

Managing the development of new products and product features is a complex process, with multiple stakeholders and competing priorities. Often, in large teams, the role of product lead is split between Product Manager and Product Owner.

The roles can overlap, but the main difference is that the Product Manager is focused on product / market fit while the Product Owner is focused on getting the development team to build valuable product features.

Product Manager

The Product Manager is responsible for ensuring that the organisation develops and delivers a profitable product that meets the needs of the market. The Product Manager develops a product vision with customers and stakeholders and turns it into a prioritised, high level roadmap of activities that maximise business value. The product roadmap may include a mix of customer research, sales, marketing, feature development, training and process improvement activities.

Product Managers have a broad scope which means that they may not be able to give the development team the time and attention they need. In this case they may appoint a Product Owner to work full time with the Development team on their behalf. If they do this they should meet with the Product Owner every few days and attend the planning and review session with the development team every couple of weeks to ensure that the development team is prioritising business value correctly.

Product Owner

Product Owner is a role that was popularised by Scrum, an agile framework that helps you to develop valuable products in half the time. The Product Owner is the interface between business stakeholders, customers and the delivery team. Their primary goal is to maximize the value of the work done by the development team.

Product Owner is a full time job that requires skill in product management, business analysis, communication and project management. Located alongside the development team day to day, the Product Owner works closely with stakeholders to define the objectives, understand user needs and work out what features are required to improve the user experience and meet business objectives.

At the same time they work closely with the development team to rank the product features by business value, risk and dependency and analyse, design, develop and test the features in an incremental cycle, showing stakeholders what they have developed every few weeks.


The Product Owner is the critical role in an agile development team. A good Product Owner is customer focused, passionate, empowering, honest, analytical, detail oriented, decisive, available and engaged. It’s a fascinating role for a Product Manager, Business Analyst or Project Manager that provides considerable career growth for people lucky enough to do it.

5 ways to be an effective Product Owner

A Product Owner has the most important role in an agile team. Their job is to maximise business value by communicating the product vision, prioritising the product backlog and taking key stakeholders on the journey. Here are five tips to help you be a better Product Owner:

1. Advocate for the product

The Product Owner should be the champion for the product. They should know the product vision and details inside out so that they can communicate it to stakeholders and the team throughout the project and they should make sure that the team get the resources and information they need to maximise business value. The role of the Product Owner can be intense, as they’re pulled in many directions, but they should remain present and proactive, bringing clarity and direction to the project.

2. Adaptive planning

Effective Product Owners plan quickly and replan frequently. They do “just enough planning, just in time” because they understand that projects are full of assumptions about what customers want, what the business needs, and what the solution is. At the start of a project they develop a high level plan with the team in a few weeks so they can get started as soon as possible. Then they deliver in small iterations so they can test their assumptions and adapt the plan based on feedback.

3. Estimate business value

At the start of the project and at the start of each sprint the Product Owner should estimate the relative business value of the features and stories in the backlog. The Product Owner can use affinity estimation with key business stakeholders to quickly synthesize everyone’s views. When you know the relative size and value of the stories in the backlog you can organise them into releases that produce the maximum business value in the shortest time possible. Involve the technical team to ensure that they understand what the business priorities are.

4. Communicate with the team

Team effectiveness depends on good communication. To maximise communication the Product Owner communicates face to face with the delivery team every day. The best way to do this is to physically sit with the team to get involved in all the discussions that occur. When the Product Owner is communicating well with the team then the team can make good decisions about what they need to do to maximise business value and the Product Owner understands what support the team needs from the business.

5. Be decisive

The list of things that a team could do is always bigger than the list of the things they can do and this list increases as more people get involved with different priorities. The Product Owner is responsible for balancing competing priorities by constantly re-prioritising the product backlog. This means saying “no” to feature requests that have low business value. A Product Owner can deliver a product within the time and budget available if they are decisive about what features are in and out of scope. They understand that bad news delivered well improves relationships and increases trust.


The Product Owner is responsible for satisfying the customer by delivering a valuable product as soon as possible and then iterating on it to improve it. This is a leadership role where you have to say ‘no’; work within a budget; motivate teams and be across both the vision and the detail. These are just five of the many things a Product Owner could do to achieve successful outcomes in this challenging and rewarding role.

5 ways to increase your business agility

Agile is a new way of working that was created to address serious problems with the way work is traditionally done. First implemented in software development teams, the increased speed, productivity and customer focus that agile brings has seen it applied to all areas of business.

Below are a few ways to check if your business is truly agile:

1. Is your team customer focused?

Agile teams solve the customers’ problems, whether the customer is internal or external. They understand the customers’ objectives and have key performance indicators based on customer satisfaction and retention, not cost. Agile teams know that doing the right thing by the customer the first time leads to lower costs than doing the job wrong and then trying to fix it afterwards.

Product Managers have a broad scope which means that they may not be able to give the development team the time and attention they need. In this case they may appoint a Product Owner to work full time with the Development team on their behalf. If they do this they should meet with the Product Owner every few days and attend the planning and review session with the development team every couple of weeks to ensure that the development team is prioritising business value correctly.

2. Is your team able to solve a customer problem from end to end?

Agile teams contain all the different skills and functions required to solve a customer’s problem, from end to end. These people work together full time to continuously deliver outcomes that customers want. Cross functional, colocated teams are hyper productive because they remove waste, rework, delays and communication costs. An agile team that is developing a new product or service would be made up of people from sales, marketing, design, development, testing and operations colocated in one cross functional team.

3. Does your team make their work visible?

In a factory you can see the work people are doing and all the supplies and unfinished work that piles up. In offices you can’t see the work in progress which means that you can’t see the wasted time and effort in the system. Agile teams visualise the work on a scrum board or kanban board so that everyone can see what’s being worked on, what’s done and what’s next. When a team visualises their work they can manage it themselves without needing to be micromanaged. They can also see where there are bottlenecks in the system so they can fix them. This leads to faster and more productive teams.

4. Is your team regularly reviewing and improving the way they work?

Agile teams meet face to face every day for 15 minutes to discuss what they are doing and identify blockers. When they find a blocker team members help solve the problem. Every two weeks the team gets together with the client (internal or external) to review what went well, what didn’t go well and what they could do differently next time. This leads to gradual and continuous improvement in the way the team and the organisation works. Regular retrospectives are the core of agile.

5. Is your team testing and iterating?

The highest priority of an agile team is to deliver early and often.  Agile teams focus on delivering the simplest possible version of a product early so that they can deliver value quickly and get customer feedback early. Agile teams know that requirements are untested assumptions about user needs. The best way to deliver a high value product is by testing it early and often. If managers are expecting to deliver a rich, complex product in the first release then they are not adopting an agile mindset.

Teams that truly adopt agile are faster, more productive and more effective at meeting customer expectations. Agile workplaces are also more collaborative, cohesive and sustainable for those of us lucky enough to work in one.

The agile future of business

The age of the customer

We have moved from the age of manufacturing to the age of the customer. In this new age customers have more information and more choice than they’ve had before which leads to increased expectations.

In the past, businesses spent years designing mass produced products for a mass market and selling them through mass media. This no longer works. To succeed in the modern world, businesses need to quickly design tailored products for target markets, sell via two way conversations and use rapid feedback to continuously improve.

Fast-fashion brand Zara is a great example of a company that does this. Zara is surpassing competitors by releasing new items four to five times faster than a traditional retail brand. In just five days store managers, designers and commercialisation teams work with pattern makers, in the same office, to develop a concept and prototype a garment. In just two weeks, manufacturers make several thousand garments and send them to the logistics centre in Zaragoza, Spain, and from there the garments are flown to stores all over the world. This means customers can buy the latest fashion, from design to storefront, in less than a month.

How do businesses achieve agility?

Agility is a simple concept, but difficult to achieve in practice. Behind the scenes this fast delivery pace requires autonomous, empowered and cross-functional teams that are able to collaborate and adapt quickly to ever changing needs. This is where agile values, practices, and their associated benefits come in. No longer limited to software development, agile principles and tools are being applied across all aspects of the workplace to achieve faster outcomes.

Agile is fundamentally about breaking down silos and bringing people together into cross-functional, co-located, customer focused teams that can deliver solutions many times faster than before by being highly collaborative, iterative and focused. Agile methods are now used by many companies in non-technical areas such as legal, marketing, finance and customer-service areas of online companies. Companies that practice agile include Spotify, Microsoft, Google, CBAANZREA Group and SEEK.

In practice, implementing agile involves replacing slow business processes with new ways of working. Many organisations do the following:

  • Restructure their organisation so that work is done in cross-functional, co-located, client focused teams.
  • Leverage visual work tools, such as Kanban boards, to provide a shared understanding of the work in progress so that teams can swarm on bottlenecks.
  • Hold short, daily team meetings to communicate and identify if anyone needs help
  • Use two week sprints to plan and complete work.
  • Create the minimum viable product (MVP) necessary to test customer demand before investing heavily in new products.

How do businesses manage agile teams?

Managements teams need to ensure that their structure and key performance indicators reward this new way of working. Teams need to be rewarded for experimentation, learning and the delivery of business value rather than the delivery of documents. They need to know that it’s better to find out that you’re wrong with an early version of a product, than it is to find it out after huge investment of time and money.

Agile is an approach that can deliver substantial value in many areas of a business, not just software development. As we move towards an agile business future, executive, HR and marketing, to name a few, have successfully implemented agile and accelerated profitable growth.

Learn more about Silicon Block agile courses.

Speak to an advisor

How to be a good leader

We have all had good leaders and bad leaders in our careers and often people who are a mix of both. Unfortunately there seem to be far more bad leaders than good ones. This really isn’t acceptable because leadership has a big impact. Good leaders help us do our best work while bad leaders stress us out and make it difficult to do good work. Fortunately you can learn to be a good leader with coaching and experience.

As part of IE’s agile training I asked people to take part in a retrospective on managers and leaders during their careers so that we could define what it takes to be a good leader. This is what we came up with.


Good: encourages, supports, defends and rewards good work.

Bad: negative, complains, attacks and blames.


Good: coaches and trains, shares the glory, gets the best out of people and helps people move to a better role.

Bad: takes credit for other peoples work, blocks training and blocks career moves.


Good: encourages people to raise issues, discusses issues and happy to be wrong.

Bad: doesn’t listen, shoots the messenger and has to be right all the time.


Good: accepts issues, takes ownership of problems and discusses difficult issues with people.

Bad: refuses to admit there are problems, won’t take responsibility for problems and refuses to discuss difficult issues.


Good: resolves issues blocking the team, resolves conflict, calm under pressure and says no when required.

Bad: doesn’t resolve issues blocking the team, doesn’t improve team methods, doesn’t resolve conflict, is afraid of upsetting people and doesn’t challenge broken systems.


Good: understands the work, helps improve the way the work is done, challenges bad rules and poor practices, streamlines administration, makes good decisions and helps their team efficiently produce high quality work.

Bad: doesn’t understand the work, doesn’t provide enough resources to do the work, gets in the way of people doing the work, forces people to comply with stupid rules and bad practices, increases administration costs, makes poor decisions about the work and makes their teams slow and low quality.


Good: delegates, empowers, coaches, mentors and teaches.

Bad: micromanages, doesn’t trust anyone, demands frequent detailed reports, wont delegate and doesn’t coach.


Good: open, honest, encourages discussion, doesn’t tell you what you want to hear and leads by example.

Bad: manages perception, denies involvement in decisions, is deceitful and deceptive, breaks promises and says one thing and does another.


Good: understands people, cares about people, builds relationships, leaves their ego at the door.

Bad: feels entitled to power and privilege, is jealous of others, doesn’t care about people and treats people like tools.


Good: calm, organised and clear.

Bad: disorganised, poor briefing, sudden urgent tasks and frequent changes in direction.