As with most endeavors, good planning gets you only halfway to success. In IT, product quality largely depends on quality of planning, which is why the Software Development Life Cycle (SDLC) is so important. An SDLС is a term that refers to the way the development process is built, the layout of the development, and the definition of tasks for every team member. The SDLC is a framework for the planning, control, creation, testing, and delivery of software. It helps to know where the team stands at any given time and what resources are necessary for the team to work at every phase.
Any software development life cycle consists of several phases, including requirements gathering and analysis, design, coding, testing, deployment, and maintenance. Depending on how the team wishes to proceed through these phases, several SDLC methodologies can be used.
The methodology that’s proven to be the most efficient for startups is called the Agile SDLC model. Being agile basically means being able to adapt to changes, whenever it’s required. Thanks to this methodology, product teams can adapt to market developments and pivot with whatever limited resources are available to them at the time. Being a lean methodology, it helps reduce or completely eliminate wasteful and meaningless activities.
In fact, agile software development not only eliminates unnecessary action, it also intentionally avoids strict proscription, as it values people, communication, new information, and product quality over blindly following a plan.
The Agile SDLC model is based on two approaches – Iterative & Incremental. Incremental development means you create something piece by piece. Software is developed in small chunks, adding functionality at each step. This approach allows you to get a minimum viable product (MVP) pretty early in the development process. However, there’s one problem with working this way – your product will not be done until the last piece of working functionality is in place. Iterative product development, on the other hand, means creating something through refinements. Basically, you make a simple draft version of the product that will do the job it’s intended to do, and you go from there – refining functions and different specs. Combined, the approach helps the development team work on the bigger picture, and let them make changes to the product more easily.
For example, take the Waterfall model. It’s probably the oldest one, and it seems pretty solid, but it doesn’t fit the way a startup works. Since you only go from phase to phase in a strict order, and there’s literally no way to go back, it doesn’t provide a startup the freedom it needs to experiment in conditions of uncertainty. The V model is basically the same as Waterfall, except the product is tested at the end of every stage. However, it’s quite difficult to go back a step to fix or add something, which only works for products with little to no new features. We’ve already mentioned the Iterative approach, but used alone, it may suck you into an endless cycle of repeated refinements that drain the limited resources of a startup. The Spiral model combines the structure of a Waterfall model and the repetitiveness of the Iterative, which also means that there’s a danger of losing time and money if the product being developed is new and has a lot of unknown characteristics. Which leaves startups with the most flexible and result-oriented model – the Agile SDLC.
As software development evolved, a group of independent thinkers in software development realized that all those traditional development methods just weren’t enough in a world full of innovative technology that requires original thinking. In early 2001, the Agile Software Development Manifesto emerged:
Choosing the Agile SDLC model alone is not the end of the story. Depending on the project and the company, you choose frameworks within the methodology. For example, Scrum and Kanban are two types of an agile software development methodology. They both allow complex tasks to be broken down into smaller parts to be completed efficiently by means of continual improvement and work optimization. Both place high value on a transparent and super-clear workflow.
However, there are differences too. Scrum focuses on distinct scheduling and has distinct roles for each project – Product Owner, a Scrum Master, and Team Members. If you’re looking to change your company’s methodology to Agile, Scrum may be your weapon of choice, as it’s still quite regulated and won’t shake up the whole system.
On Kanban, there are neither required time boxes or iterations, or set roles – they evolve with the needs of the project and the organization. This framework may be a bit too loose for some companies, but if you feel you need to improve your processes, try Kanban – it just might help you see your tasks from an entirely new perspective.
Wherever the needs of your project lead you, all the agile frameworks flow from the principles of the Agile Manifesto mentioned above.
Individuals and interactions over processes and tools
By choosing individuals and interactions over processes and tools, the software development avant garde chose to create a work environment that truly values the people working on a project and the communication between and among them.
Working software over comprehensive documentation
They also put a good result over bureaucratic requirements – it’s not worth having sophisticated and neatly done documentation if the software doesn’t work, right?
Customer collaboration over contract negotiation
Similarly, they choose a good understanding of the customer and knowing his wishes, over contracts and other papers. A progressive industry such as IT shouldn’t be held back by paperwork.
Responding to change over following a plan
The most important quality of the Agile SDLC is, of course, the ability to respond to change quickly and painlessly, with as little effort and financial loss as possible. Without a doubt, plans are great for working efficiently, but everyone has to understand that if the initial plan doesn’t work or causes the product to be worse than it should be, the plan should be changed.
Agile vs Waterfall
Earlier on, we mentioned the Waterfall model as one of the first methodologies for software development. It’s a bit old-school, but it’s still valid for many companies.
Let’s take a closer look at it. Waterfall goes through such phases as Conception, Initiation, Analysis, Design, Construction, Testing, Production/Implementation, and Maintenance like a metro train goes from station to station. Of course, it’s practical for fixing bugs, since they can be discovered and removed at earlier stages, rather than being found after the product is done, which would mean you’d have to start everything over again. What makes this method less attractive is the need for detailed documentation so that the process doesn’t depend on one particular person; if someone is replaced, the newbie can see where the process stands at any given time. For startups that are still establishing their workflow, or work on new software from scratch, it can be tricky to follow these steps, as there too many unknown and unpredictable elements to be taken into account. Thus, Waterfall requires that there be little to no uncertainty in the development process.
Like Waterfall, the Agile SDLC model has pros and cons as well. Developers needed a methodology that would accommodate change and the need for faster software development – and from this need the Agile Manifesto arose, as mentioned above.
Unlike the Waterfall model, developers don’t go from one phase to the other. They decide in the beginning of the time box what can be accomplished in the set timeframe. At the end of the iteration, they plan to have a working piece of software that can be installed and tested. Thus, developers can adapt to the needs of the product and get customer validation along the way, which is very important to reaching the best possible result in the shortest amount of time. Moreover, developers feel valued, as they are always working on something that really matters and reflects the needs of the time.
The flexibility of this approach also allows you to get rid of tumultuous up-front work – there used to be times when product requirement documents forecasted what would be needed in 6 months, and outlined a universal contract detailing nearly every aspect of a product’s future design. And we already know that this goes against everything Agile SDLC stands for.
After accepting change, the second biggest virtue of Agile is accepting uncertainty. It’s totally okay to not know everything about the product at the very beginning of development. Agile accepts that the team will discover more information as they go on. A feature no longer meets customer needs? No problem – with Agile SDLC, it’s easy to change direction.
In order to be able to accept change and uncertainty, Agile SDLC adapted fast review cycles. Most Agile practices either use time boxes or control the amount of work done (Scrum and Kanban, as we mentioned above). Afterwards, the work done is reviewed with customers or customer proxies.
However, as progressive as Agile is, development projects may take up more time and require a higher level of commitment, since there’s no set number of phases to go through. This may be caused by a lack of understanding of the Agile philosophy outlined in the manifesto. Most organizations want to be agile, but don’t necessarily invest the time, money, and effort to change, to educate management, to really get to the point. Sometimes, trying to implement “agile” ideas taken out of context has bad and destructive consequences.
Since Agile is a flexible way to work, loopholes in management can cause bad behavior or lack of discipline in the team, which will inevitably affect results. And often, the team blames the bad outcome on the Agile SDLC model itself rather than on dysfunctional choices the team made in the process.
Unfortunately, not every organization and not every corporate culture is ready to become Agile. If a company relies on 12- to 24-month roadmaps, future promises they make to their customers to guarantee current business, or requires strict budget approval before they can start a new project, it will be hard for them to switch to Agile, as this SDLC is based on a certain level of uncertainty. If a company expects to predict operations for the next 6 months, or longer, they won’t be able to use Agile.
Despite its drawbacks, Agile is becoming the buzzword among startups. Why so? Small startups can’t outspend or out-muscle big corporations, but what they do have that the big fish doesn’t is flexibility. This is a virtue that the Agile SDLC method loves. Startups trump their competition by using their limited resources smarter, and Agile is one of the best frameworks to accomplish this. Agile startups employ small teams, each working on one part of the project, and when they put together the results of their work they have a minimum viable project which they improve bit by bit, incorporating user and market feedback in the process.
How To Make Agile SDLC Work For StartUps
In case you’re asking how you can make Agile work for you and your startup – here are some tips.
Step 1. Set your goals. Many startup founders concentrate only on efficient work and fast delivery, but that’s not the only advantage agile development gives you. Create a learning organization that will outperform your competitors. Attract talented people by leaving room for autonomy, mastery, and purpose.
Step 2. Make the transition to a learning organization smooth for your team. Run experiments, embrace failure, and don’t try to become a heroic inventor. A successful learning organization can only work with self-organizing teams, and over time it will take the shape of a ‘team of teams’ structure. You can’t do everything on your own.
Step 3. Change the team spirit. Change isn’t always as welcome as we might think. Just relabelling positions in a company won’t help. You will need devoted coaches and mentors for the self-organization to work well.
Step 4. Avoid cognitive bias. When something works, people at the founder and management level are confident that they were right this time, and will always be right in future. On the other hand, if something goes wrong, they distance themselves by saying that was something no one could have foreseen. Consequently, this may lead to micromanagement of the product delivery organization.
Step 5. Find your own way. Many startups try to copy the processes of other scaling companies. For example, Spotify became a role model for scaling agile organizations. But the truth is, there is no one way in which software is developed at Spotify. Spotify encourages their employees to continuously bring in new ideas and adapt their way of working. As a startup founder, you have to embrace the uniqueness of your company and help your team find their own way to grow.
Step 6. Lose the command & control mindset. Agile companies don’t need project management offices or a gatekeeper between them and the stakeholders and customers.
If we dig deeper into how agile organizations work, we might mention the Lean Startup. Lean is a set of principles that help a company achieve quality, speed, and customer alignment. Lean is a practice that eliminates all the possible “waste” – useless meetings, documentation, and ineffective ways of working, like multitasking. So, basically, Lean is a project management technique that works for all industries, with Agile being its adaptation for IT.
How do you incorporate general Lean principles within Agile methodology? Here are a couple of steps:
- Identify your product. Clearly state what your product is, how it’s going to work, who will use it, how it supports your company’s strategy.
- Make a Product Map. Include product specs, requirements, and a loose timeframe for the development of each requirement. The team needs to visualize parts of the product, how they will work together, and how much time they have to devote to for each part.
- Draft a work plan. This will be your team’s timetable for the release of each iteration.
- Plan daily meetings. Avoid arranging too many meetings, but regular meetings every other day are necessary to discuss current progress and catch mistakes at early stages.
- Arrange sprint reviews. Show the working product to your stakeholders so they can review it.
- Sprint evaluation. Draw conclusions about how this sprint went and discuss further actions/improvements.
As you can see, building lean and agile is as effective as it is dynamic, which is why numerous companies around the world choose this methodology. It allows product teams to concentrate on the roadmap and maximize efficiency by eliminating time-consuming and mostly useless paperwork and meetings. However, when choosing Agile SDLC, you have to keep in mind that it’s important to combine this aim-oriented workflow with customer validation in order to deliver a top-notch product.