We have a brownfield project which was recently struck by disaster (many people leaving for unrelated reasons, too many new customers, much too large backlog for much to few people, etc.). Management support is still fine. Thank bob the product owner (decades of knowledge) is still here. The devs have seen some glimpses of DevOps benefits from a very nicely-received DevOps colleague who is doing practical work as well as evangelisation, so there is no resistance on that front, either.
At the moment, we are bringing in new people from all over the place (i.e., split across different cities and even countries, though all speak the same language), and getting the know-how under control etc. We are also focusing a lot on automation before starting actual development again, because everybody saw what happens when we don't. Also, we have bundled everybody together - devs, ops, testers, to make use of every last bit of knowledge and avoid future silos. So it is a very dynamic situation.
My main objectives are:
- Get people to work instead of panicking, i.e., give the individual devs focus.
- Shield devs and ops from panicked management and stakeholders.
- Make it more transparent for stakeholders to see what is happening with their tasks/epics, to reduce panicked zero-warning status calls.
Most people, as well as me, are used to Scrum (or more likely Zombie-Scrum or Scrum-But ;) ), but I believe it is too early to do proper Scrum here. So I will likely implement Kanban (in Jira).
What are your best practices here?
- One column per person/pair? Or rather one column per stage for the tasks (i.e., "in development", "in testing" etc.)? I think I'd prefer the first, because it very clearly shows whether a person/pair has their hands full - we could use a full column really well for telling a manager to go away. Also, we have quite diverse roles in the team (i.e., a DevOps expert who will be focusing on the CI/CD pipeline and such; or the testers).
- In the usual Scrum process, the P.O. would not be part of the actual sprint board, but do his good work in the backlog. Would you propose to give a column to the P.O. so he can focus on fleshing out a few task at a time? This would put the P.O. well inside the team, which I would like. Is it a good idea? (Yes, I am aware that Kanban does not actually label those roles, but I hope you see what I mean...).
- Alternatively to the previous: I believe The IT Sceptic had an article about having two boards - one focused on the stakeholder epics, the other on the actual short-term tasks. Do you have experience with that? Would that help in this situation, in your experience?
These may seem like three distinct questions, but are, in my mind one: how to structure the Kanban board - around people, or around tasks?