Tag Archives: kanban

Magnetic White-Board Kanban Card Options

Just some quick ideas for Kanban whiteboard magnetic card options from a question I answered on Reddit.

Here is the best lean solution: Trying Out My Agile Kanban Board from Jon Miller.

kanban board with magnetic whiteboad cards

Magnetic kanban board from Jon Miller.

Why, well mainly I am kidding about it being the best, but if you don’t read his Gemba Panta Rei blog you should! Go add it to your RSS feed reader, before you continue with this post.

Ok, welcome back. In addition to thinking his blog is great the solution from his blog is very flexible and easy – though it isn’t quite a packaged solution (as asked for on Reddit). Also that post provides some good insight into the thinking behind the board (as well as how to create your own).

More links with kanban board options: Magnetic whiteboard cards (50-pack) – Physical Taskboards – I think just magnetic symbols (not magnetic white board card) but could use magnet with icon to stick paper to the board

Another silly site, that sells some sort of solution, blocked my access because they don’t sell in the country my computer reported being located in. So I didn’t give them a free plug (assuming their product was decent which it might be?). Very dumb design if you ask me; well even though you didn’t ask, I told you anyway.

Localization that impedes users rather than helping them seems far far too common in my experience. Mapping (and related – find closest…) uses are about the only localization stuff I find useful – country based localization I nearly always find annoying or crippling. And showing my location on a map is totally awesome (especially as I travel around as a tourist – or really in whatever capacity). Such bad design and poor usability decisions cost companies money.

Avoiding Tragedy of the Commons for Software Development

Kanban and Tragedy of the Commons

The “Tragedy of the Commons” archetype often manifests itself through “Shared Services”, when a small number of people with specific skills, work across different teams. Each team in isolation gets benefit from the Shared Service, but when demand for the service exceeds its capacity, then nobody benefits. At a smaller scale, a team with a low “bus factor”, or a hero, can also suffer from a tragedy of the commons, when too much work is dependent on a single person.

One of the comments on this post suggested that the tragedy of the commons wasn’t an accurate description. My comment:

I think the “tragedy of the commons” analogy works. As long as the users don’t have pay for use (or decide to prioritize) the danger exists for the abuse. So if you have a developer team and everyone just gets to dump tickets on to them and then whine if they don’t get what they want, when they want, I see the analogy as accurate. If people can just treat a resource as though it was suppose to just serve them and the resource is overwhelmed I see that as tragedy of the commons.

There are many ways to manage that problem (some manager deciding the priority for example). Then you may have other problems, but may avoid the tragedy of the commons scenario (in reality this setup is often done, but most don’t accept the prioritizations and just expect the development team to get everything done – which means you don’t avoid the tragedy of the commons problem).
Continue reading →

Assigning Story Points to Bug Fixes

Agile software development has teams estimate the effort to deliver requests from the product owner. The estimates are done in points (in order to abstract away from hours – as estimates have plenty of variation in how long they will really take). Then the teams capacity (velocity) is determined based on looking at how many points they complete in a “sprint” (a set length, often 2 weeks). Then the product owner can prioritize all of the requests with an understanding of how much effort each is estimated to take and the historical capacity of the development team.

I think it is good to add point estimates to bugs. It may well impact how bugs are prioritized – if it is known to be simple a program manager may say, yes I want these 6 first then… If then know the first 2 are likely to take a bunch of time, they may think, ok, I am not going to get these 4 for awhile… They might just accept that, or may wish to shift more hours to bug fixes this sprint. Or they might say well if it is that big an issue maybe we could do x instead…

In practice I rarely has us estimate emergent bugs we are going to fix in the current sprint, but we do it for bugs that are in the backlog. I sometimes will have us estimate a current bug if I think it is may take significant time – to help determine what we really want to and what the impact may be on the teams output for the sprint. We do not have many emergent significant bugs so it isn’t much of an issue for us.

We do have more difficulty accurately estimating bugs, compared to new stories, but we still provide actionable estimates (they are not perfect, but are usable).

We use agile software development principles at work and they have been a great help in letting us be much more effective than we had been previously. The discussion of priorities and delivery expectations are much improved by such methods I believe. And unrealistic expectations can be reduced. For various reason, without adopting some form of agile/lean… software development methods the common pattern I see is software developers being frustrated by unrealistic expectation of their customers (project managers…) being frustrated by failure to communicate what it is reasonable to expect and status updates. A big part of this is the failure to acknowledge variation (and the related difficulty in estimation). Agile/Kanban… are systems that take the variation into account, and therefore the variation is dealt with as natural instead of leading to bad outcomes for developers and their customers.

Response to Should story points be assigned to a bug fixing story.

Annual Management Blog Review: Software, Manufacturing and Leadership

In my contribution to the 3rd annual management blog roundup I will take a look at 3 blogs: Dennis Stevens, How to implement “Lean Thinking” in a Business and the Three Star Leadership Blog. This year 14 management bloggers contributed to highlight over 40 blogs, be sure to check out all the posts.

Dennis Stevens

Dennis Stevens writes a blog of the same name focused on agile software development principles with a strong focus on Dr. Deming’s ideas and lean thinking.

What’s Deming got to do with Agile – “Deming is not about manufacturing. He is about showing management how to create an environment for success. Deming is about culture – and his System of Profound Knowledge creates an environment that is especially effective for knowledge work… In knowledge work, where products are invisible, impact can be difficult to demonstrate. Kanban clearly shows progress and demonstrates the contribution of each person to the delivery of value. Additionally, PDSA provides opportunities for everyone to contribute to improving the quality of the organization’s capabilities.”
Kanban Mental Models and Double Loop Learning – “the Kanban cycle supports continuous learning that the team internalizes. Argyris’s model gives us some insight into why Kanban teams are consistently achieving double-loop learning and rapid maturity.”
We are Doing QQ All Wrong– “Developers should be using tools that support automated unit testing and only checking in code that passes all their unit tests… Test driven development or test just after development should be ubiquitous – but it is not. Continuous Integration environments that ensure that each check-in results in a valid and testable platform help teams perform integration and build validation.”
Shorten and Reduce Variability in Lead Times Using Kanban – ” identify and leverage strategies like reducing waiting, reducing rework, making work ready, defining small size work, and swarming, to improve lead time. Tracking causes of defects and blockages can help make decisions to focus these strategies appropriately. Reducing lead time duration and variability will result in increased predictability, faster feedback, improved flexibility and responsiveness.”

Tracey Richardson

Tracey Richardson writes the How to implement “Lean Thinking” in a Business blog focused on the lean manufacturing and the Toyota Production System.

Common Mistakes when we are Problem Solving – “Not utilizing the ‘Power of the gemba’,–or often referred to as “Go see the work/process“.!! I often see teams working together in a room trying to solve the problem by using their experiences, hypothetical guesses, and what their opinion is. I quickly disperse the huddle to “go-see” with their own eyes the current situation.”
How many different types of A3’s are there? – “I will briefly describe the 4 different types of A3’s and when to use them based on my experience: Problem Solving A3, Proposal A3, Status Report A3, Strategic Planning A3. All A3’s should follow the PDCA thinking regardless of which type you are working on.”
Why is asking “Why” so important? – “It is important to ask why repeatedly when visiting the gemba to determine what is current happening versus what should be happening. In many cases we stop at a symptom to the problem because we are often pressured for results and quickly solving the problem without going past the symptom seems to be the best answer.” [this one is actually from 2009 but I included it anyway – John]

Continue reading →

No True Lean Thinking or Agile Software Development

“There is no true value of any characteristic, state, or condition that is defined in terms of measurement or observation.” – Dr. W. Edwards Deming.

The value depends on your operational definition.

Once you operationalize management ideas in a real organization it necessarily should have differences from how it is operationalized elsewhere. As Deming said there are no effective simple recipes for management. It is one of the frustrations people have with Dr. Deming: that there is no cookbook telling you what you should go do as a manager. You need to understand things like: interactions, variation, psychology, systems thinking, how we know what we know (and what we “know” that isn’t so). And then you need to make decisions about how to apply these concepts in your organization.

There is value in being able to think and discuss ideas in a broader context than your organization. You lose a great deal of learning opportunities if you can’t. And having common idea about what common principles a lean thinking organization or agile software organization should have is helpful I believe. That is aided by abstract ideals of these management practices.

One of agile’s guiding principles is individuals and interactions over processes and tools. I am a Deming follower and that emphasizes the importance of process and system. The words in agile are anti-process. But in my experience it is really a specific type of process – and that is basically idiotic adherence to process that the software developers are sick of. This attitude is best summed up in Dilbert. There are plenty of what I would call process in the practice of agile – sprints, kanban, work in process limits, define what done means, using user stories, retrospectives, build in quality… Basically I think it is important to understand what the principles mean, but don’t get locked into dogmatic ideas.

There are principles that seem to me necessary to, for example, consider an effort as lean management. There must be respect for people in lean management. If it isn’t there, then I don’t think it is lean. It might be management using some ideas and tools from lean, but it isn’t lean management. Exactly how respect for people is manifest is up to the organization. The same thing holds for other principles.

Thoughts on No True Agile, No True Lean, No True Latte

Continue reading →

Kanban In Software Engineering

Kanban in Action [the broken link was removed]:

The kanban system allows us to deliver on my 3 elements of my recipe for success: reduce work-in-progress (in fact it limits it completely); balance capacity against demand (as new CRs [change requests] can only be introduced when a kanban card frees up after a release); and prioritize. We hold a business prioritization meeting once per week with vice presidents from around the company. They get to pick new CRs from the backlog to allocate against free kanban cards. This forces them to think about the one, two, or three most important things for them to get done now. It forces prioritization.

Another interesting application of management improvement concepts in software development by David Anderson.

Single Piece Flow

Single Piece Flow [the broken link was removed] by Rich Weissman:

The transition from batch and queue to lean manufacturing involves converting to single piece flow…

In traditional manufacturing, specific operations were done in batches by departments that specialized in individual manufacturing tasks like machining, welding, assembly, and test. Through the integration of lean induced cellular manufacturing processes, cross-trained employees produce just the amount of completed products that are required by other internal operations or the end customer. By eliminating complex set-ups, buffer stock, and large batches, lean companies are able to reduce lead times, increase flexibility, reduce inventories, and improve product quality.

More lean manufacturing and lean thinking articles

Management Glossary, lean terms: Takt Time – Kanban

Types of Pull Systems

Pull Systems Must Fit Your Production Needs [the broken link was removed]:

Mixed Supermarket and Sequential Pull System

The supermarket and sequential pull systems may be used together in a mixed system, also known as a C-type pull system. A mixed system may be appropriate when the 80/20 rule applies, with a small percentage of part numbers (perhaps 20%) accounting for the majority (perhaps 80%) of daily production volume. Often an analysis is performed to segment part numbers by volume into (A) high, (B) medium, (C) low, and (D) infrequent orders. Type D may represent special order or service parts. To handle these low-running items, a special type D kanban may be created to represent not a specific part number but rather an amount of capacity. The sequence of production for the type D products is then determined by the method the scheduling department uses for sequential pull system part numbers.