Agile myths

Some of you may notice that as a result of many myths about what is "truly agile", some teams have become significantly less agile, and they have certainly become less effective at building great products.

Some teams that claim to be agile are creating environments that are very rigid and inflexible in fact. In some cases, the definition of agile on teams is based on a complete misunderstanding of true agile principles.

A number of these myths are responsible for the most common agile anti-patterns, so let's take a look at some of the things people really believe about agile. Some of you may find it from your stories of learning by failure examples. I've conducted desk research and observation on "live organizations", what I have found out?

Agile is for building things faster, according to myth #1

There is one of the most pervasive myths of agile development, and it's very popular for a good reason. It's partially true! Agile methodologies can, very frequently, help teams build things faster than a waterfall process.

Running faster is not the primary goal of being agile, and in some cases it can even hurt you. If you're running in the wrong direction, running faster will only take you further away from your goal ;)

In fact, agile does talk about getting things in front of users quickly, which is another reason why we see this misunderstanding.

The real goal of agile is to get things in front of users quickly, so we can get feedback on them and continuously improve them.

This leads to all sorts of problems since it is very easy to mistake this for "get everything out as soon as possible, and then move on." Did you hear that before?

Example:

Researchers and designers should be able to recognize this myth when they join a new team, because teams that just use agile methodologies to go faster can be particularly challenging.

It is common for research and design on "teams like this" to work at a rapid pace in order to constantly provide engineers with new things to develop. The main criteria for success for engineers and management is how many features get shipped. They are obsessed with output rather than outcomes and are measured on quantity rather than quality.

Designers often complain that wireframes or mockups are sent to them before they have time to think about a design. Once I have spoken to a designer who said that a team would ask for wireframes literally the day before engineers began working on a feature, leaving no time for actual design or research.

It is common for teams like this to become feature factories, where they simply keep churning out features without iterating or measuring their effectiveness. When they focus more on building new things as quickly as possible than thinking about how everything works together, they can end up with tons of technical and UX debt.

Agile means no research according to myth #2

Among all the myths, this one is the most difficult to comprehend. After all, the idea that we should be getting constant feedback from users is right there in the Manifesto! Isn't that a pretty compelling argument for research? Some agile teams get great feedback on work that has already been released, but they don't have the time or place for proactive research in their processes.

The manifestation of this on teams is the phrase "Oh, we don't have time for research" and designers being assigned to "create designs" for things in just a couple of days.

Because UX researchers are often viewed as a "separate entities", research is often tackled concurrently with other tasks, leading to unnecessary delays. For example, a cross-functional team consisting of designers, engineers, and product people may rely on the researcher only for some things. However, this is probably the worst approach since the team becomes accustomed to thinking of research as someone else’s responsibility and they don't realize that having it done before last minute could save them hours or even days worth of work.

As a result, teams sometimes create something called Sprint Zero, which is a single sprint in which engineers conduct research and design before they begin developing. I would love to dive deeper next time. (Maybe one of the best Scrum Masters that I know in my team would be helpful to share their knowledge here.) Just keep in mind not to just turns this into a series of tiny waterfalls, and it often fails because not all research and design fit into one sprint!

Agile lacks vision and holistic design according to myth #3

Because agile methodologies are iterative and rely on user feedback, there is a misconception that agile does not allow for a holistic or overall design.

Example:

A lot of user stories will already be broken down into small chunks or tasks if you join an agile team. Some teams with a low design focus may have designers assigned these tasks and asked to draw a wireframe or mockup for them. Obviously, attempting to create a single wireframe for a very specific feature without any user research or general context can result in a very fractured user interface.

A successful information architecture is key to making a website as useful and user-friendly as possible.

Even when you’re not dealing with large, diverse sets of data like an e-commerce catalog. I have been working on e-commerce with thousands of products in HoReCa industry. That was an interesting information architecture rollercoaster :)

If you worked on a job board as a designer, you would be asked to develop a new job posting interface for employers. If you wanted, you could create a generic job posting interface where employers could post any job.

Essentially, to create a useful interface, the designer needs a good understanding of how things will work in the rest of the product. Just building a single screen or wireframe in isolation can lead to all sorts of rework.

Agile means no deliverables according to myth #4

When designers aren't given any time to do real research or design work, they can end up in a situation where they feel like they have no time to create deliverables. It's not always necessary to design with pixel-perfect mockups, a journey map, and three personas.

As such, being agile doesn't mean you never need to create another wireframe. Instead, it means you might have to get a bit creative and flexible in how you define deliverables.

I have read on the blog's post commentary that there are no deliverables in agile work. Am I missing something? If you are in design school or an agency, you know that a lot of time is spent crafting and perfecting the artifacts themselves to be attractive, because we don't just look at the artifact itself; we also assess it against other deliverables to make sure they're successful. But with agile work, communication is everything. Good teams are cross-functional and collaborative by nature, so this often leads to less detail in the final product.

In addition to having solid design systems and ensuring that everyone on the team understands the business and user goals for a feature, designs can be communicated purely through writing or conversation.

Research deliverables may also vary considerably. Rather than a 50-page research deck that takes a month to construct, research deliverables might emerge directly from analysis and synthesis sessions with the entire team.

By working together to understand research findings, researchers and designers can convert research insights directly into new designs.

All of these aren't "no deliverables," though. As a designer or researcher, you still have to communicate things to other team members, and that usually requires some form of communication medium.

Being agile doesn't mean moving faster (you are not a DC Flash) or getting rid of design deliverables or not having a holistic product vision. In order to get the benefits of agility, you need to correct these myths or learn to ignore (?) them when you encounter them. If you can't, you'll need to figure out how to work around the

I'm far for Scrum Master but as a leader that believes in a growth mindset, I enjoy scratching a surface and seeing what is beneath it. I’m curious about what kind of Agile myths have you encountered. Can you give some examples?

More Agile myths

#agile #leadership #myths #scrum #design