Is this you? That is, does the question below, which I answered on a technical forum recently, describe a situation you might be facing or may have faced in the past?
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 evangelization, 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 tasks 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 Skeptic 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?
Kanban in a Complex, Fast Moving Environment
In my over 25+ years in the software industry, this has been an all too familiar situation! I have often wondered – doesn’t speak too well of us as software professionals! Far too many projects and teams are occupied by far too many crises all through the development/ implementation lifecycle.
However, the fact is that software development is a complex activity – perhaps more so than any other type of projects? Myriad technologies, complex system designs, changing market/ business needs, the inherent difficulties of capturing user requirements and priorities, all make for a challenging situation in the best of times. Add to the mix a situation where you are losing or have lost people, multiple projects demand your bandwidth and customers and management breathe down your neck – it is enough to make anyone break down. Adopting a Kanban system in such a situation can really help your team – and all your stakeholders – understand the situation and slowly make sense of it, get it under control and gradually manage it to deliver to business goals.
Kanban’s evolutionary nature – start with what you currently do, visualize your workflows and work – and manage and improve flow – can be the perfect non-disruptive tool you need to get things in control and working again!
I draw a lot on our own experience – although, of course, I have worked with multiple customers of ours in a variety of situations and those experiences bear me out as well! Starting in 2007 when we moved from being a waterfall shop to 2011 when we adopted Kanban, we have ourselves mastered a number of challenges that the question above presents. I have spoken about our own experience in a number of conferences worldwide and found it resonating with a lot of people – so we are not alone in this.
What follows is my response to the question above – and if you have been or are in a similar situation, you might find this useful as well.
We are of course a product development shop – and since we built SwiftKanban, we have acquired a lot of experience with Kanban. Our product development Kanban board has evolved and undergone change multiple times. Today we have separate boards for epic/ story detailing vs. dev/ ps tracking. Our DevOps setup is still being fully automated and being gradually fleshed out. We’ve been on this journey since 2010-11 – and we have achieved significant business benefits exactly of the kind you are looking for.
Our Kanban Journey
We started with a single Kanban board, but with 2 separate swim lanes for the product manager and the dev team – see below –
Planning Lane for the Product Owner
Dev Lane for the main dev activity
Since we had a single team doing development as well as maintenance/ customer related work, as also refactoring work, we also had a few other lanes to help them visualize their overall workload –
Over the last 6 years, we have evolved, as have our dev/ engineering practices. While we never used Scrum – and don’t have sprints, we do production releases every 4-6 weeks, we deploy to an internal staging server (which we use as our internal production server, where we use our product for dev as well as other functions such as marketing, sales, support, implementation services, etc.) every week or less, and we have a single workflow between Dev and Ops as you will see below.
From that separate planning lane, we have evolved to a full upstream Kanban board – which is our roadmap planning board, where we track Themes, Epics and Stories – and lay out stories in up to 4 releases out. We did this as we gradually figured out just how much work needs to get done to identify and detail the work to be done as well as to get stakeholder alignment so everyone agrees that we are working on the right stuff.
Roadmap Planning Board
Themes on this board provide long-running topics – a new market segment, a specific aspect of our products such as UI/ UX or performance – that might take several release-cycles to fully implement. Themes break into multiple Epics where specific aspects of the Theme are identified and their design/ implementation fleshed out. Each Epic then breaks downs into specific user stories which are taken up for implementation.
These stories get pulled to the Dev board. On the other hand, both internal and customer reported defects are directly added to Dev board’s Ready queue.
Dev Board
The Dev board value stream follows a Test Driven Development flow. Prioritized stories are picked up by Developers and taken thru a coding, JUnits and functional automation flow. All code is reviewed by senior leads and only after that, Dev is considered complete. This is followed by validation; all validation is done functional team members including the Product Manager and Documentation team members. Once validation is complete, features are deployed on to our internal staging server. Once in 4-6 weeks, when we have sufficient Stories and Defects done, we make a production release.
As you can tell, the Product Owner (Product Manager) is responsible for the Roadmap board, while the Sr. Dev Manager is responsible for the Dev Board. While Dev team members deploy to a Staging server, the Ops team ensures they have the right CI/ CD environment to do that. After Dev/ Validation, it is the Ops Team’s job to deploy to production.
Stakeholder Visibility is Key
Both boards are accessible to all senior stakeholders as well as CEO, Sales and Marketing so everyone can track what is going on and what is prioritized for upcoming releases.
At the same time, we ensure we follow many of the recommended Kanban cadences, including the Daily Standup Meeting, the Weekly Replenishment Meeting (where fine-tuning of the story/ defect prioritization takes place) as well as Release Retrospective and a Quarterly Strategy Review Meeting.
The Kanban boards and cadences ensure that everyone is aware and aligned; and if there are conflicts, they are resolved during one of these meetings (other than the Daily Standup).
Besides key Kanban practices – including a reasonably strict adherence to WIP Limits – we have also, of course, invested heavily in engineering practices to enable a true continuous delivery/ deployment environment – and that journey still continues. As I mentioned earlier, we are a Test Driven Dev shop and developers are responsible for JUnits, Functional Automation, and Peer Review. Our code repository is Subversion (we are now moving to Git – and may have completed the move by the time this post is published!) and integration/ deployment is orchestrated using Jenkins. Subversion is integrated with our Kanban tool so all work at each stage is also updated on the card as well (via comments on the card).
Overall, to answer some of your questions more specifically,
1. Yes, it makes a lot of sense to provide a separate board to the product owner and another to the dev/ ops teams and link cards across them as needed.
2. And it makes sense to organize the board by tasks/ workflow stages rather than people as that gives you greater flexibility with using cross-functional folks in different stages of the workflow.
3. Most importantly, it lets you easily visualize and measure which workflow stages might be bottlenecks (rather than which people – which would typically be inaccurate) and what tweaks you might need to make to improve your flow and throughput and reduce lead time.
All the best with your transition to Kanban! If you need any more help with respect to Kanban, I strongly recommend reading David Anderson’s book on the Kanban Method as well as refer to our comprehensive Kanban guide.
Hope you – the reader of this blog – also benefit from this write-up. I would love to hear from you on you have used Kanban to slay your dragons and deliver great products or services to your clients, in spite of those dragons breathing fire on your team!
Mahesh Singh
Co-founder, Accredited Kanban Trainer/ Coach