Recently, I came across several articles on the web that challenged whether Agile methods actually make teams faster. As you can imagine, a lot of provocative views were triggered by these articles. My impression from them was that perhaps some of these experiences were caused by these people not seeing the benefits of Agile after attempting it for a long time or, in some cases, not even knowing what benefits they were supposed to get. And so, many people’s loss of interest manifests itself when they defend illogical-sounding statements like “making the bold claim that ‘Agile means faster’ is a myth”. Imagine how executives in your organization would react when they read such a statement! As Matthew Heusser postulates here, their logical reaction to such a statement should be something like “If agile is not faster, then let’s not do it!”
As we look at this, let’s restate the hypothesis: is Agile supposed to make you faster? It would be too convenient to answer this as: “well, yes and no”: on the “yes” side, you could argue that Agile indeed makes you faster because, if done properly, you’ll minimize waste, automate testing, and get quick feedback to assess if you are doing “the right thing” or not. Others would argue that Agile, as a word, was never meant to mean “faster” (as postulated by dictionary definitions <here>, and so the statement “Agile means faster” is, indeed, a misleading statement. Perhaps a more productive discussion would seek to avoid answering such statements, or attempting to simplify Agile by making statements like that can be interpreted too literally. Statements like “you need to make us agile-fast” should sound ridiculous to mature Agile practitioners, but I can assure you: many agile posers make those statements word-for-word. They, of course, don’t do it intentionally but, as Lizzy Morris explains here: “you just can’t do Agile; you either heed the values and principles or you don’t”.
Still, let’s not dismiss those views by just saying “whoever makes those statements are simply Agile posers who don’t understand what Agile really means”. After all, being faster is a worthwhile goal in the business of developing websites, delivering products, and creating value. Further, properly practicing some Scrum, Lean, or other methods of introspection and feedback should result in achieving your desired outcomes faster, right? Let’s think about the popular show “The Amazing Race”, where it is less about who runs the fastest, nor about who takes the shortcuts, but who finds the most efficient way to get to the finish line and shows up with the best possible result before anyone else. Moreover, since there are many races to run, with constantly changing obstacles, the most efficient runner will likely be the most adaptive, thus the most likely to have repeatable success. After all, people don’t tend to remember the one athlete that won that one rare race that one single time; they remember the one that wins all races in their heyday. That athlete, the consistently successful one, is the one that rises to be considered legendary – the true “winner”.
Let’s establish the anti-pattern, that is, it is not necessarily about “running faster”, or investing in drinking RedBull and Starbucks non-stop during your work day. If so, then what kinds of things can I do to win races repeatedly? Perhaps some of these ideas may help in your journey to reach your outcome “faster”:
1. Assess the real reasons why you are having to say “No” to your customers. If you find yourself, your team, or your organization saying “No” to a lot of opportunities, client requests, or Product Owner requirements, it is likely a signal that some recalibration of your positioning, product, or process is necessary. If you are saying “No” because you have too many bugs to address, then find other correlations to this: is it that testing has become sub-optimal? Or is it that the bugs are indeed “hidden scope requirements” that are getting submitted as bugs? Or maybe is it a lack of domain skills that are keeping you from being well positioned to do the things you are expected to do. All in all, you may find that the symptoms revealed by some of these frequent “No’s” have to do with lack of introspection and adaptation – maybe your team decided that they’ve reached a state where changing many things is no longer necessary. The problem? even if you think you don’t need to change, chances are your customer’s needs will always change. Be mindful that, with time, the “No’s” probably will decrease not because you got better at tolerating or rationalizing the “No” answers, but because customers (who are also not too fond of “No’s”) decide to quit asking you questions altogether. So, the “No’s” will signal to you, in one way or another, where the inefficiencies and waste in your daily activities manifest themselves.
2. Do one thing at a time. Really, just one thing. As authors Gary Keller and Jay Papasan cover well in their book, one of the biggest myths of people that seek high productivity and success is multi-tasking. The truth is: humans and their brains are not designed for multi-tasking many things. In general, the more you attempt to multi-task, the more things you will end up doing in a sub-optimal way. Further, the drawbacks of multi-tasking manifest themselves in all sorts of levels. From a coding perspective, the “Single Responsibility Principle” is a design practice that has been battle-tested for decades: make more methods, classes or programs that do one thing, and the resulting cost and complexity will be less than making one program large and brittle as it pretends to do many things. At a macro-company level, many pundits have lauded the leading edge companies that have focused on doing very few products, but executing their business extremely well around those very few products. So, doing less things concurrently, but doing them more efficiently, will reduce waste by reducing the context-change time that is caused by attempting to multi-task.
3. “Learning” , “balancing”, “responding” and “reacting”. Great athletes, like great performers in non-athletic contexts, have many things in common. Among them is constantly learning how to become better, but that should be obvious by now to you. Or should it? Learning takes hard work, practice, and long-term commitment and patience. And indeed, athletes work extremely hard to get better at their craft, but that doesn’t mean that they train at breakneck speed all the time, until exhaustion. Which is where balance comes in. In our ultimate mission (creating value for our customers, which is ultimately what we all get paid to do), we need to seek a balance where we are not working too obsessively so that the work is filled with anxiety, or working with too little passion, so that the work becomes mundane and tedious. The balance should provide enough learning opportunity to add efficiency to the work without causing anxiety, and enough incentive to push us to try different things while looking forward to making some mistakes (but not repeating the same mistakes. Don’t confuse properly responding to changes, which is rooted in choice, versus reacting to changes, which is ruled by habit (hence the word re-action, indicating an action repeated). With the proper application of learning new techniques, balance your focus, and choosing to respond versus react, you can optimize, remove wasteful process and energy, and increase efficiency.
All these ideas will reduce waste and improve efficiency. In our race, that may mean taking more direct routes, avoiding unproductive trails and loops, and overall building of better habits. Note that none of these “ideas” are written in typical Agile language, like “embrace change”, or “continuous delivery”, or “retrospectives” or “fail fast”. But they are, indeed, both compatible and fundamentally essential to practice and execute Agility well. In fact, one could argue that they help illustrate Agile tenets without using the tired, same Agile phrases or buzzwords. And they are all uniquely focused on doing things more efficiently and with less waste. If you continuously learn how to be more efficient and less wasteful don’t you think that you will create your ideal outcomes “faster”? But perhaps the better question is: since Agile can indeed help you be faster, what am I doing, as I’m implementing Agile, that is not helping me get faster?
Henry Ford once said: “Whether you think you can, or you think you can’t, either way you are right”. Maybe then if your Agile team focuses on being faster, heed the values and principles that are designed to make you faster, and be ready to always adapt if you find more waste and inefficiency, then it would be easy for you to prove that, indeed, Agile can make you faster…as we all would expect it to. The strategy should be easy: by learning about your “No’s”, you measure more of what you are doing. Then, do less multi-tasking, then do more learning, balancing, and more responding versus reacting.
