Asynchrony Solutions Blog

Kanban: It Changed My Life

by on February 8th, 2012 at 5:52 pm

Well, maybe not my life, but my project’s life.  A bit reading and patience will allow me to explain.  But first, a definition of the word: Kanban.

kanban |ˈkänˌbän| – noun

a Japanese manufacturing system in which the supply of components is regulated through the use of a card displaying a sequence of specifications and instructions, sent along the production line.

“Now wait.  We are not in Japan, and we are definitely not a production line.” Understood, however we can take this system and apply it to our practice.

Kanban in practical terms is best described with a picture.

We have multiple queues drawn by string, or marker on a whiteboard, or imaginary (it depends on the project).  Each queue represents a phase of our development process.  A new project, for example, may have the following queues: Waiting, Code In Process, Code Complete, Acceptance Testing In process, Acceptance Testing Complete, Ready for Customer Review, Ready for Production.

As requirements, from our client or customer, are recorded, they are written onto story cards and placed into the Waiting queue.  When someone begins working, that person picks up the first card and moves it over to the next queue to begin Coding.  When the story has been completely coded, it goes to Code Complete so that the person who provides acceptance testing can pick it up and begin working on that story.  This process continues to happen until it reaches the end.

Stories get worked on from the right side first, so that it can reach completion as fast as possible.  This provides the most efficient and focused flow of progress.

 Just in that brief description, I have covered a bunch of topics we deal with when working on a project:

  • Recording, prioritizing, and tracking customer requirements.
  • Showing progress of work in progress.
  • Communicating when something is complete and ready for the next phase of the development process (Acceptance Testing).
  • Providing visibility for when work is running out and new requirements are needed from the customer or client.

Kanban provides a ton of invaluable assets, as a system, to your project.  Such as: efficiency, focus, communication, limit work in process, prioritization, visibility on status.

We also limit work in process (WIP), because work in process is considered waste.  It is considered waste because it, at the state of being work in process, is unusable code.  If at any point in time the customer says “Let’s change priorities completely” or if for some reason the project finished prematurely, the incomplete code is wasted.

We apply WIP limits by restricting the number of stories that can be in a particular queue.  If you can’t move a queue forward because the WIP limit is already full, you are forced to either clear the queue ahead or find someone who can.  This is very important because it prevents the project from consuming a block in flow of progress.

Our primary Kanban consists of the following queues.  Feel free to use the exact same queues for your project but beware that every project is different and requires a different kanban.  Pay attention to the pain of your project, start simple and adjust based on that pain.

  • Backlog
  • Waiting (limit 3 features)
  • Code In Process (limit 3 stories)
  • Code Review Ready (optional, limit 1 story)
  • Code Review In Process (optional, limit 1 story)
  • Quality Acceptance Ready
  • Quality Acceptance In Process
  • Quality Acceptance Complete
  • Feature Waiting for Stories (limit 3 features)
  • Feature Ready for Customer Review
  • Release Waiting for Features
  • Release Ready to be tested on Staging
  • Release Ready for Production
  • Released to Production
When building your Kanban, remember the definition.

a Japanese manufacturing system in which the supply of components is regulated through the use of a card displaying a sequence of specifications and instructions, sent along the production line.

Your project’s development cycle is a production line.  In order to get the most quality and the most work completed think about work in process, notice where stories have the longest cycle time (time a story spends in a given queue), which queue fills up too fast (perhaps you need more resources to satisfy that queue, or you need a greater WIP limit).

If you are developing cars, you want as many completed, high quality cars as you can build.  You don’t want 500 windows, 200 doors, 6 handles, 3 mirrors and 1 car.  Same goes for developing an application.  You don’t want 10 features in process and 1 feature completed; you aren’t guaranteed time to finish the work in process.

I hope this post was useful to you. I would love to get some feedback.

This post is the first in a series I plan on publishing about how Kanban changed my life.  Check in to see the additional posts. I will also update this post with links.

Tags: , , , , , ,

Design Rule 5: What they want isn’t always what they want.

by on November 1st, 2011 at 3:10 pm

Be careful what the client wishes for.

Yellow is in this season

Tags: , ,

Establishing a Baseline for Organizations’ Enterprise Architecture, Portfolio Management, and Enterprise Governance

by on September 28th, 2011 at 10:24 am

Myles Bogner, Ph.D, VP Research and Development
with Special Asynchrony Guest Jason Carter, President of Aegis Strategies

As organizations embark on improving their Enterprise Architecture, Portfolio Management, and Enterprise Governance efforts, a frequent question tends to be, where are we now?  Below we offer a set of questions to guide the creation of an “as-is” assessment around these three areas.  We’ve categorized these questions into seven broad categories.

Governance

  • What are your governance bodies, documents, and processes?
  • How are IT investments prioritized and funded across your enterprise?
  • What are the guiding principles that you would like to achieve through enterprise governance?
  • Are your governance organizations formally chartered; where are they?
  • Is there an IT governance process for routine requirements different from a strategic IT governance process?
  • Does your community of lead architects come together regularly in a forum; is this forum chartered?
  • Is there a formal tie between the enterprise architecture and engineering communities; if so, what is the concept of operations?
  • Is there a formal tie between your organization and any external communities of interest; if so, what are the governance charters?
  • Is there a formal enterprise architecture configuration and control board; if so, is it chartered and executing?
  • Is there a prescribed methodology for software development across the organization to ensure secure, timely delivery?
  • Are the organization’s architectural rules succinctly captured?
  • Is there a configuration control board around a common computing environment; is this chartered?
  • Specifically for government organizations, what are the governance procedures for ensuring Clinger-Cohen Act compliance?

Information

  • Is there an enterprise data group established; if so, is there a common vocabulary and a prescribed way for sharing information?
  • How is data quality being addressed as an enterprise-wide focus?
  • How are system information needs and data flows categorized?
  • Are there any standard message templates in use; how are these governed?
  • Is there common reference data; if so, which system(s) provide it and how is it governed?

Business

  • Does the enterprise share the same vision; is this captured in an easy to understand graphic?
  • What are enterprise’s defined capabilities, and have they been decomposed into tasks, conditions, and standards that have broad organizational agreement?
  • Are the lines of business defined; is there enterprise consensus on this?
  • What are the activities performed that support the enterprise capabilities and lines of business?
  • Are there clearly identified enterprise functions that cross lines of business?
  • What are the enterprise architecture touch-points to external architectures?
  • Is there a formal way to capture business processes in a consistent, industry standard manner; are any captured?  How are these business processes linked to information flows, performance metrics, and governance bodies?

Performance

  • What are the enterprise performance categories and metrics from both operational and technical aspects; which organizations have authority for these metrics?
  • Is performance actually measured and used to drive improvements?

Enterprise Initiatives and Enabling IT Systems

  • How does the CIO office convey user and architectural needs to project managers and how are these managers held accountable for delivery?
  • How do project managers know that they are in alignment with the enterprise architecture?
  • What redundancies exist across systems from functional and technical perspectives in the enterprise; how are these being addressed?
  • How are projects assessed from an operational, technical, and financial perspective; what are the results?

Service

  • How are enterprise web services implemented and governed; is there a roadmap for the upcoming enterprise services?
  • What are the enterprise web service management tools and processes; how many systems are utilizing these today?
  • What standards guide web service development?
  • Is there an enterprise service-oriented architecture infrastructure established; what are the tools and selection criteria utilized for these tools
Technical
  • What are the enterprise standards for technical refresh and software selection; are these governed enterprise-wide?
  • Is there a plan to move each of the systems to a shared platform such as a common user interface; what platform has been selected and what is the transition schedule?
  • What is the vision for the enterprise to move toward cloud computing; how is this vision conveyed to others?
  • How are enterprise user authentication and account management solution(s) implemented and governed in the portfolio?

Once an enterprise establishes its baseline, these same set of questions can be prioritized and utilized by the organization as a spring-board to implementing a robust enterprise architecture and portfolio management practice.

Tags: , ,

Newer Posts | Older Posts