Agile is a set of principles that developers can follow to be more effective in developing their software. The whole thing started with a set of principles that were developed by a group of industry leaders back in 2001.

Given that Agile is a set of principles, it is more guidelines vs strict rules to follow. If you review the set of principles, and later the agile frameworks, the biggest take away is to focus on short iterations of work. Always focus on delivering value in each iteration. You can find the set of 12 principles of agile design here. You don’t want to get bogged down with trying to get everything right the first time. A working product is better than a perfect product in most cases.

Agile Frameworks

For those looking to adopt agile design practices, there are frameworks to help guide you in your journey. To name a few, there is Scrum, Kanban, LeSS, and Safe.

LeSS or Large Scale Scrum is a variation on Scrum designed to help coordinate multiple teams towards a given Goal. This could be a few teams, or this could be a thousand teams. SAFE or Scaled Agile Framework is a framework designed to be implemented at the organizational level instead of the team level.

Given that LeSS and SAFE are based on Scrum and Kanban, I will focus on those two frameworks. However, if you want more information about the Less and SAFE frameworks, see the links above.

Scrum

Scrum is a methodology or framework for teams who want to follow agile principles. Scrum is probably the most common agile framework and is pretty structured. The most notable thing about Scrum is you have a concept of sprints. These sprints are agreed upon periods of time between 1 and 4 weeks. During each sprint, the team agrees on what work they can accomplish during that period of time. The team then works on the agreed up items for that period of time.

The work the team is working on is organized into a backlog. The backlog contains a prioritized list of all of the work that the team needs to do. In addition to the backlog, there is a sprint backlog which represents a list of all the work that is being worked on during the current sprint.

The general rule is once you have started the sprint, you don’t add anything to the sprint backlog, and you only work on the work items in the sprint backlog. This allows the team to focus on what they are doing. Since the backlog was prioritized before the sprint began, the team is always working on the highest priority items.

There are 3 roles on a Scrum team:

• Product Owner
• Scrum Master
• Development Team Member

The product owner is responsible for organizing the backlog to ensure the team is always working on the most important work items. The scrum master is responsible for leading the scrum meetings, and the development team members are responsible for working on the items in the sprint backlog.

There are four meetings a scrum team holds that are led by the scrum master

• Sprint Planning
• Daily Scrum
• Sprint Review
• Sprint Retrospective

The Sprint Planning meeting is when the team plans what backlog items they will work on during the next sprint. The team estimates how much effort is required to complete those items, and tries to ensure they don’t pull in too much work that they can’t complete it in the allotted time, or too little that the complete everything long before the end of the sprint.

The Daily Scrum is sometimes called the daily standup meeting. In this meeting, the team gets together to give a status update. There are three main topics of conversation during these meetings:

• What did you do since the last scrum?
• What will you be working on next?
• What blockers do you have?

Blockers are things that are preventing you from getting your work done. For example, dependency on another team. These meetings are intended to be short and not waste everyone’s time. Frequently these are called standup meetings because everyone remains standing during the meeting. Buy forcing everyone to stand, you incentivize everyone to not let the meeting drag on for too long.

In the Sprint Review meeting is held at the end of the sprint and the team looks at what backlog items were completed and not completed. The result of the meeting is a list of probably backlog items for the next sprint, and a reorganized backlog. This sets the team up to be ready for the next sprint.

The last meeting in the sprint is the sprint retrospective. In the retrospective, the team looks at what worked and didn’t work on during the previous sprint. The team then commits to what can be done better during the next sprint.

On the scrum website, there is a nice little video which talks about. how scrum works. And you can download the scum guide here.

Kanban

Kanban is an agile framework originally inspired by Lean Manufacturing methodologies at Toyota in the 1980s. The idea behind Kanban is you treat your work similar to the way that work is completed in a factory. You have your designated work areas, and try to limit work in progress (WIP).

The word Kanban means signboard in Japanese. This too is a central Tennant to using kanban on your team. In manufacturing, it is more obvious what that status of something is. You can look at a car in production and see that it does not have paint, or it does not have doors. In software development things are more abstract and having a visual representation helps everyone to better understand the status of a given item.

The kanban board is divided into different work centers. These work centers will vary depending on your project or team. Typically you will start with the following columns on your kanban board:

• Backlog
• Analyze/Breakdown
• Doing/Develop/In Progress
• Test/Verify
• Done

Below is a sample representation of a kanban board:

Just like in Scrum you have a backlog that you work from. As things come up that you need to work on, you put something in the backlog column. As you work on a given item, you move it from one column to the next on the kanban board. This gives the visual representation of the work being done.

As mentioned, you want to limit work in progress. To do that, you put a Work in Progress or WIP limit at the top of each column. This WIP limit is the maximum number of items that can be in a given column.

In Kanban, you don’t have a lot of meetings, but you do have a daily standup just like in Scrum. Also just like in Scrum the focus of your standup is:

• What did you do?
• What are you going to do?
• What is blocking you from getting your work done?

One of the main benefits of Kanban vs scrum is the lack of sprints. Since you don’t have sprints, it allows you to shift priorities more often. Remember in Scrum you are not supposed to change the sprint backlog mid-sprint. In Kanban, you just have to wait until you are not violating your WIP limit, and you can continuously reprioritize your backlog.

The main drawback of Kanban is that it is not as structured as scrum. Scrum is a much more detailed framework and with the set roles and meetings, it is easier to adopt in many ways. Kanban is not as structured, so it requires a bit more discipline to follow the rules.

My favorite book on Kanban was written by Eric Brechner at Microsoft. There are also various videos on Youtube from Eric on the topic.

Scrumban

Scrumban, as the name implies, is somewhere between Kanban and Scrum. You have all of the meetings and structure of Scrum, but with one added component, limiting Work in Progress.

In Scrum, you populate your sprint backlog at the beginning of the sprint, and then everyone starts working on the various backlog items. You might have 20 backlog items in this 4 week-long sprint, and your team starts all of them at once. You might not realize that something is not working until the end of week 3 at which time you don’t have time to fix things, and you have wasted your sprint.

If you limit your work in progress to let’s say 3 items, then you don’t start on the 4th item until the previous 3 are completed. This means that you are completing and testing backlog items earlier in the sprint. The difference now is at the end of the sprint you have a big pile of completed backlog items and possibly some non-completed ones. But 10 completed and 10 not-started backlog items are preferable to 20 half done backlog items.

Emergent Design

Emergent Design is an agile approach to product design. In general, it means that the development will develop new features using best practices without getting bogged down in the design process. After the feature has been implemented the team will do another iteration on that feature to better integrate it into the overall project and let the overall design emerge.

The goal is that you end up with a smaller code base and a better designed and understood product. The danger is you could end up with a poorly designed product that doesn’t really work. The best guard against this is to do just enough design initially. This ensures that you are following the best practices, and not trying to do something impossible. For more information on Emergent Design, you can look here

Summary

Thank you for reading this article about Agile development. Today we have talked about what is Agile development? What are some frameworks for agile development? How do the most common frameworks like Scrum and Kanban work? What are some of the benefits of Scrum vs Kanban?