Improve business productivity with rapid development
We’ve talked about using trunk-based development to improve software development productivity. In fact, to significantly increase productivity, you must implement multiple methods, which is why there are many agile methodologies, two of which are well known: Scrum and Kanban.
Scrum is currently the most widely used by most organizations. However, it is not easy to use Scrum well. In many agile methodologies, Scrum is the most diverse, and it can be said that there are a hundred Scrum practices in a hundred organizations.
This is Bcuse The original Scrum contained many “rules”, which could not exactly match the current organizational structure of each organization. According to Conway’s law, most software structures are closely related to organizational structures, resulting in various agile methods that can only provide a prototype and cannot be fully implemented.
This article will briefly introduce the purpose of the Agile and Scrum method, as well as the problems encountered in running Scrum, and then describe the main topic: Kanban.
Why do we need agile methods?
What exactly does it need to be agile?
First, let’s define what agile is.
The purpose of Agile is to generate “faster” value. So, what is the value? Honestly, it’s something that can make money. In other words, they are usually found in the form of features on the product. This means that only when the feature or product is delivered to the customer can it generate true value, and the purpose of rapid development is to accelerate the delivery of this value stream.
When we evaluate the speed of delivery of a value stream, one indicator is usually used: the timeout. The entire time from the feature request that is generated to the requirement that is actually delivered to the client is called the delivery lead time.
Under traditional waterfall development, this lead time can take several months, which doesn’t seem agile at all. Moreover, if this requirement is fulfilled halfway, it turns out that this is not what the customer wants, then all the invested resources are wasted.
Therefore, modern software development focuses on dividing requirements into small parts, and each small piece has its own value. By consistently delivering these small values, the product iteration cycle can be faster.
I think most of you have heard of or even experienced the Scrum development process. From the conclusion of the previous section, we can know that the core spirit of Scrum is to break down large requirements into small requirements through a short, pre-defined cycle: Sprint. Each small requirement is set in the form of a user story. It is important to have deliverable outputs at the end of each Sprint.
There are three roles in Scrum.
- Product Owner: This role is clearly the Product Owner. It’s like a traditional project management and sales manager, as a gateway between the development team and the customer, to find out what the customer wants.
- Scrum Master: The person most familiar with the Scrum process on the Scrum team, responsible for hosting each “Scrum Defined” event, and should also act as the coordinator of product requirements and development teams.
- Functional teams: This role represents the development teams and the people who implement product requirements. There are many different departments depending on the size of the team and the nature of the teams, such as front-end, back-end, QA, etc.
Sprint consists of several different events.
- Planning: This event is used to determine the requirements to be taken in this Sprint. At this point, each small requirement is usually converted into a card with its cost points. Each fixed Sprint is equipped with a fixed number of points, that is, in this cycle, what tasks must be completed according to the number of points and priorities.
- Development: After each member receives the assigned card, they start working.
- Retrospective: At the end of Sprint, review the status of everyone’s cards and ascertain the value this Sprint can provide, as well as review this Sprint’s performance.
The description above briefly describes the entire Scrum development process. As far as we know, Scrum is complex, there are many assigned roles and events, and there are many Scrum overheads. Taking the team I’ve been working with as an example, Planning would take half a day, Retroactive would also take half a day, plus having regular meetings like standing up in the morning, basic expenses alone can take up to 2 days.
In addition, estimating the number of points is also an imprecise exercise. Who should set the price? Who will give it up? How many points can a course handle? It takes a long time to get used to each other before we can gradually go down the right path.
Furthermore, how should the role assignment be configured? Every organization usually has a basic organizational structure, and it is very difficult to extract roles that can adapt to Scrum.
All of the above situations are worse if there are many parallel Scrums. Especially when someone is in multiple Scrum teams, regular meetings can take up most of the time.
In short, scrum is ineffective for small teams. Therefore, the teams I lead use another agile method: kanban.
Compared to Scrum, Kanban is used by fewer teams. The main reason is that most teams do not use kanban properly and therefore do not see the benefits of kanban. Most people just plan out the different stages of the Kanban board, then place the cards on the lanes like a Scrum, and then move them through stage by stage. In the end, they get no benefit, just using Kanban in the figure, then back to Scrum, after all, the way to make the card is the same.
For this reason, in this section I will first introduce the purpose of Kanban, then explain the key to using Kanban, and finally describe the Kanban development process.
Kanban is just like in appearance, it is actually a display of a value stream, and each stage of a value stream must be rendered in a kanban. Assuming your organization’s development process is analysis, design, implementation, testing and release, there should be five stages in a Kanban board.
As mentioned in the first section, an agile approach is to speed up the value flow; Therefore, Kanban presents the entire value stream in a specific way, and can also see the elapsed time for each task. When there is a card that cannot go to the next stage for a long time, it means that there is a problem, and the task status must be checked immediately and appropriate actions taken immediately.
For example, if the content of the task covered by the card is very large, then the card must be divided into two parts at once. And let someone take care of the small split cards. By checking the status of each card, value delivery can be speeded up.
There are only three main points to using Kanban properly without any specific events.
- Cards can only be moved backwards, not forwards. Each stage of the kanban represents the stage of the value flow. Like the flow of water, the water only flows down, and the value only flows to the customer. For example, assume that one stage is development and the other is in testing, so that even if an error is found during testing, the card will not go back to development, and instead should remain in testing.
- Define Done Definition (DoD): DoD is important to Kanban, what conditions must be met to move from one stage to another regarding quality. Taking development and testing as an example again, if the state of the DoD is that unit test coverage reaches 80%, the card cannot enter the testing phase until this condition is met. On the other hand, it is also important to define a “measurable” mod. It is recommended to turn the DoD of each stage into a checklist, which can make sure that each card movement is compatible and qualified.
- Identification of Work in Progress (WIP): Arguably the most important concept of using Kanban. Each stage must specify its own work in progress, ie the maximum number of cards that can be accepted. If the works in progress for the next stage are full, even if the DoD is completed, the card is still unable to move to the next stage. The purpose of the work in progress is to be able to see where the value flow has stopped in a jiffy. As mentioned in the previous section, once the flow of value has stopped, immediate action must be taken. How do you know it’s stuck? The time spent on a particular card is an indicator, but when the number of cards is large, this indicator is easily ignored. Therefore, work in progress is a more effective enforcement measure, as long as you see that the work in progress is full and the ticket is forced to wait, something is stopping you.
In this section, I will explain how my team uses kanban. First of all, the Kanban boards we used are: open, mission, design, develop, test, release and close.
- Unlocked: All feature requirements will be posted here after they are released. At this time, the content of this card will be huge, the time spent and so on are not estimated.
- To-do tasks: According to the priority, the cards are taken out of the opening, evaluated and divided, and a large card will be divided into several small cards and put into tasks. The working time for each card is about one to two weeks. The work in progress will be assigned to the task a bit more, which is my team’s ability. We will queue up to do so. If the task is full, then my team is currently overloaded.
- Design: In the to-do stage, the due date of each card should be planned, and the design stage will also determine when the card will be spent in each stage. If you get stuck on stage in the future, it means that something is wrong. The mod in the design phase is the production of design documents that are included in the user story and use cases mentioned in my previous article.
- Development: After entering the development phase, it is time to develop the feature. At this time, the focus is whether the expected time will be exceeded and the work in progress. Work in progress is defined here as roughly twice the size of the team. For DoD, unit testing is completed, and integration testing must be passed on the on-premises environment.
- Testing: Cards at this point have already been deployed in a staging or pre-production environment. Due to mailbox-based development, every code is entered into the trunk, and every test environment is released from the trunk. It is tested by QA in a pre-production environment, and after completion, it is ready for the release phase.
- Released: The feature has been deployed to a production environment. At this point, we will pay attention to a period of time to show whether the feature is working properly, and the time is DoD. If the observation time is traced, the card will enter the final stage: closed.
- Locked: At this point the features are working normally normally, we will review every now and then the number of deliveries depending on our performance and then achieve it.
As you know from the description in the previous sections, the use of Kanban is flexible and can be easily applied regardless of the organizational structure. There will be no fixed regular meetings and no assigned roles, and everyone can still develop as before. The Kanban board is just a visual tool that provides managers with an intuitive view of work progress.
The entire Kanban approach does not have complicated rules, just the value stream, DoD and WIP that each organization defines based on their existing business processes. By mastering the goals and principles of Kanban, it is easy for organizations to implement their own customizations on Kanban, which is also an advantage of Kanban.
As an experienced leader with Scrum and Kanban, I will continue to lead my team using the Kanban method in the future. After all, meetings are a waste of time.