Our minds get conditioned by the definitions we give to things around us. And when the definitions are poked or prodded to change, if we wish, old mindsets can dramatically shift. So the key to new learning is to be open to redefining! That is what AGILE can make possible when it comes to Startups - when it comes to things like rapid prototyping or pivoting on the idea or prioritising effort. Some people would be familiar with the terms - especially those connected with the world of software – like agile development, agile software, and agile methodology.
What is Agile?
Agile began as a method of software development where requirements (specifications) as well as development (efforts) were iteratively and collaboratively handled by engineering and product management teams, together. This contrasted from the conventional method of software development (also called the Waterfall method), where the specifications were laid out once at the beginning, and the development process thereafter was done in isolation, with no further discussions or inputs allowed into the process - and this conventional method had a history of bungled and unsuccessful projects for the longest time.
The backstory of the birth of Agile is quite interesting. Way back in 2001, seventeen experienced software developers got together to ski, relax, eat, and share ideas in the mountains of Utah, USA. And they all agreed that a change was needed in the way software projects were being executed. Amongst them were the two Agile pioneers Alistair Cockburn and Ken Schwaber. Some of the others also brought their own well-defined methods to the table, including Extreme Programming (XP), SCRUM and Crystal, all of which are today well-recognised Agile tools.
The meeting culminated in what is now famously called the Agile Software Development Manifesto (read more here https://agilemanifesto.org/) signed by all participants, in response to the need for an alternative to the heavyweight, documentation-driven software development processes of the time. This group of independent thinkers named themselves The Agile Alliance.
To the credit of the solid foundational thinking of the Agile Alliance, two decades later, very little has changed in terms of the definitions or relevance of Agile. And it is now de rigueur in the world of technology to do Agile. As software started getting into so much of our daily lives – gadgets, portals, devices…, Agile was just what the doctor ordered for, in the method of making software. Here is a widely circulated graphic that illustrates and contrasts between Agile and the conventional, old methods, and more tellingly the outcomes. As you might be thinking, the consequence of a Waterfall method going off-track midway can be far more distressing!
Why is Agile relevant for Startups?
After experiencing Agile (in actual implementation terms), and having considered the applicability of Agile while mentoring several startups, I am of the view that Agile is a highly intuitive and remarkably simple project management framework to use for developing ANY new product for ANY startup or new product development effort.
The whole MVP development exercise in startups is rooted in Agile principles. Agile seems to be quite universal in its applicability, and any startup or entrepreneur is well advised to use it without a second thought, as a bedrock to manage the process and method of building their value proposition. I would even argue that in the absence of such a powerful method, it is quite possible to get off-tracked or defocused in the journey!
How to do Agile?
The good thing about Agile is its simplicity. To get started, you just need to know and act on a couple of key terms (let’s call it the Agile vocabulary), namely Agile Project Management
ARTIFACTS and EVENTS
Let's begin with the first term, ARTIFACTS. Any project has to be transparent and measurable in order to gauge progress. So Agile project teams use the following artifacts (in other words, deliverables), to track progress in any project.
Product vision statement - An elevator pitch to describe what the product vision or strategy is, and what problem broadly you intend to solve – it articulates the goals for the product.
Product roadmap - The product roadmap is a high-level view of the requirements to be built into the product to achieve its vision. It also helps the team to outline a broad timeframe for developing and releasing those requirements.
Product backlog - The full list of features and functionalities to be developed for the project, ordered by priority. When you have listed your first requirement, you have a product backlog. And this backlog keeps getting incremented throughout the project.
Release plan - A high-level timetable for the release of a set of requirements (which means a version of the product).
Sprint backlog - The goal, user stories (similar to use cases), and tasks associated with the current Sprint (a term we will define as part of the EVENTS below)
Increment - The working product functionality, demonstrated to stakeholders at the end of the sprint, which is potentially usable by/shippable to the customer.
Now let us consider the second term, EVENTS. You would agree that most projects get measured by stages of execution. Agile projects include the following recurring events through the product development, as follows.
Project planning - This is the initial plan for your project, which includes creating a product vision statement and a product roadmap.
Release planning - Planning the set of product features to release and identifying a target product launch date around which the team works. In Agile, you plan one release at a time.
Sprint - This is a key concept in Agile. It is a short cycle of development, in which the team creates a usable/shippable product functionality. Sprints could last between one and four weeks. Sprints should be of the same length throughout the project, which keeps the pace intact for teams to plan work more accurately based on their past performance.
Sprint planning - A meeting at the beginning of each sprint where the project team commits to a sprint goal. They also identify the requirements that support this goal and will be part of the sprint, and the individual tasks it will take to complete each requirement.
Daily scrum/meeting - Another key Agile concept, this is a daily 15-minute coordination and synchronization meeting, where team members state what they completed the day before, what they will complete on the current day, and whether they have any roadblocks.
Sprint review - A meeting at the end of each sprint, where the project team involved demonstrates the working product functionality to the product owner and other stakeholders. Keeping this review in perspective, the product owner uses new inputs and feedback, and appends/updates the product backlog.
Sprint retrospective - A meeting at the end of each sprint where the team reviews their processes, discussing what went well, what could change, and makes changes if needed for the next sprint.
Notice how the Sprint review and retrospective are cleverly designed to separate out the product-related discussions and debates from the process and the methods used.
If you have come thus far in this note, reading with interest, I am sure you have begun to get a hang of Agile already. You could get started with Agile by just acting on these two terms - Artifacts and Events. If you are a Startup - even without a big team, my recommendation to you is to adopt Agile. It will help bring discipline, visibility, measurement and stability to your product development effort.
There are plenty of learning resources available online for those interested to explore. I started by reading up Agile for Dummies (what else!), versions of which have actually been written by several authors and companies (including IBM and Adobe) adapting Agile for their own product development needs.