TLDR: No, it's not lean, it's not agile, and, therefore, it is very expensive, therefore, not good for startups.
I see a lot of startups still use Scrum in their engineering teams. Given that Scrum's public history goes way back to 1995, I'm astounded by the fact that the words "Scrum" and "startup" so often come up in the same sentence with a positive correlation even in 2019, so I decided to write this blog post.
What is Agile?
Let's start with the question: "What is Agile?". In a second, you'll see why we need to start with this question and not with something else.
Agile is an adjective, not a noun. So it's not a process, framework, technique or methodology. But it can be a descriptor for them. It's a very important distinction — you can't do Agile, but your processes are either agile or not.
To tell whether a process is Agile or not you need to assess if it is aligned with the values in the Agile Manifesto and conforms to the 12 Principles of Agile Manifesto. There you go, now you can quantify the extent to which a process is Agile in percentage terms.
What is Scrum in Agile software development?
Agile Scrum History
In 1986 Hirotaka Takeuchi and Ikujiro Nonaka introduced the term scrum in the context of product development in their Harvard Business Review article, The New New Product Development Game, which served as an inspiration to Scrum framework. At the heart of Scrum Framework is the antagonism to Waterfall as Waterfall is believed to be that sequential approach where you plan everything extremely hard and for too long, and then just follow the plan no matter what happens. And so in the end, you end up with a thing that is either half-assed or nobody needs it (or both lol!).
Scrum, on the other hand, intends to do the thing in iterations, called Sprints, to accommodate the feedback from the world and new knowledge, so you always end up with a whole-assed thing, hopefully. Anyhow, the intention is to reduce waste while delivering value or building a startup, i.e. maximize ROI.
From the execution point of view, there are two full-time roles running the ceremonies (yes, they are literally called "ceremonies") which are essentially daily meetings to catch up (stand-ups), the Sprint planning (another meeting to decide what to work on next), and the retrospectives (a group therapy to mourn the unmet goals). Scrum has also various kinds of rules like not accepting requirements changes in the middle of a Sprint, cancelling and re-planning sprints, creating tickets during retrospectives, etc etc. You don't get a Scrum Master for no reason — that stuff is intricate!
Founders of Scrum: ScrumAlliance.org® vs Scrum.org™
In 2002, Ken Schwaber with others founded the Scrum Alliance® and set up the Certified Scrum® accreditation series. Schwaber left the Scrum Alliance® in late 2009 and founded Scrum.org™ which oversees the parallel Professional Scrum™ accreditation series.
Which begs two questions:
- Does a Professional Scrum Master™ certificate invalidate a Certified Scrum Master® certificate as Ken Schwaber is the Ultimate Scrum Master™ and he left Scrum Alliance®, and that must have taken away some certifiable credibility with him?
- If a daily scrum is a ceremony, can MC Hammer be a Scrum Master™ because he is a master of ceremonies?
Is Scrum Agile?
To answer this question, we need more than just assess Scrum against the 12 Principles of Agile Manifesto. We need to provide some context to software development as an activity. Why do we build stuff? How do we build a company? Do we need to build stuff to build a company?
How to startup?
Many people believe that building a startup is relentlessly pitching investors in tight spaces like elevators or shark tanks, and developing a product (often in secrecy). Although both things do happen in startups, none of them is the ultimate goal. The goal of a startup is to verify a business hypothesis, not to build a product. It is to validate an awful lot of business hypotheses until a repeatable and scalable business model emerges, and the startup transforms into a business. Simply speaking, a startup founder is either not sure what exactly she needs to build to solve a customer's problem or whether the problem she is seeking to resolve even exists! Developing a product is the most expensive and inefficient way to verify that. Ideally, the product should reflect only confirmed hypotheses, therefore I would argue, that the product development methodology is not essential to the startup success, thus it cannot dictate the rhythm in the startup.
Building a startup does not mean writing software!
Dale Sakai, a successful CEO, strategic planning expert, and co-founder of the startup Obo, put it this way:
If you look back at different industries, the company that has ended up in the top slot with the most market share is generally not the company with the best technology, but the one that had the best marketing.
Source: Beyond Product — by Jill Soley and Todd Wilms
The direct implication is that no matter how short your sprints are — they always will be too long for a startup. I remember in 2010 it was common to have two-months long sprints. These days it's more common to have two weeks sprints but that's still too long for a lean startup! Imagine, if you were allowed to use steering wheel only every two minutes — that's how two weeks feel like on the early days of a startup. Sure, Scrum has a workaround to cancel a sprint, but this comes with a cost — you need to plan another one, and sure as hell, there will be a lengthy retrospective, that's why almost nobody cancels sprints but puts more stuff in the product backlog in a naive attempt to catch up in the following sprint. This is often how a development team ends up building something that nobody needs instead of actually building MVP.
Lean as bacon
Among the core pillars of Lean Methodology, there is a modest concept of maximizing value and minimizing waste. Whatever is not creating value for customers is considered waste. While Toyota Way purists can intellectualize about how to identify value, startup founders have a very tangible metric to look at — cash runway. It is not a secret that one of the leading expenses for startups and small businesses is payroll. With Scrum, a startup founder is paying for a full-time Scrum Master and a full-time Product Owner and is also paying for 20 hours on average per month of sprint planning, sprint review, sprint retrospective which aggregates into 100 person-hours per month for a typical development team of five. This number does include Scrum Master and a Product Owner as full-time jobs. Even if we replace a Product Owner with its contemporary counterpart of a Product Manager, we still have 40 hours of a Scrum Master. And we either have to make somebody else perform the function of a Scrum Master (who doesn't have a conflict of interest) or not have it at all — you can't hire a part-time Scrum Master, it makes even less sense than a full-time one. But then, is this Scrum or a Scrum-inspired process?
In short, Scrum ceremonies would cost a startup founder more than twenty thousand dollars per month minimum (including Scrum master and Product owner) and have zero return — customers do not value all intricacies of nuanced Scrum ceremonies. If that's a lean approach — then it's surprisingly very cash saturated.
Also, all these ceremonies directly contradict two out of four values in the Agile Manifesto:
- Individuals and interactions over processes and tools
- Responding to change over following a plan
P.S. I know there is "lean bacon" which is not real bacon because it's pork loin instead of pork belly. I'm not saying it tastes bad or inferior — it's just not bacon. Similarly to bacon, Scrum is not lean, however unlike bacon or lean bacon Scrum doesn't leave a pleasant aftertaste.
Points, badges, belts and leaderboards
As I mentioned, Scrum practitioners do call their meetings — ceremonies. Scrum embeds religious, cult-like features and vocabulary in itself right out of the box reinforcing Core Drive #1: Epic Meaning as opposed to Six Sigma which focuses on badges and leaderboards in the form of a hierarchy of belts implementing Core Drive #2: Development and Accomplishment.
I believe that the usage of the words Ceremony and Master was a genius marketing move. Think about it for a second. It's not a meeting — it's a ceremony — implying hidden knowledge, wisdom and mystery, only a Master can lead the team and adhere to the word of Scrum. And it's flattering to be called — Master.
Sir Lord Admiral General Scrum Master Aladeen — sounds a little overboard but definitely, more fabulous than just a meeting facilitator! To become a Master, you need to pass the initiation ceremony and obtain a certificate.
Scrum Alternative
My good friend used to say: "If you are critiquing something — suggest a better alternative". Indeed, a very good advice that I've been running with ever since. So I'm not going to leave you hanging, and here is my suggestion: Read the Agile Manifesto again, then start with as little process as possible because it's easy to introduce a process and very hard to change it, so if there is no valid common cause to have a process — don't even introduce it. The most lightweight, yet extremely efficient, process I would recommend is Kanban.
What is Kanban
Kanban is a scheduling system that focuses on avoiding overcapacity — it's when you have more stuff than you can handle and there is too much work in progress. In other words, Kanban is here to prevent being overwhelmed, overloaded and multitasking. Kanban is more than just boards with cards. It's a production system. We've embedded multiple mechanisms and safeguards of Kanban in todo.space to help you create a highly productive, collaborative and stress-free environment. Ditch Scrum. Start Kanban with todo.space or a spreadsheet or even a physical whiteboard — the tool doesn't matter that much as long as you contain your WIP and don't have a process where it's not needed.