in Working on a project alone is easy. You are all parties in one person, and you can make a decision efficiently at every step. Having two or three people on a team already requires some syncs, yet nothing fancy is required. With a bigger group, you already need to ask how to keep efficiently in sync.
Agile has been the main direction of the past decade. It can mean a lot of things to many people. Some can call it a swear word; others might not imagine working in any other way. For someone like me, I like to have an idea and slowly see where it takes me because, from my experience, the only constant is a change.
The question then comes to what agile framework to choose from. One of the most famous ones is probably Scrum. Everyone is used to having stand-ups, grooming, planning, and probably the least popular retrospectives in the past. It is more common to do those meetings just because it is written in the book than for practical purposes.
That's why sometimes teams go to Kanban, which seems, on first look, to be less filled with organizational work. I don't see it that way, though. It is a different type of flow emphasizing some other parts.
Scrum and Kanban are not the only agile frameworks. When neither of those works, teams can either look for something else or make a hybrid called Scrumban. But first, we need to figure out: what doesn't work?
Most of the time, in my experience, a product is composed of two very different kinds of work. Implementing new features or changing them, and fixing bugs or doing unpredictable work.
With Scrum, it is easy to work on features and plan releases, but a super inflexible to work on hotfixes. Trying to estimate bugs doesn't work, and hopping on new bug changes the whole sprint. On the other hand, with Kanban, it is natural to work on the most critical task, one or two at a time. Everyday priorities can change, but don't try to plan anything long term.
The problem is you need both unless you work on an entirely new product that has not yet been released to anyone or a mature product in maintenance mode without any further development. So what can you do?
I don't think Scrum, Kanban, or even Scrumban will help. I believe that combination (not hybrid) is for the rescue. The slight problem is you need a bigger team for that. I think it makes sense with at least three, ideally four, people on the team.
The idea is to keep Scrum for work you can plan and choose who is working on maintenance with the Kanban board. The team's velocity is then not four (for the four-member team) but three (if one person for maintenance is enough). Three people then work on nicely estimated tickets, or maybe time-boxed tasks (such as spikes, designing a new feature, proof of concept, breaking down big epic into reasonable tasks, and so on), while one person is processing unplanned or hardly planned work (triaging bugs, checking bug reports, logs, other monitoring, working on fixes, and providing answers for ad-hoc questions).
The next sprint maintenance role rotates to someone else, or the same person can handle two or even more sprints in a row. It depends on personality and other factors (it might not make sense for someone working on a feature spanned over several sprints to interrupt the work in the middle).
If one person cannot handle maintenance, the team can change the split to two:two, for example. In bigger groups, it might be natural that six people can work on features while two guard the walls.
The hard part might be how to work with such a split. Well, if you are still working from the office and the whole team is in one spot (lucky you!), you can mount a giant board on the wall. Make a thick line in the middle and have a feature on the top and maintenance on the bottom. In the end, both workflows need (usually) the same columns, and the only difference is what is on the board and how you approach the tickets.
With the remote type of work, I have fine enough experience with Jira. Every project can have as many boards as you please, and every board can have its own filters. So I have two boards, one to include only bugs, the other to include everything else. The first board uses Kanban type, while the second is Scrum.
For me, that works very well and solves all the problems. The team always has room to work on unplanned tickets and fix serious bugs as soon as possible, while planned important releases are not affected.
feed