Wisdom from the trenches: "Agile" isn't for me
On Leaving the Church of Agile
If you’re new here, welcome! This newsletter is about wisdom from the trenches - those practical lessons you learn while building a software company. Please forward to with anyone you know who’s a founder or soon-to-be founder.
Last week I wrote about why I won’t outsource software development again.
This week, I write about what has & hasn’t worked in managing software development - specifically, why I’m not a big fan of Agile & Scrum.
PS: I’ve added a new section to the end… This week’s controversial opinion. Let me know what you think — keep / remove?
Agile tl;dr
You and I know the manifesto for agile software development. Its twelve principles are hard to disagree with. Three examples:
Simplicity--the art of maximizing the amount of work not done--is essential.
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
Cool. In other words, “Frequently ship simple things that customers give a sh*t about.” But something that simple is hard for consultants, certifying organizations, and methodological gurus to sell to big companies for millions of dollars.
So they stepped in and complicated everything:
(If I’d wanted to parody Agile Consultancies, I would have made something very similar to the above picture. They’ve spared me the effort.)
Interested in joining the Church of Agile? Here’s why I’m not a churchgoer…
Agile isn’t for you (yet?)
You’re building a software product from nothing with limited resources. That’s hard.
You also don’t really know what you’re building. You’re learning to fly mid-flight.
You only have a certain amount of time, effort, and focus. Putting your mental energy into implementing one of the Agile Methodologies (e.g., Scrum) is opportunity cost - time you could be focusing on higher-leverage activities.
What’s higher leverage than your software development process? Look upstream - what enters your software development process.
Deciding what should get built - really digging into what matters to customers.
Shaping into simple features - turning “what matters to customers” into “the simplest version of the solution”
Your team has to do these things right first. ONLY THEN is it worthwhile to invest time rigorously optimizing your software development process.
This is only something I’ve learned from “focusing on doing Scrum right” and seeing the result:
Functionality customers don’t care much about
Poorly scoped features (implemented in perfect Agile slices)
Engineering believing that story points are their success metric
Increasing frustration for everyone, as it doesn’t feel like we’re focusing on the right things or making progress on what truly matters
Instead…
You’ve probably guessed it. Focus upstream: Figuring out what customers want and shaping into the simplest version.
The important thing I’ve learned is to involve the entire company upstream, instead of relying on the Product Manager (and maybe designer).
We have weekly prioritization sessions that everyone attends (yes, sales too!), where we make trade-offs. What’s more important to deliver to our customers right now - enabling waitlists or hiring minors?
We then take our priority and ruthlessly simplify and concretize, with multiple iterations that get from “idea” to “implementable feature”.
We involve our engineers in both stages so they understand what the customer needs and the many feature trade-offs we’ve considered. They’re great at coming up with simpler feature versions. Plus, it’s no fun arguing with them when they’ve been brought into the process late and feel like they’re being railroaded with stupid features.
Then… engineering decides how to build. They can use any development process they like as long as it’s process-light, but whatever process they wind up with is better served by them being part of the upstream process than them religiously implementing Scrum!
The rest of the business trusts engineering because they’ve been part of the upstream conversations. Our version of Agile is just saying, “It’s probably fine, ship it!”
The end result: We’re shipping things that are really valuable to our customers, consistently! (And I’d bet we’re truer to the original definition of “agile” than members of the Church of Agile…)
I can’t say it enough: focus upstream. You can’t afford to be an Agile Purist. Not yet… probably not ever.
Controversial opinion of the week
If going against Agile isn’t controversial enough…
The pitch deck needs to go.
Replace it with a two-page word document (one-page, were I a better writer) covering (1) who we are and what we do; (2) why customers will choose us and stay with us; and (3) why this will be a big thing.
Too many startups waste too much time making pretty pitch deck for investors, competitions... Worse, slide deck format makes it hard to realize that your pitch is incoherent.
—Rob
PS. Follow me on twitter if you’re not already!