My team is just getting started integrating agile practices (we’ve chosen kanban) into our dev, test and design teams, but we have a lot of bug cases and feature cases not written in user stories left over from the old system and we’re trying to find a good way to take care of the bugs but still keep the devs that need to stay heads down focused. for now we have a newer dev assigned to bug fixes so the rest can work on new features but we are looking for the right way to structure the team. We have 7 devs, 2 testers and 2 designers.
Thanks in advance for the help 🙂
Place the bug items on your Kanban board like everything else (in prioritized order of course) and then let the team decide who should implement the next item in the queue.
I believe the team knows best how to handle this, rather than having someone else distribute the items among specific team members. At least that will give them an opportunity to self-organize. This being agile and all.
3
Finish the old bug cases and feature requests as usual and slowly begin to implement the kanban system as new bug cases and feature requests come in.
OR
Have some devs or other people in the office create user stories for the old bugs before progressing.
What you are maybe missing is a clearly prioritized backlog and proper WIP limits (work in progress limits).
First, assuming you are starting out using 3 states (Open/Backlog, In Progress, Done) the team needs to have a way of pulling items from the backlog according to the priorities set out by the product owner. It does not matter whether or not these are leftovers from the pre-agile time. Everything has to be prioritized against everything else, right? So assemble your backlog, giving the team the possibility to choose from the top of the backlog. It also does not matter whether or not the items are rough sketched bug descriptions or fully blown stories, what matters is that you have some kind of visualized representation of the idea of the product owner that the team can work with it. Transition to a more formalized way of defining these wishes on the way (until you end up with only proper bugs and stories in the end). Bugs are a fact of life in software development, so just treat them as stories when prioritizing.
Second, tell the team to come up with a maximum number of items that they would like to have in progress at the same time and let the team define this as their initial WIP limit. This value can be adjusted over time depending on the way it works out for you.
It also seems as if you think you know best how the team should organize their work (assign one new developer on bugs, keep others focused). I have seen this kind of behavior before and usually it is a sign of dysfunctional behavior. The team should know best how they solve the items on the Kanban board, provided they act and think as a team. This way they can maximize the throughput and utilize everyone to the best of his/her abilities. Interference from outside (micro-management and alike) can hurt the team. This said, there is always two sides of the story, as teams must grow and might need proper guidance to achieve a certain quality where agile practices work effectively. If they have problems splitting up the work this is something that can be addressed as part of retrospectives/feedback loops that are essential to improve things like the distribution of work for example.
Remember that Kanban is based on letting the team pull rather than pushing items onto the team. Finally, should you fail with the one big team approach, you and your team can always consider splitting up the team into several smaller teams, each having own Kanban processes and workflows with individual boards, tailored to the specific team’s needs (e.g. a bugfixing team, feature team, tester team). In the end, you and your development team must govern the process, not the other way round.