AGILE METHODOLOGIES

Agile Values


Individuals & interactions outweighs rigid procedures
While good processes and high-tech tools are important, it's the team you work with and the way you collaborate that truly determines success. Effective and efficient communication within the team is far more valuable than the processes they follow or the tools at their disposal.


Working software & prototypes over excessive amounts of documentation

Under the Agile philosophy, the highest priority is getting software into the hands of customers, learning from their feedback, and iterating based on that input. While this emphasizes the importance of shipping, it’s essential to recognize that documentation isn’t inherently negative—as long as it doesn’t become a bottleneck or prevent teams from maintaining the autonomy to pivot and respond to change.


Responding to change over following a plan

Build, measure, and learn. A product roadmap shouldn’t be a static document but a dynamic strategy. Continuously updating the roadmap based on new insights, involving stakeholders, and adapting to change should be a standard operational practice.


Customer collaboration over rigid contracts

Contracts can define what is delivered at the start or end of a project, but this limits the flexibility for teams to remain autonomous and adapt as the project evolves



AGILE METHODOLOGIES

Balanced Team

Designers, engineers, and product managers collaborating closely on a single product to achieve shared goals, outcomes and realize their full potential. This approach emphasizes the importance of a dedicated autonomous team for each product, rather than having one designer/pm juggle multiple projects, which can lead to burnout and compromise quality product thinking.

By allowing the team to focus on collaboration, interaction, and aligned processes, everyone stays in sync, fosters shared ownership, minimizes the need for excessive documentation, and ultimately drives better results.

A balanced team is better suited for businesses that prioritize understanding how features are performing (qualitative) over simply tracking how many features have been delivered (quantitative). This approach also ensures that we consider a comprehensive range of factors when making product decisions together, allowing each discipline to contribute their expertise and removing silos:

Balanced team approach to hiring and scaling

As the company grows, the balanced team should scale with it. For example, if you start with a team of 4 engineers, 1 product manager, and 1 designer, the next "balance" as you hire might be 8 engineers, 2 product managers, and 2 designers. This approach ensures that the workload is distributed effectively, allowing each team to collaborate efficiently and maintain alignment as the team expands.

COLLABORATION DO'S AND DON'TS

When asked about their likes and dislikes in collaborating with each other.


We asked engineers:
What do they enjoy & not enjoy when working with designers?


Engineers like:

  1. Doing design reviews and design sketching workshops with them

  2. They love when designers share user insights and learnings around designs being validated, unvalidated and learnings along the way.

  3. knowing that the design works and is usable by users. they love when designers share insights to ensure what they are building is valuable. They also love when they share positive user feedback, this keeps morale high.

  4. Reinforce that engineers can tell designers anything when it comes to the designs we are building.

  5. Include links of the latest designs and being able to inspect figma design files.

  6. Working within a live design system, communicating the UI patterns (ie: spacing) and sharing style guides.

  7. Tweaking a design to make it easier to implement.

  8. Modeling complexities in a visual way so we can all have a shared understanding and alignment.


Engineers don't like:

  1. Changing the designs in the middle of building them.

  2. Not empathizing with them and not working with them when they push back on a design or technical

    challenge that your design is informing. There are usually other ways to solve a problem with u.i. and

    avoid the "my way or the highway" mentality.

  3. When they work on a design that is outdated or not the right screens.

We asked designers:
What do they enjoy & not enjoy when working with engineers?


Designers like when:

  1. Engineers effectively communicate technical constraints upfront before designing.

  2. Engineers take the time to understand the desired user outcomes. Especially when offering alternative options, don't just decide on what's most easiest to implement.

  3. Engineers care about what's best for the users of our tools. Care about the design and style details and want to make it look as true as possible to the designs/prototype.


Designer don't like it when:

  1. Engineers make design decisions or change designs without informing the designers.


We asked product managers:
What do they enjoy & not enjoy when working with designers?


PM's like:

  1. Designers have a focused set of goals & designs that map to the product strategy and the business goals/initiatives.

  2. Pairing with designers and bouncing ideas of each other.

  3. Pairing on research plans, deciding on who to talk to for research and testing, being together during user interviews, user testing and synthesis.

  4. Designers help to model business complexities or product complexities in a visual way that helps other team members easily understand and align on our plans. It's also helpful because we can spot problems in a more visual manner.

  5. Not waiting for the design to be absolutely perfect when we have engineers ready to review, scope and possible start working on some backend & frontend properties (can start with the wireframes first to build functionality and then add style stories later—be a bit more lean).


PM's don't like it when:

  1. Engineers make design decisions or change designs without informing the designers.


We asked designers:
What do they enjoy & not enjoy when working with PM's?


Designers like:

  1. Product managers advocate for design and users.

  2. Shield designers from meetings so they can focus on work.

  3. Giving design plenty of time to create designs.

  4. Helping designers connect business priority/impact/results to the designs & features.

  5. Gathering metrics to track to help inform how well the designs/features are performing.

  6. Pairing together on designs and sketching together.


Designers don't like it when:

  1. Product managers change the designs without involving design.

  2. Set unrealistic expectations with clients/stakeholders and design has to sacrifice their craft quality to meet delivery needs.

  3. Making a designer feel like they work for them. When they are part of the balanced team. Avoid saying things like "my team" or "my designers."