Everyone in tech has seen the word, repeated ad nauseum as the “silver bullet” for everything from go-to-market timing to quality to product discovery. But like many terms bandied about by those both within and on the periphery of Product Management, the term “iteration” often comes with connotations or meanings attached to it that aren’t really quite right — almost to the point where the word itself begins to lose its meaning and becomes a “cargo cult” phrase without any real “there” there. In this post, I want to explore what I think are five common myths about iteration that if busted will let us renew the meaning of the word and make it something worthwhile in our profession.
1. Iteration Does Not (Always) Mean a “Full Bite of the Sandwich
In many training guides and classrooms, we’re told that the only way to effectively iterate and prove out your assumptions, risks, and hypotheses is to start out by taking a “full bite of the sandwich” — meaning that you’ve built each layer of your system to the extent needed to achieve your goal. This usually means that your UI, business logic, and backend are built out in a way that allows you to go top-to-bottom with your user stories, and that you can extend from there with additional “bites”. Don’t get me wrong here, it’s great when it does mean or when it can mean that you’re building everything from the backend to the frontend for a particular goal statement, but the reality is that unless you’re starting from scratch building a brand new MVP or designing a prototype rather than a product, it’s more often the case that you have to attack the layers of the sandwich in a logical order rather than build part of everything in between. And I’m here to tell you that’s okay. As Product Managers, we often have to sacrifice the “perfect” for the “good” — and this is a common situation in which the choice is obvious. If your teams can succeed in focusing on one layer at a time, and can “stub in” connections to the other layers, you can be successful, and probably have something demonstrable faster than if you tried to force your team to take the whole bite. It’s all about understanding what your teams are capable of and ensuring they are focused on doing what they do best, not what some consultant or trainer thinks some abstraction of a team can or should do.
2. Iteration Does Not Mean Doing The Same Thing Every Time
In organizations that are strongly technically-driven, we often see that iteration is really just a code-word for “moving in fits and spurts”. The fundamental reason why we take iterative steps to deliver product isn’t that two-week iterations are the magic number to optimize developer engagement and maximize utilization of our resources. There is no such magic number, in point of fact. Rather, we iterate in order to learn and we learn in order to improve. Retrospectives aren’t a “pat yourself on the back” discussion when you’ve done a great job, nor are they a “finger pointing and name calling” session when you miss your targets. Demos aren’t there just to show your stakeholders what you’ve done in a passive, boring walkthrough of user stories. Planning Sessions aren’t there to just grab the next 5 stories off the backlog and then go back to your desks. NO! These “ceremonies” are there to encourage us to talk to one another and find new and better ways of doing the things that we have to do every two weeks. These changes could be process, they could be tools, they could be more or fewer meetings — but the entire point of engaging in these agile practices, all built around iterations, is that we talk about what we’ve done, what we’re doing, and what we’re going to do so that we can get better at it.
3. Iteration Does Not Mean That Each Step is Perfect
I’d hope by now that most people have some general conception of the time/quality/resource pyramid (which I’ve discussed in the past) — and iterations are a way of fixing time. And we usually have fixed resources. Which means what do we have left to be flexible on? Simple — Scope or Quality (which in many ways are strongly tied to one another). We can’t expect the first swing at something new to be absolutely perfect — and we have two ways to address that uncertainty: (1) we can spend a lot of time and effort doing research and writing technical specifications that go deep into details that then need to be communicated into the teams that will do the work; or (2) we can have the teams actually doing the work give it a try based on what they know, so that they are empowered to learn and grow on their own, on the job. If we do #1, we’ll delay shipping because of uncertainty that’s being driven out by someone who’s not actually doing the work. If we do #2, we’ll have something to show, test, and play with at the end of the iteration, even if it’s not perfect. And we can then make intelligent choices based on that outcome about what to do next. The idea of “wasted code” is in many ways kind of ridiculous to me — anyone who’s trying to solve a problem with an imperfect set of skills or an imperfect amount of knowledge (also known as “everyone in the world”) is going to learn best by doing and trying and possibly failing than they will by ingesting some technical specification pored over by a Product Manager or Business Analyst. Human beings learn best by doing and trying, not by merely relying on the work of other people.
4. Iteration Does Not Mean You’ll Get There Faster
In fact, especially early on in agile adoptions, it often means the opposite. But we have to understand, just like a race car driver entering a sharp corner, sometimes you do have to slow down momentarily so that you can accelerate more as you round the bend. Iteration is not about the destination — it’s about the journey, and it works best when we’re focused more on the short-term goals that we’re trying to achieve in each iterative step and less on the big vision or goal that we’re shooting for. Iteration allows us the opportunity to have regular checkpoints along that path — to check the weather, assess the road conditions, and generally to see if this is actually a direction we want or need to continue on. It allows us to step aside and kick the tires a bit, make sure that we haven’t picked up too much grime and dirt and dust along the way. It gives us the chance to realize that we’ve over-used an analogy that was already worn thin, and talk more directly. Iteration is not about accelerating our efforts in the short term — it’s about establishing a culture of conversation, review, and experimentation that will allows us to accelerate in the long term and sustain that acceleration over time.
5. Iteration Does Not Mean Randomization
I’ve touched on this topic before (see “Agile” Does Not Mean “Without a Plan”) but it’s important to make sure that while we’re open to changing direction when and where it’s needed, we shouldn’t be doing this every single iteration, nor should we be doing any such changes without a good, data-backed reason. I can’t think of anything that’s more demoralizing to a development team than working really hard to hit an iteration or two of solid work, only to find out that the business “changed its mind” and now has something new to work on, while the old code winds up sitting on a shelf somewhere collecting dust. When we randomize our teams, we kill their engagement — and when we lose team engagement, we’re just asking for trouble. Why should I focus on quality if there’s a good chance what I do won’t ever see the light of day? Why should I document my code if nobody else is ever going to see it? Why am I even writing code when it’s not making it out to the customer? All of these things are product-killing questions that a randomized developer is likely to be asking themselves every single day. We need to have a plan, and we need to support the efforts of our teams to innovate and iterate toward that plan — but we also have to be willing to change those plans when it makes sense to do so, and to share those reasons with the people who are doing the heavy lifting on the development teams. People get frustrated quickly when they aren’t told why plans change — they’ll naturally assume that there really are no reasons if that’s the case. But they’re less likely to become frustrated if we give them the context and keep such changes to a minimum.
