In the pursuit of Agility, not Agile: How to Build the Right Features
Interview with Henry Latham, founder of Scribe, Author of ‘Why Your Startup is Failing’
While almost everyone understands the vocabulary of Agile and grasps how to apply some of its ceremonies, such as running a weekly sprint or holding a daily stand-up to align at the start of each day, most teams fundamentally misunderstand what agile really is — and how it should be applied.
Henry Latham spent 7 years working across different design & product leadership roles studying the factors involved in startup success & failure.
He now applies that knowledge in his own company, Scribe, a journaling application his team has bootstrapped to profitability within 12 months, as well as with clients, helping them define a product vision, strategy & process of execution to help them achieve success & longevity.
We welcomed Henry to our Berlin center to discuss how teams can overcome the common mistakes that occur when teams apply Agile, and he was kind enough to ask a few related follow-up questions after the event.
BCGDV: What common mistakes do teams make when applying Agile?
Henry Latham: Firstly, don’t allow yourself — or your team — to become too attached to any idea. All of us have a tendency to attach our ego to each idea — to see it as a poor reflection on ourselves and our capabilities if something doesn’t work out — rather than conceiving of and validating an idea in a detached, purely rational way. Furthermore, particularly in the high-pressure environment of a startup, we very easily fall victim to the sunk-cost bias, investing more time into an idea or new feature simply because we have already committed time to working on it. A bad idea is a bad idea. As soon as you have data to support this fact, any more time & resources committed to the bad idea is a dangerous waste.
Secondly, many developers unfortunately work in an environment where the incentives are entirely wrong. Product managers tend to push teams to simply deliver something on time, rather than, instead, pushing their team to simply deliver the right thing. “More” does not equate “better”.
Thirdly, all teams have a limited focus. When we focus on constantly pursuing more velocity (i.e. getting things done faster), we usually forget to focus — or re-focus — our efforts on delivering high-impact features (i.e. getting the right things done). Busying ourselves, obsessing over hitting arbitrary estimations, building features that are low, zero or negative impact will only mean we build a mediocre product doomed to fail.
Finally, Agile does not mean sprint planning, retrospectives and story points. These are rituals. If they are not applied within a framework focused on testing out an assumption through experimentation, measuring the results and learning from our experimentation, then they can in fact be hugely negative: Giving teams a false confidence that they are approaching their product process effectively when all they are in fact doing is obsessing over arbitrary estimation and over-organised, over-documented features that won’t have much of an impact.
How can these mistakes be overcome?
Unfortunately, there is no easy answer. In my opinion, based on my experience advising other startups and experimenting with different approaches to building product in my own business, it requires understanding what I call the “product iceberg.”
On the surface, the tip of the iceberg, being truly agile — and building product effectively — requires applying a Lean Startup approach to product development. At its core, this means:
- Defining a clear vision for your product and core strategy to help you move towards achieving that vision.
- Defining specific assumptions you need to validate in order to move towards achieving your strategy, represented by the often misused concept of an MVP (a Minimal Viable Product — such as a new product or product feature — designed to validate that you are building something that users actually want to use and ideally pay for); measuring the results of your assumption through quantitative (e.g. analytics data) and qualitative (e.g. user interviews or user testing) data after each MVP is launched; reviewing the learnings when you have results to determine what you should build next.
However, I fundamentally believe — and this lies at the core of my book — that the more important factors involved in success as a product team are what lie under the surface (the bulk of the iceberg) in terms of how we approach our work, and specifically decision-making, as a product team. I distil this down to three core principles I’ve identified in product literature and from my own experience:
- To be robust, so we are better able to persevere through difficulty and failures.
- To be more mindful, so we are better able to see things clearly and rationally.
- To be better able to focus on what is truly important — what is essential — in making decisions
I delve into these 3 principles — what they mean and how to actually cultivate them — in the book, drawing a lot on my own experience, as well as schools of thought such as Zen Buddhism and Ancient Greek Stoicism.
What are the attributes you’d associate with a great software team?
I suppose the three principles I outlined above, but to be more succinct, you can also distil this down to one thing: Psychological safety.
A few years ago, Google set out on a quest to discover what makes a team effective, launching a study codenamed Project Aristotle. What they discovered is that, in the words of the researchers, “what really mattered was less about who is on the team, and more about how the team worked together.”
And what made teams work effectively together? Trust. Specifically, an individual’s perception of taking a risk & how that risk will be judged by the team — often called psychological safety. To quote again from Project Aristotle: “In a team with high psychological safety, teammates feel safe to take risks around their team members. They feel confident that no one on the team will embarrass or punish anyone else for admitting a mistake, asking a question, or offering a new idea.”
A few years ago, Google set out on a quest to discover what makes a team effective, launching a study codenamed Project Aristotle. What they discovered is that, in the words of the researchers, “what really mattered was less about who is on the team, and more about how the team worked together.”
Great decision-making, in the context of an early-stage startup, essentially constitutes the ability to not only come up with a great idea (defined as something that will potentially be high-impact), but, also, when that idea represents a risk (as it almost always does), to feel able to actually execute on that idea, with the support of the team.
Great decision-making, therefore, not only comes from focusing on the foundations of ourselves — as individuals — in terms of creating fertile mental ground for good idea to emerge.
Great decision-making also requires us, in the context of a team, to address the very different proposition of creating psychological safety to voice and execute upon these ideas.
It requires collaboration, consensus, negotiation — bravely putting our opinion forward even when it goes against the team’s shared beliefs.
Pushing our team to make better decisions requires changing its very thoughts, beliefs and actions about what it means to do work: What a productive day means, what collaboration means, what our very definition of success is.
In short, making great decisions as a team requires us to critically examine — and, usually, radically change — our team culture.
How much of a role should engineering teams take in defining product?
Ideally, teams would be entirely cross-functional, formed into squads specifically focused on one clear business goal, such as increasing retention or reducing the drop-off rate during onboarding.
In reality, however, far too many teams are divided by functionality, into “engineering teams” or “design teams.” For me, this doesn’t make sense — and a lot of the product literature would back me up on this — as it leads to a lack of accountability that does not incentivize teams to closely examine and learn from the work they deliver.
This is really the core problem in most startups: Executives come in with some grand idea, ask engineering to build it, complain when it takes too long to build or doesn’t deliver results, yet never stop to actually review the results themselves.
Instead, far too many leaders simply push their teams to get more features delivered, rather than stopping to learn what did — and did not — work and iterate based on those learnings.
How can you make sure that Agile is leveraged for business success and product effectiveness, used in the service of building the right features, rather than production for production’s sake?
This really depends on who you are within your company and what is realistic for you to achieve.
If you are a founder or very senior leader, particularly in an early-stage startup, you should be able to shift your team away from a focus on velocity (i.e. getting as much done as quickly as possible) to outcomes (i.e. getting the right things done) within a few weeks of iteration, using a simple Kanban board and process of defining experiments to answer a core assumption, measuring the outcome of that experiment and learning from the results to inform your next product idea.
However, if you are an engineer in a large company — particularly a large corporate company — and you are working in an engineering team with no input into what turns up on your desk (or in your backlog), your options are, unfortunately somewhat limited (sorry for the bad news!)
Not to despair, however. You just need to demonstrate with clear, concrete data to your leadership team that what you are working on is not delivering any value to your customers.
This can be done by really pushing — or even simply taking the initiative yourself — to track the results of the next feature you work on.
If you can turn to your product manager a week after it is launched and demonstrate that the feature did not impact — or even negatively affected — your user experience with some clear metric, then this fact starts to become uncomfortable to avoid.
Clearly there is also an issue here with trust & accountability — which is why psychological safety is so integral to team culture — as you want to get your manager on your side, rather than put their failings (failings as they may be perceived by leadership) under a spotlight that may make them feel threatened.
If you could give one tip to someone responsible for a software team, what would it be?
I could talk about building a cultural of psychological safety and reading up on The Lean Startup and other product books, but the most simple piece of advice I would give is simply: Be kind.
If you are kind to people, treat them like adults, recognise they have the same hopes and fears as you, as well as a life outside of work, people tend to give you a lot of respect.
Don’t do things like telling someone off for turning up late or not delivering something on time. You’re just going to upset them and they’ll find a way to get back at you — and most people don’t do these things deliberately.
Interested in working with us at BCGDV? Want to find out more? See our current vacancies.
Find us on Twitter @DV_Engineering.
You can find more of Henry Latham’s thoughts on his Medium page.
