Agile is not the enemy
Issue 223: Misconceptions designers have about the methodology
In 2001, 17 software practitioners wrote The Agile Manifesto—the Code of Hammurabi for software development practices. Agile software development is an iterative and collaborative approach to creating software, emphasizing flexibility, customer feedback, and delivering small, incremental improvements quickly. Today, the practice of agile dominates and is the most common methodology adopted for delivering software. Despite that, many organizations do not run agile well and like many sacred writings, people don’t understand how to practice it.
When I started as a designer working in software, it took several sprints for me to understand the concept and value. Throughout my career as a manager of designers, they also found the methodology. It’s understandable as most design schools and bootcamps teach end-to-end bluesky design work. When they enter the workforce, they are thrown in the Pit of Scrum, blocking engineers and wondering where all the designs are. This is a friendly reminder why design internships that offer real work experience is important.
Let’s debunk the major misconceptions of the agile methodology and how to double down on the parts that are working.
Misconceptions from poor practices
My observation is the majority of poor experiences with agile are derived from poor practices. Many designers have a bad taste in their mouths because they are thrown into a team with half-baked documentation while being asked to be “autonomous.”A Waymo self driving car has no value of being autonomous if it doesn’t have the right insights and ability to make good decisions. This is the same as a Scrum team.
I’ve observed poor practices over my career as a freelancer, consultant, and in-house team member.
1. Debating process and tools over individual interactions
When teams go beyond the Working Agreement and debate over the nuances of process, it becomes ineffective. There is a famous Looney Tunes titled, “"Duck! Rabbit, Duck!" where Bugs Bunny and Daffy Duck go back-and-forth debating which hunting season it is. This is what people on Scrum teams look like when they optimize for process over practice.
The beauty of agile is you can just try things. This is the purpose of continuous improvement and iteration. Don’t get too philosophical and get practical through doing the rituals together.
Allow teams to be Forming, Storming, Norming, and Performing. Work through rituals as a team in the beginning.
2. Verbose documentation over working software
My career dream is to destroy the concept of design handoff. My fundamental belief is that poor or outdated documentation is worst than no documentation. The prototype or demo’ed working software is the artifact in which documents should be inspired by. A vital mistake designers can make is not working closely enough with engineering along the way. I’ve always viewed the best iteration cycle is sketching interactions with engineering early. This allows them to get ahead on the intention, ensuring we’re not over-designing.
Personify the act of, “Show, don’t tell.” Build artifacts such as prototypes or staging demos to cut through the noise of documentation.
3. Lagging indicators over customer touch points
Churn starts way before the renewal period, and a costly mistake companies make is treating the renewal or sales period as the only time to wrap their arms around the customer. As I wear my figurative PLG hat, I would say if you’re relying only on data (especially revenue) come in, you’re too late. Agile promotes the idea of being customer-centric. Part of the iteration process is a feedback loop with customers and users.
I like how many startups are building in the process of having design partners to work with as they build; ensuring the team is making customer-centric decisions. For more established teams, co-design sessions and having a touch point such as concept testing every sprint goes a long way.
4. Being rigid about plans over change management
Many designers have been burned, working on teams that use agile as an excuse to thrash and flail with no plan. The purpose of agile is to respond to changes based on new information to ensure you’re tracking towards the right outcome. Being too rigid is too much of a waterfall methodology when dynamics change.
Be disciplined about running rituals such as retros and user testing—share the learnings. That helps identify specifically on the changes needed and articulate why.
Optimal agile
From time-to-time, I re-read the Agile Manifesto as a reminder. Every time I read the principles, I’m reminded how they read as design-centric principles.
If you take the principles of the Agile Methodology and apply it to design, it is about thoughtful iteration in a human-centered manner. These are the beliefs of Lean UX. Agile is in fact not the enemy, but the ally to design. Where it fails designers is when the rituals and practices aren’t well groomed. It’s not about working through a backlog without collaboration from Product and Engineering. It’s co-ownership of understanding what the customer and business needs, prioritizing together, and getting shared iterations in together.
For designers, we must understand that these rituals are not only not for engineering. We need to show up and contribute.
It is failed through poor habits and behaviors, and by improving that, you’ll unlock the true value of it. Bring prototypes and concepts to get feedback from the team. More-often-than not, you’ll discover your cross-functional team gets excited about the ideas and figure out how to prioritize it. End of sprint demos are the epitome of, “Show, don’t tell.”
The Agile Manifesto is one of the most important documents for software designers. Like a sacred text in our culture, none of the writings and teachings matter if we as humans don’t practice it well. Remember that agile is not the enemy, it is a practice for enablement. Use it and make it yours.
Hyperlinks + notes
A collection of references for this post, updates, and weekly reads.
The design of getting hired by by
, one of my former designers, started a podcast—give it a subscribe
Opportunities
If you’re looking for the inside track on the best opportunities, I highly recommend
, a newsletter by Ben Lang (early Notion). I’ve sent the newsletter to friends on leads on talent who is on the market and most compelling roles in startups.
P.S. I’m offering Proof of Concept’s paid subscription 50% off until December 15, 2024. I have a personal goal on subscribers so if you enjoy the newsletter, please share!
🔥
A whole-hearted “yes!” to everything in this post!
Teams shouldn’t “do” Agile, they should “be” Agile. Minimum viable process that enables the team to effectively work together to deliver customer needs.
As I’ve coached in the past, the only Agile ritual that matters is a good retro. If you have that, then everything else will fall into place.