You Don't Need Kanban...Or Do You?
Due dates, time loss, process flow, project estimations...Kanban can be stressful, and you might not even be doing it right. Read on for some enlightenment.
Join the DZone community and get the full member experience.Join For Free
it seems as though each and every company out there is trying to catch the agile train and, even if they don't in fact work alongside the guidelines that agile prescribes, they seem to be doing an awful lot of talking about it! if you and your team are standing your ground and saying, "this is not for us," consider if any of these problems has ever caused you and the organization significant amount of trouble.
no idea what people are doing
whether it's your immediate team members, specific co-workers, or your entire team, knowing what people are working on helps paint a better picture of what is being achieved, what is to be expected for completion soon or what's already left a certain stage, and can be picked up further down the process line.
while some people will be fine with working cut-away and autonomously from anyone else, others will quickly lose grip and half their day will be spent trying to catch up with the overall progress status.
leaving the team to get the status updates on their own is an easily avoidable waste of time and should instead be done automatically.
no tracking of process flow
if there is no way of knowing how long certain tasks took to complete, then there is also no reliable way to measure whether this was done efficiently or not. of course, quality tops speed, but there are cases where the high quality achieved can easily get devalued because of the time it took to get it.
this is just one example of how not paying attention to the process metrics can mislead you about your own team and business health.
huge time loss at resource replacement
when replacing one employee with another, there is a lot of time to be spent on initial training and introduction. imagine how much time could be saved and how much easier the new employee's first weeks would have been if you could just hand them the full, exact process that their predecessor had been following.
this can be done if the previous employee had conducted a detailed, continuous record of their work - such as a kanban board.
dead wrong project estimations
if you're already in the habit of doubling or tripling the estimates your co-workers give you, in order to get a more accurate completion date - this may be indicating a problem with either the team's estimation technique issues, or with their idea of when and how things are done. giving the team access to previous project flow gives them a better chance of correctly estimating project completion dates.
disputing the progress and results of completed work
this can be anything from not being able to remember what you've worked on three months ago to arguing over who completed which parts of a project to looking for data used in previously closed projects. without an ordered and searchable archive of work, looking for any of this type of information can lead to insanity, but not to actual data results.
due dates are hardly ever met or known
a few missed deadlines may not seem like a big problem, but missing most of them creates an unofficial policy of not even taking them seriously anymore. but if no one on the team even knows when projects or milestones are due, you can seriously stop considering your business worthwhile. making the dates known to all and visible in an easily accessible spot is a sure way of ensuring a good project pace.
if any of these have indeed been part of your team's problems (without going into any further methodological consideration about what agile is, is not, and should be), try a visual board to find out why those that start using it, rarely ever stop.
Published at DZone with permission of Anna Majowska, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.