Similar to a living creature, any software product has its lifecycle. The software lifecycle is a set of stages that a product has to pass through over the entire lifespan. It begins with a business idea to be implemented in code and ends up with post-deployment maintenance of a finished software solution.
There is quite a standard list of the lifecycle stages widely accepted among software developers. The very technology of computer coding determines the list. But both the sequence of stages and the methodology of project management may vary case by case. Moreover, software product development methodologies keep evolving. And like in any evolution, different development methodologies have to compete struggling to be adopted by software developers.
Every product development methodology has its particular pros and cons. And this is a pretty delicate point since certain benefits and potential shortcomings can unlikely be determined once and forever. What an advantage for one project is a disadvantage for another one can easily be. Nonetheless, the pros and cons of the most popular software development methodologies are worth reviewing to grasp which method may fit your development process best.
Despite a lot of general information about the major software development methodologies is available on the internet, we would go into some peculiar aspects of them since the devil is in the details.
Lifecycle Stages & Project Management Paradigms
The following lifecycle stages of a software product are considered common across the whole software development industry. They may differ slightly project by project, but the difference is in terms, not in meanings. They usually reflect what developers have to do to let the product see the light.
- Analysis of the idea. Any business epiphany of a customer regarding some new software should be analyzed by the developers’ team to understand what technical requirements can be applicable to the future product.
- Designing and planning. When the product requirements become clear, the designers and software engineers offer technologies and tools that allow the future product to meet the requirements. This is about both the product’s features and the means which can make the features come true. The total work plan is elaborated at the stage usually.
- Programming. This is the longest stage that can include numerous sub-stages. They all result in turning a brainchild into a real product that can be touched and tested.
- Testing and bug fixing. The stage helps developers realize whether the finished product is actually finished. The more thoroughly the testing and bug fixing are conducted the fewer problems occur over the post-deployment support.
- Deployment and maintenance. When a new software product starts traveling over consumer markets, the developers’ team can rarely step aside to let the product go as it goes. Support and maintenance are crucial for the product to survive and bring the desired business effect. This stage can last years if not decades.
The lifecycle shows what happens with a new software product over its development. But it does not explain how it happens. Various product development methodologies come into play to answer the “how” question. This is about project management paradigms making every particular development process to be unlike others oftentimes.
In general, there are two basic paradigms: a linear one represented by the Waterfall methodology and an agile paradigm composed of some specific product development methodologies such as Scrum, Kanban, Lean, and the like. The linear paradigm is simple to understand since a straightforward step-by-step development process lies in its core. But the agile paradigm is less graspable on the go since the complexities of all composing software development methodologies differ in many critical aspects.
Let’s take a look at the two popular agile methodologies of product development Kanban and Scrum to grasp how the agile paradigm brings benefits to both developers and their customers.
Kanban Methodology
The Kanban word means a “sign” or a “note” in Japan. The Kanban system is rooted in Toyota car factories. Japan managers implemented boards with notes to visualize a special approach aimed at improving their enterprise inventory system. The main goal was to reduce both waste and downtimes. Over time, the successful approach has found numerous implementations in various sectors.
In the software industry, Kanban is accepted as a method of improving development processes. It is one of the elements of the Agile philosophy having the so-called Manifesto For Agile Software Development in the background. Values indicated in the Manifesto are applicable to almost all agile software development methodologies including Kanban, of course.
What Kanban Looks Like
However trivial it may sound, the only final goal of Kanban is to release a high-quality finished product in time. Kanban begins with a board with notes to make all processes visually graspable for the whole team. Both a real (material) board and its virtual analogs (such as Trello, for example) might fit. Each teammate gets access to the board to see the current status of one or another task at any moment.
Every project has its own work plan consisting of particular stages. The stages should be specified in columns on the board. The number of the stages can vary from project to project as well as their names can be arbitrarily selected. The most crucial is to keep the sequence of stages unchanged. Such a sequence is named the Flow in Kanban. The flow of a typical IT project might include the following sequence:
“pending - assigned - under prototyping - in development - under testing - finished - under maintenance”.
The Kanban notes containing certain tasks should move over the flow through stages. The Kanban board enables developers to run several projects simultaneously. Notes of different colors can reflect different projects. However, a board with notes alone is not enough to make Kanban work. The teammates should know how to play the game.
Kanban Principles
Kanban implies all teammates working as a single mechanism. If someone does not keep pace the entire project suffers. Since the complete workflow is visualized on the board, all teammates can assess their own contribution to the project’s value. The agile philosophy inherent in Kanban has no hard rules but instead, there are some basic Kanban principles to be reckoned with.
- Appreciate and use what you have here and now: the available resources, skills, and responsibilities
- Optimize and improve your development process avoiding overly abrupt changes
- Encourage leadership in your team
Achieving great results with the Kanban methodology is possible if the team’s workload is properly maintained. It is important to quantify the tasks your team can actually handle within a fixed time frame. The Kanban visualization is here to help. It represents a holistic picture of the project that allows realizing how to improve its individual elements.
When Kanban Is Worth Applying
Some experts rightfully consider Kanban as a transitional methodology in moving from the linear Waterfall to a very distinct agile method such as Scrum. Even though both Kanban and Scrum belong to agile software development methodologies, Kanban is a little bit softer in many aspects: no meetings are held, cross-functional teams are never compulsory, there is no division into roles in a team, no fundamental transformations in workflows are needed, etc.
When developers work under the traditional Waterfall methodology, a lot of time spent on documentation can be wasted after some error is detected at the very last moment. Assume the team realizes that it’s time to move to Agile. Why not Scrum if it is so popular today? But at the same time, certain fears are natural: what if such a radical transformation fails?
This is exactly when Kanban would be a good fit. If a team can successfully proceed with Kanban, further transition to Scrum is worth trying. But in many cases, the progress achieved with Kanban appears sufficient. Thus, Kanban benefits include a smooth transition to agile software product development inter alia.
Scrum Methodology
An agile methodology of software development is meant when we talk about Scrum. But this is not completely correct. To be precise, an agile software development methodology can be built upon Scrum practices. That's why my Scrum may appear very different from your Scrum. Hence, Scrum is kind of an agile methodology squared: it offers an agile approach to the very agile paradigm. But first things first.
Distinctive Features of Scrum
In contrast to Kanban, Scrum begins with specific roles to be assigned to some responsible teammates. They have to play the roles in a very unequivocal manner. The scope of responsibilities of the roles is probably the only hard rule in Scrum. What happens next belongs to the flexibility and creativity of your teammates. The basic Scrum roles imply the following:
- Product Owner (PO). A teammate playing this role acts as a connecting link between the team and the customer. The main task of a Product Owner is doing whatever it takes to increase the value of both the developed product and the team’s effort. A central tool of PO is the so-called Product Backlog that contains all working tasks sorted in the order of priority.
- Scrum Master (SM). The one is a servant-leader whose job is to help teammates maximize their working efficiency by removing various occurring constraints. SM assists PO by providing a team with education and motivation.
- Development Team (DT). DT consists of only those specs who directly participate in product development. According to the official Scrum Guide, DT should possess the following qualities:
- To be self-organizing. No one (including both PO and SM) can tell the teammates how they should turn the Product Backlog into an actual working product.
- To be multifunctional. DT is to include all necessary specs to create an actual working product.
- To be fully responsible. Not individuals but the team as a whole takes responsibility for the final results.
- The recommended number of DT members is 7 +/- 2 persons. Larger teams require excessive resources for communication while smaller teams elevate the risk to fail the project due to insufficient expertise.
Scrum Process
Scrum goes with special development periods called Sprints (2 - 4 weeks each, usually). Every Sprint has its specific purpose. Ideally, each Sprint ends up with a new version of the developed product.
Before a Sprint starts, a collective Sprint Planning happens to consider which task from the Product Backlog can fit a particular Sprint Backlog. The goal of every Sprint acts as a motivator. The scheme is simple: fulfilling Sprint tasks indicated in Sprint Backlogs result in achieving Sprint goals.
Every day, the entire team holds a special meeting called Daily Scrum at which all teammates share their plans, achievements, and hurdles they face. The meetings are aimed at figuring out both the status and progress of each Sprint.
When a Sprint is over, two more meetings are held: Sprint Review and Sprint Retrospective. They help teammates assess their efficiency in the completed Sprint as well as forecast the desirable efficiency in the future Sprints.
Advantages of Scrum
Scrum is customer-centric. Customers can amend their requirements at any moment. Even though Scrum does not guarantee the fulfillment of the requirements, the very opportunity to make changes along the way is very attractive for many customers.
Scrum allows saving time through the exclusion of non-critical activities. This software development methodology offers a potentially viable product at the end of each Sprint.
Scrum is focused on self-sufficient teams capable of accomplishing their tasks with no excessive coordination. This is especially appealing to small companies and startups since no special management staff needs to be hired.
Shortcomings of Scrum
Sometimes, the very customer-centric emphasis of Scrum counteracts the Scrum principles. Customers do not and should not care about the internal rules of the team. Especially when the rules limit the customers’ desires somehow. Scrum belongs to the agile philosophy which implies neither communication plans nor risk response strategies. Thus, no formal resistance to violations of Scrum rules is possible.
Another drawback of Scrum lies in the multifunctional structure of teams. The reduced coordination costs cannot offset more complicated and expensive staff recruitment oftentimes. In addition, some extra resources for training and motivation of the team may be essential. In certain circumstances on the labor market, a fully-fledged Scrum team appears to be impossible to employ.
Conclusion
Whatever is done in software development is done for better efficiency. Software product development methodologies are no exception. The traditional linear methodology (Waterfall) still remains appropriate for large projects having unlimited time frames. But the beauty of agile methods is occupying more and more small and middle-sized software teams.
Both Kanban and Scrum described above reflect the agile philosophy in terms of innovative and efficient workflows that contribute to software product development. Kanban is easier to adopt while Scrum is more revolutionary. Kanban is less radical to provide the transition from a linear paradigm to an agile one. Scrum offers an utmost customer-centric vision of the development process in which quite compact development teams move from Sprint to Sprint.
Both above-mentioned software product development methodologies have their specific pros and cons but the very agile philosophy staying in their background enables software development companies and their clients to benefit a lot from the improved workflows. This is essential for custom software product development services provided by contemporary software vendors.
Contact us today to make your project meet the best agile practices of nowadays. Our professional project managers can establish your development process through the individually selected agile methodology that best corresponds to your project.
