Agile Patterns, Anti-Patterns and Myths Flashcards
Which of these situations indicates a poor (or wrong) implementation of agile?
a. Designers should always deliver wireframes and mockups in exactly one sprint.
b. Designers can sometimes end up creating documents or spreadsheets instead of wireframes.
c. Everyone on the team is involved with the research instead of just the person who’s appointed to do the research.
a. Designers should always deliver wireframes and mockups in exactly one sprint.
Some agile teams may misinterpret “agility” as building faster, even at the cost of research and holistic design. In such scenarios, designers are likely to be told to create wireframes or mockups for specific features, and asked to deliver them in time for the engineers to begin work (sometimes, being given just a day or two to work on it).
In a more agile team, designers will be empowered to hand off deliverables in unconventional formats when appropriate. Since the role of designers is to communicate the designs to the team, the form of the deliverable need not always be a wireframe or a high-fidelity mockup. Similarly, to work around time constraints, an agile team will involve and participate in research together, so that the team can learn and improve as one unit.
As a designer, what can you do to improve the team’s agility?
a. Quit the team, as the rigidity sets in at the top and there’s not much you can do about it.
b. Ask the team to define the goal, outcome, and success metric for the design activity.
c. Delay your design deliverables and prove to the team that design is time-consuming.
b. Ask the team to define the goal, outcome, and success metric for the design activity.
While there are times when you can feel helpless in a rigid, “agile” team that only wants to churn out feature after feature without looking back, you do have some options to help improve the situation—for yourself and your team. One of the ways to reorient the team is to discuss the goal of a design request. Define the expected outcome of the design and how the team should measure it. You can then follow up on these expected outcomes and make your case for revisiting the feature, incorporating feedback and iterating till you meet the expectations.
What is Agile Fall?
An unholy hybrid of agile and waterfall. An Agilefall is a waterfall, masquerading as agile, with the core tenets of agile applied in silos and within individual waterfall phases.
When does Agile Fall generally happen?
It generally happens when upper management still wants the comfort of a top-down approach where they get to approve all features at all stages before engineering starts building, but they claim to want agile engineering teams because they think things get built faster that way.
How do you recognize AgileFall?
AgileFall’s most common manifestation occurs when all product functionality is completely defined up front and then thrown over the wall to an “agile” engineering team who break it down into tickets and then try to get it all done in a couple of sprints.
Another hint is when, even though you’re working with agile engineering methodologies, you’re still not getting any working code in front of users for months at a time, and you’re waiting until everything is completely done before deploying anything. You may also have a weeks-long QA period at the end of the engineering process.
What is design as a service org?
In agile, design is as much a part of the team as engineering. When design is treated as an external consultant whose services are called on only as and when needed, work is likely to suffer.
In many large organizations, design and research have always operated in a silo. This means that the design team is separate from engineering and often from product. There are pros and cons to having design managed as a separate team in general, but it’s definitely a problem when you’re trying to implement agile methodologies.
How do you recognize design as a service org?
Luckily, these are extremely easy teams to identify because this particular anti-pattern is right there in the org chart. You can also discover them with a few well-targeted questions about how teams are structured if you happen to be interviewing at a company that says it practices “agile.” Any company where design exists only in a silo is going to have problems implementing any sort of actual agile methodologies.
What are feature factories?
Agile teams that only focus on rolling out features in quick succession, without bothering to revisit them, are called feature factories.
The weirdest anti-pattern that we saw was one where teams simply refused to ever iterate on anything. It was a bit surprising, since feedback and iteration are so critical to the entire concept of agile methodologies, but this behavior was incredibly common on teams. Many teams simply focused on pushing out feature after feature without ever looking at how they fit into the larger picture or going back and iterating to improve the experience.
How do you recognize feature factories?
You’ll know your team is a feature factory if they measure everything only by velocity and burn down charts and never go back and make things fit together as a whole. Teams like this primarily care about the speed with which they produce things, and they don’t spend much time reflecting on whether those things were successful at producing specific outcomes.
They also tend to be told which features to build by the sales team or company executives or some other stakeholder. Instead of being asked to solve problems for users, they are told to build very specific things, and they are given no authority to get feedback on the things they release or make adjustments if they’re not performing as expected.
What is complete chaos?
A team without a clear vision or plan is bound to end up creating chaos.
Perhaps the opposite of feature factories is complete chaos. Agile methodologies encourage experimentation and pivoting based on customer feedback, while they discourage trying to plan out features many months ahead. Unfortunately, some teams take this to the extreme and refuse to plan anything at all, which can result in complete chaos, especially on larger teams where people have to coordinate changes.
How do you recognize complete chaos?
some teams simply jump from thing to thing, generally depending on which customer or stakeholder has asked for a new feature. Sometimes they won’t even finish the feature they’re currently working on because the priorities changed in the middle of implementation, and they’re forced to shelve the work and move on to the next thing.
As you can imagine, this is extremely disheartening for everybody on the team, as they have no idea what they’re working on next, whether it will actually end up being shipped, or why they’re suddenly being pulled onto something else. They will shout that they’re “being agile,” but really what they’re doing is failing to have any kind of long-term (or even medium-term) strategy. Refusing to plan a few weeks or months ahead isn’t agile; it’s just chaos.
What isn’t complete chaos?
You shouldn’t confuse a refusal to commit to a lengthy backlog with complete chaos. If teams that stick rigidly to their roadmap or backlog can easily become feature factories, teams that don’t have anything at all in the backlog often fall into complete chaos. But as long as a team knows what problem they’re trying to solve and how they’ll know when they’ve solved it, the team won’t fall into chaos and can feel free to experiment and pivot without the danger of being yanked onto a new initiative with no warning.
What is feeding the beast?
In teams that demand designers and researchers work at the pace of engineers, such team members will likely burn out quickly.
Probably the most common anti-pattern we saw among teams was “feeding the beast.” This anti-pattern is almost certainly the one most likely to burn out designers and researchers.
Feeding the beast happens when teams are incredibly focused on shipping mostly user-facing features that require lots of design work. It’s got all the downsides of feature factories, plus it also demands that designers and researchers work tirelessly to crank out design after design quickly and with little time for reflection so that they never “slow down engineering.”
How do you recognize Feeding the Beast
Designers and researchers are constantly designing things and then quickly moving on to the next feature, while engineers complain if the designs aren’t “done.”
Often engineering refuses to start work on a feature without a full set of final designs, turning the whole thing into another variation of agilefall. Even when they will start without pixel-perfect mockups, they’re always focused on shipping a new feature, and old features are almost never reviewed or refactored, which means there’s very little iteration.
In an agile organization, which one of these is most true?
a. Designers should be embedded in a project team, and never do any work outside of it.
b. Designers can be part of an autonomous project or scrum team but still connect with a central design team.
c. It is more cost-effective for companies to have agile teams borrow designers from the design team as and when they need them.
b. Designers can be part of an autonomous project or scrum team but still connect with a central design team.
An agile team has designers and researchers embedded in it. However, companies may have other design requirements, and it is perfectly okay for designers to sometimes work on things like design operations or cross-team activities. A central design team can help coordinate all design and cross-functional activities, and provide the necessary structure and support system that designers need.
