Kanbran

Though Kanbran definitely does have software-driven companies in mind as one of its target audiences, you'll notice that the tool is designed in a general way, to be easy to use and adapted by many kinds of organizations for improving their processes and involving a wide range of participants.

It's possible to arbitrarily focus on just one team, but Kanbran's design recognizes that the work flows for creating and delivering core products and services usually stretch across several teams and involve specialists from multiple professions. That's why a general tool makes more sense, since it avoids presenting a context that is only familiar to some but which could be confusing to the rest.

Even more importantly, by enlarging the boundaries of what you might typically think of as your core processes and involving more specialties, you then accumulate much more data, which in turn makes it possible to optimize the output and human resources of across an expanded share of the organization.

Only optimizing one team's output doesn't allow you to fully coordinate and reach the full potential that is latent within all of your teams, waiting to be unlocked as they work together to move good work along and out the door.

All that said, though Kanban boards and some form of Kanban method are popular now in many kinds of service industries, the following statements apply general principles to the software engineering field, to highlight the benefits of the Kanbran web app for software teams.

Since the ideation, specification, development, and operation of online software products involve work in conceptual and digital spaces, companies that manage teams to do that work constantly face choices about what the best course of action is at any given moment to produce as much as possible, with high quality, of an inherently intangible, evolving product and complex system produced and maintained by the invisible actions of many team members.

Instead of a mechanical assembly line of physical parts, such teams provide services to bring ideas to digital life across many stages of refinement, production, and operation.

Those stages and the activities performed at each stage constitute a "process" (aka work flow). And processes have been extensively studied by the field of operations research via "queueing theory". Processes can be modelled, measured, optimized, improved, monitored, controlled, predicted, and re-designed.

Ideally, every organization wants to maximize the throughput from its process while delivering each work item (feature) in the least time possible, to get them into user's hands.

However, it's not obvious how to measure the output from a process that provides an intangible product or service, so many companies just overburden and push work to their teams, thinking that will reach maximum output. That's damaging not just to work-life balance but also to the very productivity they hope to achieve.

Many software teams try to estimate story points and measure weekly velocity in those terms, obsessing over variations from week to week. For one thing, that time horizon is too small and the unit of measure (story point) is too unreliable to yield reliable insights.

Instead, the Kanbran app is built around time as the main metric. Time is objective, not subjective, and time improvements are true gains that benefit the business (and customers) directly. Less time means more per week (i.e. more productive).

How does that provide an alternative to story points? We need a reliable "standard unit of work" in order to make a meaningful characterization of any person, team, work item, or process. That standard could be seen as a "unit of value", in terms of actual customer usage data of some new or modified unit of functionality, but that's measured after-the-fact. Before release, a unit of functionality has "hypothetical value" to the customer, but as a unit of work, that's ok.

So, Kanbran proposed a pair of constraints that form a reliable alternative to story points: the smallest possible incremental unit of deliverable end-to-end functionality combined with a single arbitrary, small, fixed, absolute, enforced time limit on time-to-deliver any unit of functionality across all planned features.

How can that work? Imagination has no boundary, and we can talk ourselves into larger and larger features and projects, but they are all composed ultimately of these small, atomic units of functionality. So, by going small, in the opposite direction, we eventually hit a limit. Such small units yield many more data points and form a much more sound basis of measurement.

Likewise, by setting an inviolable time limit, we challenge our thinking as product and development work progresses on a given feature, to reconsider breaking it into even smaller units in order to not risk going over that time limit.

How do we set a reasonable time limit? Monitor several weeks of production after first adopting the "unit of functionality" approach, then set the limit where your data shows that 99% of work items were completed by. As your process improves, your data might show you can reduce it even further.

The idea is that the smaller time limit, the better, since it places the lowest possible upper bound on what are inherently variable work items produced by actors and processes with availability over time that are also all subject to some degree of variability. By squeezing that variability down within the smallest possible bounds, the average time to produce a unit of functionality will be small and stable, and our extrapolations will be more accurate.

Kanbran takes the pull-based, WIP-limited, process-oriented approach of the Kanban method, then goes beyond it to optimize software development organizations (not just the developers) using their own tracked data to form a realistic model of their process and those team members acting at each stage and then to create accurate, statistical forecasts of delivery dates and throughput volumes as a range value consistent with a specific percentage of statistical uncertainty (risk).

Kanbran gives real-time decision support every time a team member needs to decide what to do next, and each recommended decision is optimized according to custom criteria selected by the organization based on what it wants to maximize.

The longer teams use Kanbran, the more data is available and the more accurate the model and predictions become, allowing teams to accurately characterize their capacity and team size needs relative to desired production level.