At SAJ ADV we’ve been experimenting, for the past few months, with three different development methodologies, each of which adds value to the entire process. They are: Lean, Agile and Kanban. Up to when I started writing this post, I thought we used Scrum as well, but upon greater scrutiny it became clear that the roles and meetings from Scrum can also be found on Kanban, so I removed the prior .

Since these aren’t novel methodologies, and are easy to find at Wikipedia, I’ve kept the post objective, presenting how they’re being applied and how they’re helping my team to deliver quality and success to our customers. I gave concise examples for each topic.

Lean

Eliminate Waste

We strive to improve our productivity by not wasting time on the little things that add up, a.k.a. “death by a thousand cuts”, so very seldom you’ll see one of my team members going from one incomplete task to another incomplete task and then back to the first one, in an endless loop of incompleteness. We have a guideline that states that you should only start a new task if you completed the previous one.

Amplify Learning

Everybody is encouraged to share whatever knowledge they think might be worth for the rest of the team. We hold meetings for this purpose at least bi-weekly, and every week a team member takes a day off to study something that will help us in the long run (we call it Cantinho dos Estudos :), something like studying room).

A significant part of sharing your knowledge is documenting. While many developers might feel averse to it, only when you get to develop in a system of considerable complexity you’ll see the real benefits of documenting even the smallest of details. Maybe I’ll expand on this notion in a later post, but suffices to say that we document a lot, and it helps us greatly.

Decide as late as possible

Instead of implementing new features like crazy, in the vain hope that they’ll help our customers, we have a dedicated product team that creates and validates hypothesis about new functionalities, with actual data from customers.

Also, when I became responsible for the SRE-part of my team, the first step was to create/document Service Level Indicators and Service Level Objectives over the services we have. I did that by checking previous metrics and data gathered from our NewRelic subscription.

Deliver as fast as possible

We implement Continuous Integration and Continuous Delivery, having builds and deploys happening pretty much every day. And by using the Kanban board, we track functionalities and bugs from start to finish, in a way that we can improve our delivery speed by flagging stories that are too big, and breaking them into smaller deliverables that bring value to our customers.

Empower the team

The team has plenty of autonomy in deciding the best approach to any given problem and the technical decisions are up to us, since what really matters is the final value of the product. One such example: some weeks ago, by paying attention to our systems’ metrics on NewRelic, I noticed that the AWS instances for our JSF application were consuming almost all of the memory available, at all times, and that was undermining our users’ experience. After due analysis, I decided to add one more instance to the application, and that solved the problem!

Build Integrity In

By leveraging tools that check our code base, such as SonarQube and Understand, we are constantly improving our code and architecture qualities. And by doing pair-programming often, and code review upon every merge request, we seldom allow bad code to get into the system.

See the whole

As in all things, you should never lose sight of what’s truly paramount. In our case, that’d be our customers. No matter how much toil we remove from our workflow, or how much our team is able to learn and apply new/better technologies/processes, if the customers are not getting more value out of it, something is remarkably wrong. That’s why we track very closely our NPS and watch for customer feedback.

Agile

Individuals and interactions over processes and tools

Very similar to Lean’s Empower the team principle, here we created a culture where everybody in the team feels comfortable in suggesting and implementing improvements that they feel worthwhile to us and, ultimately, our customers. By doing retrospective meetings, per the Kanban methodology, we highlight the best/worse actions in a blameless manner to iterate and improve them accordingly.

Working software over comprehensive documentation

In the past few weeks I’ve been implementing some much needed health checks to our services. In none of these did I create an extensive documentation of what should be implemented and how. Of course, I analysed the situation and the system requirements to understand what exactly the health check should do, but any sort of documentation here would be useless and an overkill.

Customer collaboration over contract negotiation

As stated in the section about Lean’s Decide as late as possible principle, we have a dedicated Product Team that’s always in touch with our customers, creating and testing functionality hypothesis. That way, we often only implement functionalities that have proven to be useful to our customers.

Responding to change over following a plan

In the previous post about SAJ ADV, I already explained how we define some general objectives every quarter, called Objectives and Key Results, and attempt to follow them through, but always with some space for unforeseen challenges.

One such example happened months ago, just when I had entered the team. We were having too many problems and bugs in some critical areas of the product. Instead of following the plan and continue to implement and deploy new functionalities, we stopped everything and focused two weeks on bug fixes. That solved most of our problems, and enabled us to innovate without fear of breaking existing functionalities.

Kanban

From Kanban we adopted the board, and a few roles and meetings.

The Board

The Kanban board helps us a great deal in managing our tasks/stories. We have a virtual board on Jira, and a physical replica that gives visibility to all the stakeholders of the company about our work progress. By leveraging some metrics that we take from the board, like cycle time, lead time, throughput, we get plenty of insights into our daily operations, how the tasks are progressing, who’s stuck with what, how many new functionalities are getting to the customer every week (and bug fixes, of course), and more. Below, a picture of our physical board:

Kanban board

After some iterations, we now have the following columns in the board:

Backlog: new functionalities, approved by the Product Team
To Do: stories from the Backlog that have been prioritized by the quarter’s OKRs
Doing: the stories being worked on (developed and/or analyzed)
Staging: stories being tested in production-like environments
Waiting for production: stories that are ready and tested, just waiting for deploy
Finished: stories ready and facing the customer

For each one of the above columns, we have three possible categories:

Evolution: new functionalities
Correction: bug fixes
Kaizen: improvements to the team itself (being in the processes and/or inside applications)

Roles

We use the role of the Service Delivery Manager, akin to Scrum’s Scrum Master, which is somebody responsible for removing impediments for the team and for watching the flow of work/stories, and is represented by our development manager. We also use the role of the Service Request Manager, represented by the Product Team committee, that sets our product’s roadmap and the system’s policies.

Meetings

Replenishment Meeting: our quarter planning meeting, where we set the OKRs for the rest of the quarter
Standup Meeting: we have a daily meeting, where the we gather in front of the physical Kanban board and check everybody’s current tasks and possible impediments, usually in less than 20 minutes

P.S.: one more meeting hold regularly is the Scrum Sprint retrospective, which we do every other week to discuss what went good and bad for the team in the previous weeks, related to our processes, team members, tasks/stories, and more. I didn’t include this one in the post because I couldn’t find a Kanban meeting with the same purpose, and since this is pretty much the only thing we have from Scrum, it wasn’t worth including.