Being a developer at Plataformatec taught me to care about the whole development process, not only about my code. I want to share some thoughts about what I’ve experienced.

As I could observe while working on Plataformatec projects, a lot of companies are moving to Kanban. Usually, these companies used to follow Scrum guidelines, working in sprints of two or three weeks.

While moving to Kanban, companies maintain some old habits which are harmful to the project’s health. Stories that are discontinued due to change of priority and pull requests that get stuck too long due to the amount of WIP are good examples of problems that usually can happen during the transition.

That often happens because the team is used to work on a viable number of issues during two weeks, but when switching to Kanban, the sprint limit is not there anymore. Of course, you always can set the maximum WIP for a given column in the Kanban board, but being more specific, the main concern here is the culture of shipping things fast enough to finish the sprint successfully. This culture does not work on Kanban.

When using Kanban, the best approach is not to be always coding something, you can’t just focus on the “In progress” column because it is only one part of the whole picture.

Even though you are a programmer and what you do best is coding, you should care about other things.

The goal of everyone in the team is getting stories to the last column, to the DONE column.

I know you are not responsible for testing and there might be a Quality Assurance person working on cards in the “Review” column. Those stories may not be of your accountability, but you can provide, for instance, good information in order to test the issue or even teach him/her to use Postman in order to test if the page correctly displays the API field values.

As the goal is to get to the last column, there’s always something you can do to help. Automate things, for example. If you have time for it, a tip I can give is to start by the column nearest to done.

As I already said, moving a card to done is not just a Scrum Master’s job, it’s the team’s goal. The definition of done must include the card to be well tested and in production (adding “satisfying your user needs” would be nice too, but let’s just focus on the “production” here).

On Zach Holman’s article “How to Deploy Software” he says an important statement, which is:

This isn’t a tooling problem; this is a process problem.

Yes, it is a process problem indeed. The longer it takes to deploy, the longer your card will be held and your goal is not yet accomplished.

I’ve seen some deployment processes taking more time than fixing a bug in production, testing and being ready to deploy (and it includes the rpm packaging time!).

The same occurs at testing. Testing may be someone else’s accountability, but ensuring the software works is the team’s responsibility. So, help your coworkers to automate tests, teach them to use Capybara, Selenium or whatever fits your needs.

Ensure your CI Server jobs are fast, that you have good feedback for tests (you may consider notifying the team chat) and visibility of the whole process, so you can improve it ­ and when doing it, please note that guts are not as accurate as measuring your steps.

The last thing I’d like to share is how I changed the way I see the board. I’ve always looked to the column which has the higher number of cards and pushed them to the next column.

So, when you start working in the morning and open the whole Kanban board, the trick is not to think which cards you could push to the next column, but instead, beginning from the last column, think about which ones you could pull to it.

What do you think about these tips? Do you agree Kanban is the team’s responsibility?