The Agile Mindset
Hey guys, It’s Jenn from the Goodpatch Product Team!
We are going to discuss one of our many processes within our team. You probably know it; hate it or love it but it’s the hottest trend in business output to date: Agile. But what exactly is it? Where did it come from? Is it useful for my team? The Goodpatch Product Division can help you figure out all this and more!
What is Agile?
Agile is a system that teams and groups use in order to release a product in small increments rather than in a large release. It was founded by a group of developers who saw flaws in their team working inside a waterfall methodology. They met together and created the Agile Manifesto to align their working process and the core of how they want to build and maintain software output:
The Agile Manifesto
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a planThat was in 2001. Now, more than ever, in-house teams are implementing Agile into their everyday workflow to create products faster and to integrate quicker with smaller teams. Agile is the way we work, but let us show you our process!
Overview of the Agile Process
We use a Scrum process mixed with a Kanban board with a Scrum in order to visualize our work and also keep structured in an iteration: You can learn about the differences at Atlassian.
Some Useful Definitions
User Story: A small unit of work broken down into a story: As a type of user, I want function so that I value
Epic: A body of tasks and user storiesSprintA period of time that the team will complete work
Backlog: A prioritized list of work for the development team that is derived from the roadmap and its requirements.
Story Points: Story points rate the effort of work in a Fibonacci-like format: 0, 0.5, 1, 2, 3, 5, 8, 13, etc. As a design team, we use t-shirt sizing to weigh the points for our stories (S, M, L, XL, XXL, ?)
Here’s how it starts: our team will lay out the features we want to work on based on a strategic plan from the business that prioritizes the backlog of work for the team. This backlog is normally informed by design research/business needs that are created before the project’s initial kickoff.
We then break down tasks and requirements into user stories that benefit an epic or larger piece of the product based on the features laid out. This creates units of work that are spread over 1–2 week sprints that the team will complete. These stories are weighted by story points that inform the team what we can work on, and what needs to go back into the backlog. We put these stories on a Kanban board and give daily stand-ups to share our progress of work through the week.
At the end of the sprint, we give a demo of the work we’ve completed during the sprint to the whole team, and decide if we release, or make changes. After the demo, we go through a Retrospective to share our successes and pain points from the previous sprint. Then we will start Sprint Planning to see what we can work on next from the backlog environment and the process starts all over.
Being Agile
But ok, so now we can see what Agile is, what does it mean to ‘Be Agile’?
Scrum was something that our team was doing successfully. We were doing 2-week sprints, daily stand-ups, refinements, the whole process. But in each two-week sprint, we weren’t making a ton of progress on our work. Our total points completed were low, and for one reason or another, our team wasn’t completing tasks even if we would estimate correctly. What was going wrong?
Once I joined the team, I was able to see the problems based on my previous experience in an agile environment. We were Doing Agile but not Being Agile. Decisions weren’t based on user needs and our roadmap wasn’t aligned to the goals of the user (plus it didn’t exist). These decisions were also hard to make because too many people were trying to decide on one thing and the team felt weighed down by this decision making process. By moving slowly it caused the team to become bottlenecked with tasks which meant features pushed back.
We want designers to feel free to explore all ideas and to have the creative freedom to up with the best solution in these complex spaces, not the best-detailed design.
I was able to work with the design team to help restructure our Kanban board so we could help the team organize the tasks and align them with user stories. We structured meetings to allow for more organization and fewer distractions. We were able to move quickly, complete more stories, have a healthy backlog, and allow the team to have autonomy in the process. We’re still trying to find the balance between team size and structure in order to move faster in our big team.
Being agile isn’t just a process, it’s a mindset to continuously improve and learn from mistakes quickly. The sprints are there to allow us to rapidly learn from our oversights and improve for the next time. Scrum and Kanbans are just systems to help inform the Agile ideology.
Design + Agile
Here’s where it gets messy guys… A lot of designers don’t use Agile and feel limited by Agile’s strict rules within the design process. I agree; Agile and Design don’t mix very well if handled by someone who dismisses the value of design. A pure Agile platform causes designers to become production workhorses and values output over real problem-solving.
The real trick to Design and Agile is to make sure the design process informs the Agile sprints and features. We use Agile as a way to be transparent with our team but the way we output work and delivery is not as straightforward as the development team. Here is the Goodpatch Design Process:
In the Problem Space, we are finding user pain points and needs to build new features or fix the current ones. We then ideate, test, build those feature, and then share them with our engineers to add into the design sprint. This normally happens during the Build Phase within the Solution Space. Depending on the complexity, we will share these ideas earlier to get feedback and to make sure we are going in the right direction. We use two weeks sprints to create and build detailed screens to keep ourselves on task and move designs quickly.
What we don’t do is try to force Agile into every step of the process, especially at the beginning phases of Feature ideation. During the Problem and the beginning of the Solution phase, we tend to use the sprints as more of a progress report and less to show output because it restrains design thinking. DesignBetter.co wrote a great book on DesignOps that embodies this idea of Discovery and Understanding. We want designers to feel free to explore all ideas and to have the creative freedom to up with the best solution in these complex spaces, not the best-detailed design.
Takeaways
I am not an Agile expert by any means, but I’ve seen how frameworks of Agile can make or break a system.
Agile works really well for big projects and in-house products. Complicated systems can be organized out with the help of Agile and Scrum. But my personal opinion is if you want to design something rapidly and hone in on the methodology of Agile, leave the frameworks at home. Google’s Five Day Sprint is a great example of working fast to build and testing something in the real world.
The most important takeaway that I’ve seen from working in an Agile environment for the last year is that value design first and foremost. If you are working in an environment where design is not valued at the top, then be agile: change how you are working and iterate to make it better.
If you have any additional thoughts or resources for Agile workflows, share them in the comments below! 👇
Side Note: This is my first published article everrr so please use your words kindly ❤️
Resources:
https://www.designbetter.co/designops-handbook/introducing-designops
https://www.designbetter.co/principles-of-product-design/break-black-box
https://www.atlassian.com/agile
https://www.atlassian.com/agile/project-management/user-stories
https://www.intercom.com/blog/there-is-no-hand-off-product-design/
