Most business systems need to change from time to time, and each new change requires financial and human resources, IT Support, and Lifecycle Management.
In 1970’s when large computers were first introduced, the team of experts used to follow a hierarchy to develop software applications. When a new work was required, the team of programmers went to talk to the users to gather the necessary information. The programmers then work in their system to implement the design or minor modification.
Eventually as technology evolved and new tools were evaluated for software development, the companies realized the value of streamlining their data irrespective of handling all work manually that they used to do.
This led to the evolution of Software Development Lifecycle in Project Management for successful management of Information Technology and applying flexible methodologies.
What is Software Development Lifecycle (SDLC)?
A software development lifecycle model is a framework that describes the activities performed at each stage of software development project. The activities are performed in following phases:
There are various software development lifecycle models which are followed during software development to deliver an effective product. Each model follows a process to ensure that a product gets delivered successfully and in minimal time.
Following are the important and popular SDLC models used in the industry:
• Waterfall Model
• Iterative Model
• Spiral Model
• Agile Model
Waterfall Model: Waterfall Model has been widely used as a classic SDLC model for software development in various organizations. In this model, each lifecycle phase can start only after the earlier phase is complete. Thus, it has been easy to use and understand with proper management control.
Iterative Model: This model follows the incremental approach. Issues found from the previous phase are first identified and fixed. The process repeats itself until a working product is delivered. This lowers the initial delivery cost and the product delivery time becomes faster.
Spiral Model: This model follows the same structure as Waterfall Model except it adds Risk Analysis to the Waterfall Model. Before developing the next level product, the risk identified are evaluated and monitored. This provides early indication of risks, without involving much cost.
Agile Model: Agile methodology is defined as ‘Iterative’ and ‘Incremental’. In waterfall model, development teams could only have one chance to get each aspect of a project right. In agile, every aspect of development – requirements, design etc. is continually revisited throughout the lifecycle. Two of the most widely used Agile Software Development frameworks are Scrum and Kanban.
Before proceeding ahead with Best Practices for Kanban in Software Development, let’s take a walkthrough about What is Kanban.
What is Kanban?
Kanban is a way for teams and organizations to visualize their work. Every team member remains on track with the development and progress of work. This helps improve the way a work flow needs to be managed rather than managing team members and their work.
Why Does Kanban Work?
Kanban envisions your work by creating cards on a board to give an overview of your work.
The board makes work visible to the whole team by showing how cards move through each step of the process and provide context for the work by showing who is focusing on what and why.
Creating the Kanban Board
Kanban is a word of Japanese origin – ‘Kan’ – Visible and ‘Ban’ – Board.
The Kanban board is an instinctive way of project representation that allows tracking the current status of the project. Below is a suitable example of how Kanban Board looks like.
Every task has its card. Here, the board has been divided into four parts:
When a task is done, its moved to the Done section.
Kanban Best Practices for Software Development
There are a few pointers which can be applied while defining Best Practices or a common practice everyone in an organization should follow to handle and manage Kanban board in a more efficient and organized manner:
• Idea/Backlog Handling
• Define Work
• Define Stage Policies
• Visualize work
• Stand-up Meetings
• Work Time Estimation
• WIP Limits
• Ready Indicator
• Blocked Indicator
• Bug Handling
As soon as an Idea is ready to be implemented, a new card is created in the project board. The “Cards to be Implemented” are collected on a separate board.
High Level Roadmap
As an alternative, use a high-level roadmap where you create cards related to your higher-level goals on demand.
The team should define a way how work gets on a board:
• Either choose a feature to implement depending on what’s important and valuable for the customer.
• Or a Board owner defines the work.
Define Stage Policies
Define what each stage is in a stage policy.
Go through every stage policy together with each involved team member and make sure they understand the policies well.
The more context there is the better the focus and quality of the work outcome will be.
The easiest way to start is with the text “Features in this stage…”
• Have a UX concept
• Have been developed and tested
• Have been distributed across our traction channel
After you’ve described a policy, follow up with some quality descriptions.
• Closely work with Work In Progress within team
• Review the work flow among team before deployment
• Set a due date to complete the work and follow up on performance.
By mapping your software development work flow you get an overview about who is working on what and most importantly why.
Work gets visible to involved stakeholders. This leads to increase in collaboration and communication.
If a feature on your idea board is defined as ready to be implemented, add it to the project board.
Cards move along the process from the first stage…
Until they reach the last stage…
Two cycles done. Time to celebrate!!
Stand-up meetings are organized for a team and team lead to gather around and understand the work flow.
The stages of the board are moved from left to right.
These meetings help the team to observe that whether the cards flow smoothly through the board or there are any kind of conflicts that occur.
The “Standup” act as an effective tool for cooperation between teams as well as transparency between them.
Work Time Estimations
Getting estimations right is hard.
In Kanban you don’t measure how much you can do within a certain period of time. You measure how long a story needs from idea to roll out.
Priorities are defined depending on what’s important and valuable for the customers.
With every work iteration, you get a better understanding on how long a piece of work would take based on the updates made on Kanban Board.
Work In Progress Limits
Setting the optimal amount of work that your team can handle at one time will lead to smooth and continuous workflow.
It also improves quality because you can give greater focus to fewer tasks.
This maximizes efficiency and you eventually get more work done in less time.
The WIP limit in the “Implementation” stage is 0 of 2.
The WIP limit in the “Implementation” stage is 2 of 2.
If a feature you are working on is finished and ready to move to the next stage you can mark the card as ready to let everyone know.
A team member with an open working slot can pull the card into the next stage of the process.
Let’s assume a feature you are working on is blocked for some reason.
For example: The API of a service you are integrating with doesn’t work as described.
Make the blocker visible to the whole team by marking the card as blocked. Also, add the reason why its blocked or on which action you are waiting.
• Add a separate board for Bugs
• Create new cards for bugs in the main process board.
Create a separate board for bugs, with stages defined to your bug fixing process.
Define bug fixing policies and when to work on bugs to fit the main process workflow.
A separate card can be made which defines research related to bugs found.
Once research is done, the team member fixing the bug can move the cards accordingly until they reach the last stage and are marked as “Fixed”.
The card flows through the process until the card reaches the last stage.
Why Implementing these Practices Makes a Difference?
Markets can change fast and therefore companies need to be able to act quickly. Keeping a regular track of the project from ‘To Do – In Progress – Done’ aims at Just-In-Time delivery. Also, it decreases the load on the team leading to an increase in their efficiency. Following these practices will keep the team aware of what is the current status of the project or a single task during a development process. This enables smooth and continuous delivery of the project.
The Kanban methodology relies upon the full transparency of work and real-time communication of capacity. Therefore the Kanban board should be seen as a single source of truth for the team’s work.