Over the past 8 years I’ve developed in both Scrum and Kanban. There were times when I preferred Scrum over Kanban and times when I preferred Kanban over Scrum. About two years ago, I came to an interesting conclusion — it doesn’t matter what you call it as long as you apply the right principles. Scrum vs. Kanban A personal story, I started my career in a Scrum team. It worked brilliantly (I have written ) until we started working on a new, very important project. The requirements changed all the time during the sprints and the estimations were way off, since we were working on unfamiliar domains. many posts about Scrum So we decided to do the only reasonable thing — switch to Kanban (I have also ). In Kanban, we didn’t have sprints and we were fine with constantly changing requirements; we were always working on the most important tasks. there were two problems : We were working on the most important tasks and we were working. written about Kanban But only always Since we always worked on the top priority tasks, we had no opportunity to work on anything but new features. We had no time to work on our tech debts or time to improve our tools and infrastructures. So we decided to do the only reasonable thing — switch back to Scrum. Well… you get the picture. Disclaimer I’m exaggerating; it wasn’t that bad, but it felt wrong no matter which one we chose. Neither of them was perfect and we constantly felt something was missing from our process. The Best of Both After experimenting with both, and seeing both Scrum and Kanban work and fail in lots of teams, I’ve came to realize that it doesn’t really matter what method you choose — the principles and the best practices are what matters most. So here are the principles that matter most . for me It is important to finish In Scrum you work with sprints, and every week or two the sprint comes to an end. This is one of the most deficient parts of Kanban in which we were constantly working; we finished tasks but we immediately started new ones. A sprint creates a scope that eventually ends. We all go home with that sense of accomplishment (even though we are going to start a new one after the weekend). Celebrate wins Another great principle is the review where you meet with stakeholders and share what you have accomplished in the last sprint. It is a celebration of everyone in your team, they get to share what they have done and receive feedback for it. Constantly learn and improve yourself The single best practice is to retrospect yourself. Think about what you should keep doing and what should you stop doing and improve. When you constantly work you don’t always get to stop and think about these things, hence you don’t improve. A retro is a must have meeting. Requirements will change In the real world, requirements change all the time. Bugs, features, the scope will constantly change. It is OK. This is the real world; we build, we measure and we learn. So it is good to change priorities and work on what really matters. Don’t be closed to changes — embrace them. And that brings me to the next point. Plan ahead and break down to small tasks It’s hard working on big, unfamiliar tasks. You cannot estimate the required effort or even truly understand the scope. The solution is simple — don’t do it :) Don’t dive into an unfamiliar area without the proper preparation. Don’t try to deliver right away. Start with a few hours exploration task, understand the scope, the requirements, the pitfalls, break the feature down to small deliverables and create a high level design. Share it with your team, poker plan them and you’ll see that estimating these tasks is pretty easy. Visualize and share the process Your process should be visible, both to your team and your stakeholders. Everyone should be able to easily understand what you are currently working on, what your next tasks are and what is blocking you. A visible process is key to spotting bottlenecks, dependencies and creating order. It doesn’t matter what you call it So, you see — you can use Scrum but don’t be afraid of changes and unknowns — embrace them. You can also use Kanban, but every once in a while stop, share your work, celebrate your wins and think if anything can be improved. You can call it whatever you want. I call it Agile and sometimes Lean and sometimes simply work :)

Too Long; Didn't Read

Developers: Build Less. Deliver More. [Learn how]	

Scrum? Kanban? It doesn’t really matter

Too Long; Didn't Read

Dennis Nerush

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

Scrum? Kanban? It doesn’t really matter

Too Long; Didn't Read

Dennis Nerush

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

RELATED STORIES