As a developer, how should I work differently in kanban vs scrum?

Question

I am a junior back-end developer at a large company in the US.

At the moment, my 10-member team is changing its approach from Kanban to scrum (2 week sprints). My current way of working is this: I pick up the highest priority piece of work for which I'm suited and I complete it to a good standard, as soon as I can without overworking myself. This is essentially Kanban as I understand it. If it takes less time that I expected, that's great. If it takes longer, there isn't much I can do.

My issue is that I can't picture another sensible way of working and, in particular, I don't know how my development approach should change now that we are doing sprints.

Answer 1

The two approaches are very compatible. In fact, it is completely possible to use both. That said, as you adopt Scrum, there will probably be two significant differences.

1) Scrum is very team focused. That is not to say that you don't have experts on a Scrum Team, but the whole team is responsible to work together and that means a lot less of "my work" and a lot more of "our work". Conversations should start occurring related to if it is best to divide and conquer or swarm on a few items. Both can be the right answer in different situations so this type of conversation should be occurring multiple times per sprint (1 - 4 week iteration).

2) While Kanban is focused on the flow of work and output, Scrum is completely focused on outcome. The team should be asked to identify what work needs to be done to solve real-user problems or capitalize on opportunities. This can be a lot of fun because it allows the development team a lot more leeway in creating solutions. However, it's also a lot more responsibility. The team will have to give over some of their "coding" time to solution conversations, stakeholder discussions, and concerning themselves more with understanding the problem space than before. They are also more responsible for creating an impact. If your team's success has been measured on doing the work you are given in the past, this should change and there is definitely an adjustment to be made.

Two quick caveats: First, practicing Scrum is a difficult transition to make and you might not see all of these changes right away. Unfortunately, there are a lot of organizations where you never see these changes. Second, as I said before, Kanban and Scrum are actually very compatible. Improving flow and output can give your team the capability to achieve the outcomes better. Don't throw out everything you learned from Kanban as you adopt Scrum.

Answer 2

I pick up the highest priority piece of work for which I'm suited and I complete it to a good standard, as soon as I can without overworking myself.

This sounds like a very lonesome job. Where's the team in this work?

If this is your view of Kanban, the change of method will mainly introduce teamwork. Scrum will require you to work with your peers as team, collectively deciding what could/should be done in the iteration. And timeboxed sprint introduces a kind of common rhythm. Don't worry, you'll see that collective decision making and teamwork is really fun ;-)

Answer 3

In Scrum you have a closed sprint and you know that something has priority when it is in the sprint. Often you can treat everything with the same urgency, but in the teams where we used scrum we often had high priority tickets well. (If we don't finish anything else, these needs to be done).

You didn't give a lot of details about your teams' specific implementation of scrum, but usually in scrum you have a daily stand-up (that's where the term 'scrum' comes from to begin with). This is where you discuss with the team which of the items left in the sprint you can pick up. "I am currently working on task A, probably I will finish it today, then I will pick up B, but it might be that B is still impeded, then I could go for C or D." Someone else might interject "I'd prefer you leave C for me, because I already had some thoughts about it."

Another point I would make:

If it takes less time that I expected, that's great. If it takes longer, there isn't much I can do.

I do not agree with the last sentence, neither in Scrum nor in Kanban. There is something you can do, and that is mention it to the team that a task takes longer as estimated you mention it and manage everyone's expectations. That way you can together decide to change plans, by either dropping a task from the sprint that isn't worth spending so much time on it, or getting someone else to help out if it would block the team if you don't get it done by the end of sprint.