Hey guys,
I’m new here and I would like to know if Kanban is actually Agile…
Thanks
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
Kanban originally came from the scheduling practices of Lean before Agile was a thing.
IMHO, the reason why Agile came alone was people were sick and tired of seeing effort/money/time wasted with the waterfall approach in a complex environment.
Lean/Kanban and all the other methods/practices we call Agile serve the same purpose. Eliminate waste.
So in a way, yes, Kanban is Agile. Some people refer it as flow-based agile while calling others, such as Scrum, the iteration based agile.
In terms of three pillars of empiricism, I do believe if we implement Kanban method properly, we would be seeing all three.
Having columns ONLY does not make it a Kanban though, it’s only a status board. We need WIP limits, poll policies, as well as the definitions of where to start and where to end.
Kanban help us focus on the work itself, not on the people doing the work.
I would definitely say yes! In fact, as long as the focus is to deliver value, to work on items that are ready and that make the scope evolve as the project progresses, I think the Kanban is indeed Agile.
Thanks David, your answer make sense.
But there’s one point that I cannot convince myself so far is :
What about the 3 pillars of Agility : Transparency, Inspection, Adaptation
Where does pulling a task from TODO to IN PROGRESS enable this ?
There’s a bit more to the Kanban Method than just pulling stories from a to-do column into in progress. Ideally you
– visualise the entire workflow through to the customer using the product
– split each column into “doing” and “done” sub ciolumns
– have swim lanes for different classes of service
– monitor Kanban metrics like lead time, cycle time and throughput
Over time, tools like a “cycle time histogram” and “cumulative flow diagram” will help you to better understand the bottlenecks in that flow of work and improve it.
The cycle time histogram – with a mean and standard deviation of the cycle time – will lead you towards a probabilistic forecast for when work will be completed.
So you have transparency with the customer on delivery, and also the tools to test any hypothesis you might have regarding improving how work flows within the team.
And of course, you can extend this to an “upstream Kanban” for features, where you (say) develop a feature hypothesis, story map and deliver the feature itself. That leads to even more transparency when it comes to the mid-level *operational* forecasting.
The big difference with Scrum is the lack of a Product Goal, Sprint Goal and the Sprint cadence; that means that the overall product direction and product-market fit is not directly considered as part of the cycle.
The other big difference is that team can cover several product areas, and deal with bugs or defects, as well as technical debt easily. That might make easier if you have a “brownfield” product that lacks automated testing, and are moving to a more agile od DevOps delivery models.
Kind of what you mean by “Kanban”
The Kanban Method is pushed as an alternative to Scrum; it’s agile in the sense that you should be meeting all of the things in The Manifesto For Agile Software Development, but it doesn’t really address value at all; it’s assumed that’s someone else’s problem.
Kanban strictly speaking is just the signal that says the team should pull more work; so on that sense most teams have some form of visual indicator for this.
I’d tend to classify Kanban as more Lean than Agile, in the sense of the Poppendieck’s book “Lean Software Development”
They are similar, but on the whole lean approaches don’t really deal with the innovation / R+D space very well. Innovation is often lumpy, and doesn’t flow….