One change is always a step in the right direction for others. – Machiavelli
Agile software development does not depend on whether you use Kanban, XP, or Scrum. It’s about finding a process that works within the context you are working in. This can be difficult and requires reflection on what you are doing, how it is being done, and why. If you do something that doesn’t work, it’s best to stop doing it.
Three months ago, I discovered that the project I was working with was having some difficulties. We weren’t able to deliver the features we wanted at the speed we needed. Simply put, we didn’t know what was working and we could miss our deadline if we didn’t do anything. We decided to take action because failure is never fun. These were our main problems.
Poor focus: Many developers on the team had other commitments beyond the project, such as other projects, production issues, and so forth. The taskboard was set up, but the team members were not diligent in updating it. The result was that visibility was poor and the focus was lost on what was really important: Providing value for customers.
The quality of the code delivered: This was not an issue that was unique to our project. This is a problem that I think many software teams face. Teams often deliver too much code too quickly, which can lead to low quality code and high defect rates. It is very costly to find defects late, AP. Low quality software can cause problems for other projects, as developers are assigned to look into production issues. This is a vicious cycle.
Planning and estimation: Scrum requires a sprint planning meeting. The goal of this meeting is to set the sprint goal and to commit to a set user stories or tasks. In our case, the project had developed the habit of doing task breakdowns and estimating each task. This level of detail in estimation is just too micromanaged. I have long doubted its value. We were not following ScrumBut as did many other teams. The worst part was that the process didn’t work. AP

How Kanban was introduced
I had just finished reading Corey Ladas Scrumban’s book and was becoming more interested in Kanban. I found the ideas of just-in-time, limiting work in progress, and small batch sizes to reduce inventory code very appealing. We were faced with a project that was both simple and large, but failed to deliver the results we expected. This was the perfect time to make a change. However, I needed external support because I didn’t have any Kanban experience.
External confirmation
Henrik Kniberg’s article Scrum vs Kanban explains the external backing. It is a great article. It is easy to read and explains the basic aspects of the process in a clear, concise manner. To test the waters, the article was distributed to both the project manager as well as the domain expert. They enjoyed what they read, so we decided to discuss the possibility of making such a change with the rest of our team.
We explained that Kanban was not a revolutionary process, but that we could make some changes to our existing processes to help us get started.
Take small steps
People fear change. Change disrupts peoples lives. It involves learning new skills or doing things differently from what they are used to. It is a great Italian philosopher/writer Machiavelli who said: “And let us not forget that there is no more delicate subject to handle, nor more dangerous to manage, nor more certain in its success, then to be a leader in the introductions of changes. He who invents will have his enemies all those who are well-off under the existing system, and only those who support him who might be more fortunate.