The Power of Pull

This is a cross-post from my blog on the Military Social Networking system milBook.

I had heard of the book The Power of Pull back in October at the Army Operational KM Conference. Prior to that, there was a post on milBook about a video of a lecture by one of the book's authors John Seely Brown. I finally got around to watching the video earlier this week and was very impressed by the concept and Brown's presentation.

I will base much of this post on a document on John's website that provides an excellent overview of the material. (John Seely Brownʼs Stanford Entrepreneur's Corner Talk of April 14 2010 and Thoughts on The Power of Pull by John Hagel, JSB and Lang Davison- © 2010 Cook Network Consultants)

Even with all these great online resources, I plan to purchase the book in order to learn more on the topic.

Here is a collection of the high points from the Cook Report:

The world is broken. Business doesn’t work anymore. Across the S&P 500, return on assets is headed toward zero. Wall Street goes on an unregulated tear and tanks the economy. Washington steps in and bails everyone out pushing the deficit to unthinkable heights. A monetarily fueled recovery is knocking at the edge but once more it will be jobless. These events render pretty well impossible any future resurrection of the mass production, centralized, top down, economy-of-scale version of the petroleum fueled, assembly line based, push economy that powered the world up to the point of the popping of the internet and housing bubbles. Everyone would like to understand:‘why did all these things break?” The Power of Pull explains the seeming inexplicable.

The book’s thesis is that a ‘big shift’ from push based, mass production, top down, economy of scale kinds of organizations is taking place. The digital micro-processor, internet based economy that has matured over the past 30 years has insinuated itself into the old style companies and enabled them to make changes that squeeze more efficiency out of the old models but that is in pursuit of a diminishing returns strategy as The Power of Pull explains. It shows how the productivity enhancements of our new digital infrastructure enable what he calls creative edge that can pull the no longer productive aspects of the core to innovative projects at the edge. Edge based skunk-works transform the core in this new world.

The Shift Index consists of three indices that quantify the three waves of the Big Shift - Foundation Index, Flow Index and Impact Index - each measured by a set of indicators:

The authors presume a very fluid economy rather than static one. If new knowledge gained through productive friction is the new fuel the new raw material and therefore the new currency then, in tracking it, you have a lot more to consider than you would if you were only tracking bags of cement from the quarries to the warehouse to the construction site. Knowledge “flows.” Amplifiers of these flows are found in indices of worker passion and social media activity.

Problem solving and strategy building is a central foundation for all business. With the very complex changes brought about by the Internet and the continuing exponential advance of computing (often involving new architectures) that the authors describe throughout their entire book, the old top-down ways, “push” based ways of doing this, are no longer very productive.

The authors say that the on going practice of business depends both on accessing resources and attracting new people and their passions. Doing this is of little value unless coupled with a third set of actions "that focus on driving performance rapidly to new levels. These practices involve participation in, and sometimes orchestration of, something we call “creation spaces” -- environments that effectively integrate teams within a broader learning ecology so that performance improvement accelerates as more participants join." [p.18]

To quote the authors: “we need to marry our passions with our professions in order to reach our potential... Passion in this context refers to a sustained deep commitment to achieving our full potential and greater capacity for self-expression in a domain that engages us on a personal level. As we make our passions of our professions, we may find our dispositions shifting ... Rather than dealing change as a threat and something to be feared we will find ourselves embracing change, recognizing its potential to drive us to even higher levels of performance.” [p. 21-22]

The new world that is emerging is one made almost inevitable by the technology but it is also a world where information is used very differently than in the pre-internet world. It is shared but the sharing is done with reciprocity. If the recipient doesn't get something in return eventually the sharing ceases.

The scalable efficiency of the 20th century (pre-digital) corporation is fundamentally at odds with the way that knowledge flows in an internet connected world. It creates a world where rewards, on the one hand, are gained by capturing, hoarding and controlling stocks of knowledge. This conflicts with the digitally enabled ability to use the new Internet based tools to capture, duplicate, distribute and create new information. In the 20th century economy rewards are based on hoarding and hierarchy rather than on problem solving. The closed proprietary model needed to protect the old style corporation helps to ensure that benefits of new tools and technologies are tied up in keeping people bound to old closed proprietary systems where lawyers are used to protect fortresses and kingdoms and to bar the creation of new wealth, this return on assets goes down because emphasis on billing systems and maximum extraction from “customers” goes up.

The digital internet creates alternative models and delivery mechanisms that permit disintermediation of corporations that spend money fighting change. The economy of scale in a pre-digital age becomes diseconomy of scale leading to the declining return on assets noted above.

All of this has a tremendous implications to the theory and practice of Knowledge Management. With knowledge flows being a key ingredient in a pull economy, the people that can put efficient processes in place to leverage the technology to outperform other organizations are the ones that are going to be successful. Another key part of KM that the concept of Pull affects is the idea of KM practitioners are going to be important agents of change. The transition from Push to Pull and the attendant Big Shift are going to require the ability to effectively manage change, and that is going to fall to the KM personnel in many cases. 

While most of the examples given throughout the Power of Pull material center around the Corporate world, these concepts are just as applicable to the Government and the Military. Fostering the "creation spaces" mentioned above is important for all types of organizations. Collections of passionate, talented individuals are going to form into the teams that will ensure organizational success.

This is just a general, brief overview of a very important concept. I anticipate posting more on this topic as I continue to study it. Once again, the Cook report cited above is an excellent source for more information.

On a totally unrelated topic, there is an online community for Federal Wave (FedWave) located here. You must apply for membership first at APAN.org. I will approve all reasonable requests for group access.Thanks to those of you who have already joined. FedWave and Apache Wave may be another transformational technology that could enable the Big Shift.

This has been a good year for me blog-wise as this is my 33rd post- a personal best. I know this isn't one of the most popular blogs on the Internet, and I do appreciate everyone that takes the time to read my online musings.

I wish you a wonderful 2011.

Mark

Novell Vibe- The Latest in Enterprise Collaboration

This is a cross-post from my blog on the Military Social Networking system milBook. I have also started a new blog on the new online space for FedWave here, which is restricted access for the time being.  

As a reminder, there is an online community for Federal Wave (FedWave) located here. You must apply for membership first at APAN.org. I will approve all reasonable requests for group access.

Novell Vibe is a new enterprise collaboration offering from Novell. Vibe is the combination of the Novell Pulse and Novell Teaming projects. It incorporates the Wave Federation Protocol in order to foster inter-operation with systems such as Apache Wave/ Wave in a Box (open source version of Google Wave) and SAP StreamWork.Vibe Beta was rolled out at the Enterprise 2.0 Conference on November 9, 2010. Here are some of the articles on Vibe that were published in conjunction with the announcement.

Novell revealed on November 22nd that it was being acquired by Attachmate. This should not affect Vibe product development.
This blog post will give a brief overview of the system. This is not a commercial endorsement for Novell or Vibe, but I will use their promotional material and documentation in different places throughout this post.

The Vibe User Guide definition: Novell Vibe cloud service is a real-time collaboration Web application that unites common communication, authoring, and social messaging tools. You can use Vibe to share documents, jointly have digital conversations, and interact through social media. At present, Novell only plans to offer Vibe in a Cloud version (Software as a Service -SaaS). An on-premise version is provisionally on the product roadmap for 2011.

The basic components of Vibe are as follows:

1. Profile/ Feed: One of the central pieces of Vibe is the user profile. This is a core concept in all Social Media, and Vibe does a good job combining profiles with enterprise authentication/ authorization (see also below).

When you first launch Novell Vibe, you see the Home view, which consists of the following sections:

As evidenced by the image, Vibe has a simple interface that should be easy for most users to understand and manipulate. Another important concept in Vibe is the idea of feeds, with your personal feed being where you can provide status updates similar to other Social Media tools (see also below). Also, Vibe can be configured to provide notifications on various types of activities using email or other methods.

2. Messaging: Messages are the method to communicate with other Novell Vibe cloud service users.Depending on who you want to view your message, Vibe enables you to send messages in various ways.To communicate on a broad level to all Vibe users who are following a given person (see below), a message can be sent to that user's personal feed.Like e-mail, Vibe enables you to send messages directly to specific users. When you send a direct
message, only message recipients can view the message.A message can be sent to a group by posting a message on any group feed. Users can combine these different modes as needed to get messages to desired combinations of users.

3. Following: Individuals can follow users and groups that interest them. When following users and groups, the most recent messages from those users and groups are displayed in the BigList. Depending on the user’s permission settings, they might need to approve followers. These followers can be organized in a variety of ways configurable by the user. This is another characteristic of Social Media addressed in Vibe.  

4. Groups: Groups in Novell Vibe cloud service consist of various users who share a common purpose. Many aspects of groups are configurable by users, and permissions can be set for various group members. Permissions define who can do what in connection with the group.Users can have a variety of roles in a group, such as administrator.

5. Working together in real time: Novell Vibe cloud service enables you to see when other users are online, when they are away, and when they are offline. Knowing when users are available makes real-time collaboration more efficient.Vibe enables multiple users to simultaneously edit the same message. Gadgets can enhance the functionality of messages, making them more rich and useful.

6. Find and Organize Information: Novell Vibe cloud service provides various ways that to organize user data.Tagging functionality in Vibe enables users to create different types of virtual containers for messages. Like using folders in e-mail, information can be categorized, and then retrieved and reviewed at a later time. Important messages can be marked with a star. Users can then filter the BigList to display only messages that have been marked with a star. Tables of contents enable individuals to create links to messages in the Vibe site. You can create tables of contents on a personal profile page, or on a group profile page. There are also various ways to filter and view messages based on multiple criteria.

7. Managing Files: Novell Vibe cloud service enables users to upload, share, and manage your personal and group files. Documents can be tagged and organized in different ways, and can be the subject of messages using functionality mentioned earlier. 

8. Selectively Limiting Access to Information: Some users might find that the default access rights in Novell Vibe cloud service are too open. They can limit access rights to messages and groups. In general all messages that are posted to a personal feed are visible to all users who are currently following that individual. Furthermore, users can edit messages if they are direct recipients of the message. There is a capability to send a private message to one or more Vibe users. This ensures that only those users you specifically send the message to are able to read it. In addition, users can make messages not editable. Only the message creator is able to edit the message. By default, all files that are added to the Files tab in the Home view are visible only to the user. One user cannot generally view another user’s files. When creating or editing a group, users can restrict access to the group by setting up the group permissions. There are properties that restrict who can see the group, who can follow the group, who can contribute to the group, and so forth.By default, anyone in the organization or anyone a user is currently following can follow that user. This setting can be changed to require users to get permission before they are added to the follower list. Also by default, anyone in the organization can send messages directly to a user, unless they modify a setting restricting this activity. All of this is very important to Enterprise and Government users.

However, one of the key attributes of Vibe is its ability to foster collaboration between different organizations. Vibe leverages the Wave Federation Protocol to provide interoperability with Google Wave, Apache Wave, SAP Streamwork, and other emerging Wave-based technologies. This has already been demonstrated in this video
that shows both how a typical use case for this inter-organization collaboration and how it looks from the user perspective. This will allow large organizations using an Enterprise system such as Vibe or StreamWork to work effectively with small entities using the open source Apache Wave or a similar system.

Again, this does not constitute a commercial endorsement of this product, and is strictly the opinion of the author. Please post your questions or comments below, and thanks for reading.

Apache Wave Proposal (Apache Incubator)

This is a cross-post from my blog on the Military Social Networking system milBook. I have also started a new blog on the new online space for FedWave here, which is restricted access for the time being.  

As a reminder, there is an online community for Federal Wave (FedWave) located here. You must apply for membership first at APAN.org. I will approve all reasonable requests for group access.

The Wave in a Box project has submitted a proposal to the Apache Foundation to be admitted into the Apache Incubator. The proposal itself is located here, and an extract follows below.

Abstract

Apache Wave is the project where wave technology is developed at Apache. Wave in a Box (WIAB) is the name of the main product at the moment, which is a server that hosts and federates waves, supports extensive APIs, and provides a rich web client. This project also includes an implementation of the Wave Federation protocol, to enable federated collaboration systems (such as multiple interoperable Wave In a Box instances).

Proposal

A wave is a hosted, live, concurrent data structure for rich communication. It can be used like email, chat, or a document.

WIAB is a server that hosts waves. The best analogy for this is a mail server with a web client. WIAB is comprised of a few high-level components: the client and the server. They have the following major functionality (though this is not an exhaustive list):

• Client
  • A dynamic web client for users to create, edit, and search waves. Users can access this client by directly visiting the server in a browser.
  • Gadgets provide the ability to insert, view, and modify the UI -- exposing the Wave Gadgets API (http://code.google.com/apis/wave/extensions/gadgets/guide.html)
  • A console client that can create and edit waves via a command-line-like interface.
• Server
  • Hosts and stores waves. WIAB comes with a default storage mechanism. The administrators of the server may configure it to use alternative storage mechanisms.
  • Indexing, allowing for searching the waves a user has access to.
  • Basic authentication, configurable to delegate to other systems.
  • Federation, allowing separate Wave in a Box servers to communicate with each other using the Wave Federation Protocol (http://www.waveprotocol.org/federation).
  • Robots, using the Wave Robots API, (http://code.google.com/apis/wave/extensions/robots/) may interact with waves on a WIAB instance.

Background

Wave expresses a new metaphor for communication: hosted conversations. This was created by Lars and Jens Rasmussen after observation of people's use of many separate forms of communication to get something done, e.g, email, chat, docs, blogs, twitter, etc.

The vision has always been to better the way people communicate and collaborate. Building open protocols and sharing code available in an open and free way is a critical part of that vision. Anyone should be able to bring up their own wave server and communicate with others (much like SMTP).

We hope this project will allow everyone to easily gain the benefits of Wave with a standard implementation of Wave – in a box.

Rationale

Wave has shown it excels at small group collaboration when hosted by Google. Although Wave will not continue as a standalone Google product, there is a lot of interest from many organizations in both running Wave and building upon the technology for new products.

We are confident that with the community-centric development environment fostered by the Apache Software Foundation, WIAB will thrive.

Initial Goals

The initial goals of the project are:

1. To migrate the codebase from code.google.com and integrate the project with the ASF infrastructure (issue management, build, project site, etc).
2. To quickly reach a state where it is possible to continue the development of the Wave In a Box implementation under the ASF project.
3. To add new committers to the project and grow the community in "The Apache Way".

Current Status

The open source Wave in a Box project has existed in various forms for approximately 16 months (starting out life as the FedOne open source project).

FedOne began in July 2009 in order to accelerate adoption of the wave federation protocol, and serve as a proof of concept that a non-Google implementation of the wave federation protocol could interoperate with the Google production instance. It worked. FedOne's existence lead to a prototype by Novell that demonstrated federation between Google Wave and Novell Pulse (now known as Vibe). In addition, in May of 2010, SAP unveiled a prototype version of SAP StreamWork that federated with both Novell Pulse and Google Wave. All three systems interoperated, sharing real-time state, and gadget updates. In May 2010 Google released significantly more code (including the cross-browser rich text editor) to connect with other components that were built from scratch, resulting in a simple web client.

The project has grown over the last year to include many Google and non-Google contributions. The project has picked up steam in recent months as the direction of the standalone Google Wave product has shifted. At this time the Wave in a Box project enjoys very active development, with new features and functionality being added almost daily. The first Wave Protocol Summit was recently held and included developers from a variety of countries, companies, and organizations.

The code base is a mixture of mature core code from Google Wave, and somewhat immature integration code forming WIAB. WIAB is quickly becoming highly functional and is already in a very "demoable" state. The development mailing lists are very active indicating wide community support. We recognize that now is a good time to migrate to the Apache Foundation while the codebase and community is a manageable size. Assuming the current momentum continues, we expect strong growth in the code and community in the near future.

Meritocracy

The initial set of committers includes many Google employees, and there is an active and growing community outside Google contributing to WIAB already today. Google culture itself encourages meritocracy, and the community has always grown – and will continue to grow – in this fashion.

As shown by the initial committers list below, several members from outside of Google have already demonstrated interest, skill, and commitment to contributing to the project. These individuals have been recognized on those merits by the initial committers. Their selection as the first wave of new committers is a sign of the burgeoning meritocracy.

Community

Wave currently has a healthy community around waveprotocol.org, with conversations hosted at http://groups.google.com/group/wave-protocol. We plan to move this community to the Apache Software Foundation incubator.

Core Developers

The initial committers comes from a variety of backgrounds and includes many from Google. There are a few existing Apache committers amongst this initial group. We anticipate early future committers coming from places like Novell, SAP, companies related to the US Navy's usage of wave, startups in the wave ecosystem, and many independent individuals.

Alignment

The developers of WIAB want to work with the Apache Software Foundation because Apache has proven to provide a strong foundation with good infrastructure and support for developing projects in an open community. As WIAB continues to grow, the community will look to both reuse available Apache projects as well as look for opportunities to contribute back to the larger Apache community.

Known Risks

Orphaned products

Wave is a new means for communication, and thus it is still maturing. While the initial implementation (Google Wave) did not gain sufficient traction for it to continue as a standalone Google product, there are other related projects (e.g. Novell Vibe, SAP StreamWork), and several startups in the space that are continuing to build on the technology. In addition, the US Navy has contracted with four companies as part of evaluating using wave technology on every ship. The community itself is still growing, with several new contributors recently added.

Inexperience with Open Source

The initial committers have varying degrees of experience with open source projects. Many from the community are familiar with open source.

Homogeneous Developers

The initial set of developers does include many from Google. However, the project has accepted many patches from independent individuals, and some have already gained committership. Several companies have expressed interest and forty individuals participated in the Wave Summit.

Reliance on Salaried Developers

Following Google's change of focus for Wave in August, some of Wave's Google developers have chosen to continue working on Wave, but it is imperative that we continue to grow the community larger in the coming months.

Relationships with Other Apache Products

We currently use the following libraries from Apache

• Commons CLI
• Commons Codec
• Commons HttpClient
• Commons Logging
• Velocity
• Ant

We've also contributed the Wave Gadget implementation into the Apache Shindig project.

Documentation

Entry point for documentation of all the specs and designs. http://waveprotocol.org/

Wave Robots API http://code.google.com/apis/wave/extensions/robots/

Wave Gadgets API http://code.google.com/apis/wave/extensions/gadgets/guide.html

Initial Source

The initial source will come from http://code.google.com/p/wave-protocol/source/browse/. This consists of the Java code necessary for the client and server. These are already open source repositories licensed under the Apache Public License.

Source and Intellectual Property Submission Plan

Beginning with the initial unveiling, Google published a liberal patent license:

Subject to the terms and conditions of this License, Google and its affiliates hereby grant to you a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as stated in this License) patent license for patents necessarily infringed by implementation of this specification. If you institute patent litigation against any entity (including a cross-claim or counterclaim in a lawsuit) alleging that the implementation of the specification constitutes direct or contributory patent infringement, then any patent licenses for the specification granted to you under this License shall terminate as of the date such litigation is filed.

http://www.waveprotocol.org/patent-license

Trademarks

Google retains all rights to the trademarks "GOOGLE WAVE" and the wave design logo, neither of which will be used in the Apache Wave project.

External Dependencies

In addition to the previously mentioned Apache dependencies, the initial code relies on the following libraries that have Apache compatible licenses:

antlr, aopalliance, asm, bouncycastle, cglib, dom4j, emma, gson, guava, guice, gwt, gxp, hamcrest, jackson, jdom, jetty, jline, jmock, joda_time, jsr305, junit, libidn, mockito, mongo-driver, oauth, protobuf, protobuf-format-java, protostuff, stringtemplate, websocket, whack, xpp3

Cryptography

We use standard crypto library methods available in java.security.*. Wave federation plans to uses encryption for sending deltas to remote Wave servers.

Required Resources

Mailing lists

• wave-dev
• wave-commits
• wave-private

It is possible that if the project does grown to include many sub project that we would split the mailing list up by sub project. Again we have flexibility.

Subversion Directory

https://svn.apache.org/repos/asf/incubator/wave

Issue Tracking

Please help us setup a JIRA instance for both issue tracking and code review.

Other Resources

• a wiki (for the sites pages) (http://incubator.apache.org/guides/sites.html or a wiki http://wiki.apache.org/incubator/)
• code review on reviews.apache.org
• a server to run a dogfood instance
• continuous build bot

Initial Committers

• Alex North (Google)
• Anthony Watkins (SESI)
• Christian Ohler (Google)
• Dan Danilatos (Google)
• Dan Peterson (Google) 
• David Hearnden (Google)
• David Wang (Google)
• Ian Roughley (Novell) 
• James Purser
• Joseph Gentle
• Lennard de Rijk
• Michael MacFadden (Solute)
• Soren Lassen (Google)
• Tad Glines
• Torben Weis (University Duisburg-Essen)

Sponsors

Champion

• Paul Lindner

Nominated Mentors

• Santiago Gala
• Ben Laurie
• Upayavira
• Brian W. Fitzpatrick (emeritus on the Incubator PMC)

Sponsoring Entity

The Apache Incubator.

Comments are being sought on the proposal at this time. Please post questions or comments regarding the blog entry below.

UPDATE: Wave was accepted into the Apache Incubator on December 3, 2010. This will be the subject of a subsequent post.

HyLighter- Advanced Document Collaboration

This is a cross-post from my blog on the Military Social Networking system milBook. 

HyLighter (www.hylighter.com) is a new technology that has some unique and very useful functionality.This blog post will give an overview of the system and some of potential use cases. This is not a commercial endorsement for Hylighter, but I will use their promotional material in different places throughout this post. 

Today, it is common to have documents that require input from 10, 20, 30 or more contributors. The most common practice for managing document reviews for large groups is for the owner of the document to send out emails with attachments to contributors. Each contributor makes changes and adds comments, usually with track changes, and then emails the file back to the owner. The owner has the time-consuming and frustrating task of maintaining version control and reconciling all the changes manually. Once complete, the owner recycles the draft for another round of reviews.

HyLighter is an easy to learn web annotation and hypermedia system for collaborative analysis and review of documents. Supported file types include HTML, Word and, soon, images, PowerPoint, PDF, and Excel. In general, Web annotation systems enable users to add, modify or remove information from a Web resource without modifying the resource itself. The information can be thought of as a layer of annotation displayed on top of the existing resource. Depending on how the owner of the resource configures permissions, users who share the same annotation system can see all or parts of the annotation layer.

The name, HyLighter, is a combination of the terms hypermedia + highlighter (i.e., a felt-tip pen which is used to draw attention to sections of documents by marking them with a vivid, translucent color). Hypermedia refers to graphics, audio, video, and text that are intertwined through hyperlinks. A user following hyperlinks is said to navigate or browse the hypermedia. The most familiar example of a hypermedia system today is the World Wide Web which is a system of interlinked hypermedia documents contained on the Internet.

What is unique about HyLighter as a Web annotation and hypermedia system is that it enables almost any number of reviewers to engage in threaded discussions tied to selected locations or fragments within a document in an organized and efficient manner. It also enables users to copy a Uniform Resource Locator (URL) for any annotation (i.e., a highlighted section of a document and associated commentary and other metadata) to a clipboard in order to (a) send or post a link to a selected annotation to one or more individuals through various applications for exchanging information over the Internet (e.g., chat, instant messaging, microblogging, and email) and (b) create a link from a selected annotation to one or more annotations within the same document or a different document either on the same machine or different machine(s).

In addition to creating a bridge between social networking applications and specific locations within various file types, HyLighter has public APIs available for integrating with content management systems and other types of applications. For example, HyLighter offers a plugin for SharePoint that enables a user to push a document from a SharePoint library to a browser with HyLighter installed. Once the review activity is completed, HyLighter provides various mechanisms for analysis of input and editing in Word or other native application and checking the document back into the SharePoint library for maintaining version history.

HyLighter is straightforward to use. Simply import the document into the system (or use something like the SharePoint plugin shown above), access the document using a browser with the proper plugin, and begin editing or making comments. For example:

The key to the technology is the use of XML and XHTML that allows for the formation of the annotation layer mentioned above. There are also many other ways that the XML in HyLighter can be leveraged, such as metadata, and other integrations with XML-based technologies. While the use of HyLighter and Google Wave had been discussed (and Wave is mentioned in the HyLighter literature) it has not been actively pursued. 

HyLighter solves three major challenges that are relevant to expertise location and knowledge mining that are not adequately addressed by any other available technology. The challenges:

- How can large groups of reviewers (that is, 5-50 or more) engage in collaborative discussions tied to specific sections of a document or source in an organized and efficient manner?

- How can the potential of collective intelligence or crowd sourcing be harnessed to increase the value of existing content?

- How can knowledge workers collaboratively link related ideas and objects together or “connect the dots” across increasingly large repositories of unstructured data in order to make associations, discover patterns, and create new knowledge and innovations?

Here are some potential use cases for HyLighter:

- Policy Creation: Most organizations have a need to create policy documents, especially in Government. There is usually a review and approval process when writing policy, in addition to multiple authors of the content. HyLighter would allow for many authors and reviewers, and it automatically creates an audit trail for changes on the document.

- Technical Writing: This seems a logical use for the system. Often technical writing requires peer review or input from multiple experts, and HyLighter would allow for these individuals to easily review and/or provide input on specific parts of a document.

- Proposal Management: Writing proposals is another natural use case for HyLighter. Collective authoring and review is generally a requirement when writing proposals. Having different authors and reviewers for each section of the proposal is much easier to manage with HyLighter. 

- Training: HyLighter can be used for both training development (collaborative creation of content and programs of instruction) and also as part of the learning experience where learners can interact with instructors on collaborative online documents.

- Enhance capabilities of wikis and blogs: Sometimes on wikis and blogs there is content that lends itself to a collaborative effort. Placing links on the original site to a HyLighter document allows for the development of the content in a more organized fashion than most Social Media systems.

- Support online communities of learners and practitioners: Online social networks around specific areas of interest can benefit from HyLighter in that they can use the system to collaboratively create content to enhance the building of knowledge on the specific topics involved.

There are trial instances of HyLighter accessible from their website, and there is also a military-focused test instance as well. The technology is sophisticated and the best way to understand it is to give it a try.

Again, this does not constitute a commercial endorsement of this product, and is strictly the opinion of the author. Please post your questions or comments below, and thanks for reading.

FedWave Update

This is a cross-post from my blog on the Military Social Networking system milBook. I have also started a new blog on the new online space for FedWave here, which is restricted access for the time being.  

Three months have passed since Google announced that they would discontinue development on Wave. From my post in August:

On August 4, 2010, Google announced that they were going to discontinue development on Google Wave. This came as a surprise to much of the community of users and supporters of Wave, and sparked an outpouring of commentary on the topic in the Blogosphere. These postings included how Google doesn't do Social Media, how Google botched the rollout of the system, and how Google did the right thing by cutting their losses. All of these missed one point: the value of the technology itself.

In these three months, the Wave in a Box project has made impressive strides, with the current version looking much like the main Google product (see also below). There is still a lot to do, but much has been accomplished. In addition, all the information has been consolidated in one place. This project is moving fast, as the plan is to have a fully functional open source WIAB server ready for general release by the end of 2010. I will continue to monitor (and contribute) and will post updates like this one on a regular basis. 

The FedWave effort has made progress as well, with a Working Model of FedWave now operational in a limited mode. More information on this working model is in the FedWave group located here. You must apply for membership first at APAN.org. I will approve most requests for group access.

This virtual space is designed to facilitate online collaboration between different government agencies and with non-government entities as well. It has many different capabilities including blogs, wikis, document upload, and others. I selected this platform to enable collaboration with a wide group and to consolidate information in one place online. The site is a little sparse now, and I would welcome contributions and content.

Here is a current screenshot of the Working Model: 

FedWave Working Model as of 4 Nov 2010

I have let a long time pass between posts, but I will work harder to post more frequently. As always, please enter your questions and comments below.

Wave in a Box (WIAB) and FedWave

This is a cross-post from my blog on the Military Social Networking system milBook. 

On 2 September 2010, Google announced the way ahead for the open source version of Google Wave, now called Wave in a Box (WIAB).

Here is a quick summary of features for WIAB from that announcement:

• An application bundle including a server and web client supporting real-time collaboration using the same structured conversations as the Google Wave system
• A fast and fully-featured wave panel in the web client with complete support for threaded conversations
• A persistent wave store and search implementation for the server (building on contributed patches to implement a MongoDB store)
• Refinements to the client-server protocols
• Gadget, robot and data API support
• Support for importing wave data from wave.google.com
• The ability to federate across other Wave in a Box instances, with some additional configuration

The implications of this for the fledgling Federal Wave (FedWave) project are still being examined, but this could be a significant shortening of the way for this project.

I have been in contact with the Google team working WIAB, and below is a list of non-functional requirements provided to them that relate to the FedWave project. The requirements and the following response from Joseph Gentle (Google) were posted to the forum (list) on the Google Group for the Wave Protocol here:

1. CAC enabled (Government Smart Card w/ Certificates):
2. Army Knowledge Online (AKO) and Active Directory authentication:

These should be quite easy to implement.

The planned authentication system has 2 parts: An authenticator, which provides the client with a signed token, and a verifier, which verifies the validity of the token. I'm looking at using an RSA key pair to generate & sign the tokens. The verifier will be bolted deeply in fedone. For this, what we need is multiple authenticator implementations. Each implementation needs a copy of the signing key,
and a way to talk to the client (to authenticate it, and if its authenticated give it a token).

The first implementation of that will be a simple password check. I don't know anything about LDAP or smart cards. But it will be quite easy for someone who does know that stuff to hook it up.

3. Usable with mobile clients (iPad, iPhone, Android)

There are projects to make native clients for ipad, iphone and android. Others on this list will know more.

4. Automated installation/ Operation on Windows and Linux Servers:

The plan is for a totally hands-free installation that does everything except for federation. Federation will require a TLS certificate signed by a trusted party and an XMPP server (which could be bundled). We haven't looked in depth at making an installer. I imagine its not too difficult. Maybe someone on this list can help us out here?

5. Security/ Standards:
a. Encryption: Client-Server (SSL) and Server-Server (PKI): The ability to protect data in transit is important.

Tick. The client-server protocol will use SSL with a signed certificate. The server-server communication is authenticated as well, though I don't know the details there.

b. Authorization: once authenticated, users should only be able to access authorized waves/wavelets/blips. This would probably be done using the authentication system in some manner.

Yes. Not done yet, but it will.

c. No use of Google Web Tools (GWT)or other unapproved code: Don't take this the wrong way, but many of the Government security types are totally set against anything that uses GWT. They contend it obfuscates the underlying code and could be an attack vector into the system.

This is a hard one. At the moment the entire web client is written using GWT. We plan to make splash (a lightweight non-gwt client) work with fedone, though live typing doesn't work in splash. (There will be a lot of work to make this happen).

If this is super important to you guys, it might be worth making a native wave client, or waiting until native wave clients are made by 3rd parties.

d. Servers with full STIG (Security Technical Implementation Guides): STIGs are just settings on the server that lock down specific ports, protocols, and portions of the system in question for maximum security. They can cause things to not work, but have to be followed as much as possible or exceptions must be sought.

I don't know what that is, but making a document detailing which ports need to be open and whatnot should be easy to write.

e. Use approved Federal Government XMPP

There's no presence / XMPP-based chat support in WIAB. This is surprisingly difficult to implement.

6. Full code review/ test throughout development: This is more of a going-forward concept, but it is important from a security standpoint to make sure no "sleeper" code gets onto Government networks.

Pre-commit code reviews are standard google practice. We are doing code review for all new code added to fedone.

Fedone (and hence wave-in-a-box) code reviews take place here:
http://codereview.waveprotocol.org/

7. Full Presence/ Awareness (XMPP):
8. Email integration (in and out):
9. Embed waves in portal pages:

None of these things are planned for v1.0 of wave-in-a-box. I think they're all important, but not critical to having a working product.

10. Robust Search: The ability to search through waves and across federated servers for keywords and tags is important.

Search will work, but there's no current plan to make full-text search work across federated servers. (You will be able to search any wave that you have been added to explicitly, but public waves hosted on other servers won't appear in your search results).

11. Archive/ persistence of waves:

This will be done. Further, all operations are signed in the database(so archives will be tamper proof).

Thanks to Joseph for responding to my post. He has been very helpful. If there are other non-functional requirements I missed, please post a comment and I will add them to the list.

There was an office hours session with the Google WIAB team on 15 September 2010 and there was a lot of good information shared. They are making steady progress on the code, but there are still a lot of things the team has left to accomplish, including authentication, among others.

Informational Links:
The Google Group for the Wave Protocol is here.
The 20 Sep 2010 WIAB Status Report is here.
The WIAB task list is here.
The list of starter projects is here.

All the documentation has been consolidated on the Google Wave Federation Protocol site.

Note: many of the URLs in this post require a Google login and group membership to access.

The next step for FedWave is to install a working model of the FedOne server, so that WIAB updates can be deployed as development goes forward. I will be blogging that on milBook as I do the installation.

Thanks for your patience as I have assembled this post. I look forward to your comments and questions.

Forge.mil: The Government Version of SourceForge

This is a cross-post from my blog on the Military Social Networking system milBook.

The US Federal Government has created a family of services to support technology development in the Department of Defense (DoD) called forge.mil. According to the site, forge.mil is a collaborative environment to accelerate the development and deployment of dependable software and services within DoD.

Much of this post will be based on an overview presentation available on the site titled "Forge 101: An Introduction to Forge.mil".

The Forge.mil Vision is to enable the rapid development, test, certification, deployment and acceptance of new products and services on the Global Information Grid (GIG) by providing policies, processes, tools and a federated development and test infrastructure. Forge.mil is intended to provide a collaborative environment for developers, testers, Warfighters and other stakeholders for the rapid development, testing, certification and deployment of software.

Top level support for this idea is starting to take shape. In the National Defense Authorization Act for FY2010, Congress has called for the DoD to ‘develop and implement a new acquisition process for information technology systems’ – one designed and based on early and continual user involvement, rapidly executed incremental capability, early prototyping and open systems. The Forge.mil environment is perfectly suited to meet these goals.

To build a toolset, Forge.mil initially focused on the development community.  Software developers were the ones least likely to be involved in the ongoing program management and software acquisition process. The capability that exists in Forge.mil today is centered on software development, software version control, code management, and release management. The core product Forge.mil is built on is CollabNet TeamForge.

There are two types of tools in Forge.mil today:

1. Development Tools (Source Code Management, Trackers for Requirements, Bugs or Issues, Change Requests, File Release Management, Task Management and Real-time Reporting
2. Communication Tools (Project wiki pages, Discussion Forums and Document Management)

One of the greatest features this set of tools provides is the ability to relate software builds with the requirements met or bugs fixed in each of these builds.  The ability to associate artifacts within the same tool set allows users to associate:

•  A Document with a task (create training manual by a certain date)
•  A Tracker with a discussion post (a user requirement that needs clarification)
•  A File commit with a bug tracker or requirement tracker (commit new code that fixes a bug or fulfills a requirement)

Artifacts – documents, requirements and bug trackers, software builds and releases – are visible and accessible to the test community, the IA community and other program and project stakeholders.  This visibility and availability of program information is key to successfully working with distributed teams.

Forge.mil is available to U.S. military, DoD government civilians and DoD contractors for Government authorized use. Access to Forge.mil requires a valid DoD Common Access Card (CAC) or a PKI certificate issued by a DoD approved External Certificate Authority (ECA) with a DoD government sponsor.

The first offering launched in April 2009 was SoftwareForge.  The goal for SoftwareForge was to model the best of the open source communities in terms of doing collaborative development and bring that into the DoD by offering the same set of capabilities and enable the same set of approaches that have been driving successful open source projects. SoftwareForge enables the collaborative development and distribution of open source software and DoD community source software.

After SoftwareForge rolled out, there were project teams stating they had a need for the same toolset for projects and teams that were unable to operate in the open.  They wanted the same tools in a private project space.  ProjectForge provides the same application life cycle management tools to DoD projects and programs as SoftwareForge, but for projects that are not doing DoD community source development and/or need to restrict access to specific project members.

The following criteria are used by the community/project review committee when determining whether a project is appropriate for the SoftwareForge site: Project has an Open Source or DoD Community Source license Project is not a ‘fork’ OR a 'mirror' of an existing external Open Source project If a fork is required (e.g. - security reasons), will be evaluated case by case Project must accept ‘DoD internal public/open’ view permission Project must be willing to consider contributions (code, docs, patches, etc.) from participants outside of their team Project should not be a duplicate of an existing project on the site The goal of the project adjudication process is not to deny or make it difficult for new projects to be created. Ideally, if the new project criteria are adhered to, project approval can be done in less than 48 hours (depending on the number of requests in the new project queue). This process is designed to ensure the usefulness of SoftwareForge for both developers and consumers of software.

The plan currently is to use this for the FedWave development effort, if other conditions are met (Sponsorship, approval, etc.).

I believe this is an exciting advance in Government software development and should be very beneficial. As always, the opinions expressed here are strictly my own, and I welcome your comments.

Google Wave is Dead... Or Is It? A Potential Way Forward

This is a cross-post from my blog on the Military Social Networking system milBook.

On August 4, 2010, Google announced that they were going to discontinue development on Google Wave. This came as a surprise to much of the community of users and supporters of Wave, and sparked an outpouring of commentary on the topic in the Blogosphere. These postings included how Google doesn't do Social Media, how Google botched the rollout of the system, and how Google did the right thing by cutting their losses. All of these missed one point: the value of the technology itself.

At this point I need to make sure to mention that the biased opinions expressed here are strictly those of the author, and do not represent the position of the Government or any company that is doing business or may do business with the Government.

As I have looked over all of this and thought about the implications, I am not so sure that Google abandoning development of Wave is a bad thing. The Federal Wave project (FedWave), which is intended to introduce Wave into the Government, was never going to use the Google product based in the Cloud. Instead, the plan is to leverage the open source version of the system called FedOne. It has been slow going, but the effort continues to stand up a server on a closed development environment (called RACE) on the Military network.

Even though Google has given up on Wave, other large companies have not. Novell Pulse development continues, and the company had this to say about their commitment to Enterprise collaboration. SAP continues to develop their Wave-based product StreamWork, and had this to say about Google's decision.One conclusion that can be drawn from this is that the Wave protocol can be an excellent basis for interoperable collaboration between disparate systems, and several large tech companies see this.

In addition to large companies sticking with Wave, there is also a grassroots movement out there called, appropriately enough, Save Google Wave. There is a Facebook page, Google Group, Twitter feed and waves on the topic. Very interesting to note that I am not the only believer in this technology, and also not nearly the most passionate.

On a more practical level, there is an informal group forming called the The Wave Consortium that is looking at the future of Wave and how the open sourcing of the platform and protocol could happen. I am participating in the Consortium in order to represent the interests of potential Government users (and developers) and promote FedWave to the greater Wave community.

That all being said, here is a proposed potential way forward, which I am choosing to call the FedWave Manifesto (for now):

1. The Google Wave platform, and the Wave Federation Protocol have the demonstrated potential to enable interoperable collaboration in Joint, Interagency, Intergovernment, and Multinational environments (including commercial) known as JIIM+. Federal Wave (FedWave) will leverage this technology for use in Government.

2. Government-centric use cases and user stories need to continue to be developed and extended in order to prioritize and direct FedWave development efforts. Sponsoring agencies will be able to influence the direction this development effort takes based on committed resources.

3. FedWave will be Government sponsored Open Source Software that will be developed in a collaborative manner, utilizing approved tools such as SoftwareForge.mil and the DISA RACE environment. Security and usability will be built in, not bolted on. User suggestions and feedback will be an integral part of the process as Agile Development methodologies will be used whenever possible.

4. As the overall Wave community continues to organize and evolve, FedWave will remain a participating member of this larger group in order to make sure the Government's requirements are represented as the Wave platform and protocol matures.

This is only a first cut at a manifesto, and I would like feedback so this can capture collective wisdom. 

I hope this post will encourage discussion (and dissent) on this topic. Again, this is only my opinion, and I am very passionate about this technology.  Please comment below as you are so moved. Thanks for reading.

More Reasons to Use Google Wave

This is a cross-post from my blog on the Military Social Networking system milBook.

This will be the second of a series of posts that will look into use cases for Google Wave (or more specifically FedWave, which is the effort to use Wave in the Federal Government). While these use cases will have a military/ government focus, they have much in common with other articles that cover uses for Google Wave (here, here, and here).

NOTE: this and subsequent posts on this topic are strictly the opinions of the author, and do not represent any official Government policy or endorsement, nor are endorsed by any entity that is or may do business with the Government in any capacity.

Assumptions and Warnings:
- Not all the functionality shown in the following use cases is fully developed
- Some existing Wave features are not available in open source version of Wave (FedOne) including attachments and many extensions. 
- The use cases are for illustration only, do not represent any official sanction of the technology or its use by the Government in any form
 
Here are some more use cases, based on milBook comments/ contributions in response to my earlier post:

7. Task/Initiative Management: A simple management tool to track small projects, initiatives, or actions that do not require a full project management tool

8. Staff Action Tracking: Items that need to be endorsed by multiple staff sections can be collaboratively reviewed in order to see the comments or thoughts put together by another office and could collaborate on responses and reduce email overhead

9. Operations Center: Update briefings can be created and kept current in real-time for briefing senior leaders; being able to coordinate and collaborate using rich media will provide a clear common operational picture that is available to a multitude of organizations using trusted connections


I will expand on these and the first six use cases in subsequent posts. 


Thanks for your participation in the process, and please continue to let me know what you think about this.

Why Use Google Wave?

This is a cross-post from my blog on the Military Social Networking system milBook.

This will be the first of a series of posts that will look into use cases for Google Wave (or more specifically FedWave, which is the effort to use Wave in the Federal Government). While these use cases will have a military/ government focus, they have much in common with other articles that cover uses for Google Wave (here, here, and here).

NOTE: this and subsequent posts on this topic are strictly the opinions of the author, and do not represent any official Government policy or endorsement, nor are endorsed by any entity that is or may do business with the Government in any capacity.

By way of review, here is a synopsis of one of my earlier posts:

Definition: Google Wave is a product that could replace email, instant messaging, and threaded discussion using a collaborative platform and an open-source protocol.
- Product: Currently Google hosted
- Platform: Includes Extensions, bots, etc.
- Protocol: Facilitates having independent Wave servers on any network, but still able to federate over a single port

Assumptions and Warnings:
- Not all the functionality shown in the following use cases is fully developed
- Some existing Wave features are not available in open source version of Wave (FedOne) including attachments and many extensions. 
- The use cases are for illustration only, do not represent any official sanction of the technology or its use by the Government in any form

1. Joint Use Case: Targeting
All information and approvals for target execution in one place on the Network that can be edited in real-time by multiple users

2. Interagency Use Case: Significant Activities (SIGACTs)
Effective Real-time and Time-Delayed Collaboration across multiple-networks for information gathering, analysis, and response

3. Intergovernmental Use Case: Border Enforcement
Real-time multiple-echelon and multiple-network collaboration to coordinate response to border incidents

4. Multinational Use Case: Simultaneous translation coupled with event planning
Use of simultaneous translation extensions to facilitate event planning such as a G8 or G20 summit

5. Social Media Integration (VIP Social Media)
Authoritative capture of official communications via non-Federal controlled systems such as Facebook, Twitter, or other Web 2.0 apps

6. Secure Messaging
Replacement of aging E-mail (SMTP) based organizational messaging systems with a platform that inherently supports a similar authority model and meets the criteria of multi-author, multi-destination authoritative organizational messages

In subsequent posts I will expand on these six FedWave Use Cases and provide an example of each.

Please let me know what you think about this. I have to admit that I am less than objective about this new technology, as I believe it is truly revolutionary and has tremendous potential. If you have other use cases, please share them in the comments, and I will look at adding them to my unofficial list. As always, thanks for reading.

Overview of Citrix and Virtualization Technology

Citrix Systems (www.citrix.com) is a leading provider of technology for virtualization of applications and servers. The company was formed in 1989 and its name is a portmanteau of Citrus (the original name of the company) and UNIX. It had over $1 Billion in revenue in 2009 and employs over 4800 worldwide. Citrix is headquartered in Fort Lauderdale, Florida.

Andreas Krebs authored an excellent brief overview of Citrix technology in the All Covered Learning Center:

In 1995, Citrix introduced the world to virtualization with NT 3.5 WinFrame, an application virtualization solution.  Later, they offered NT 4.0 Terminal Server, a desktop virtualization solution.  As the founders of virtualization technology, Citrix is the company that many businesses recognize and trust for their virtualization solutions.

Server Virtualization
XenServer is Citrix’s no-cost server virtualization solution that gives small and medium sized businesses an affordable and effective way to adopt an enterprise-class technology.  Unlike other server virtualization solutions, XenServer provides premium grade features for free.  Benefits include the following:

• XenServer supports an unlimited number of servers, virtual machines and physical memory.
• XenServer includes a conversion function will allow you to convert a virtual server into a physical server and physical server into a virtual server as needed.  (Other server virtualization solutions will charge you for this feature.)
• Shared SAN and NAS storage between server hosts maximize available storage on the network.
• All virtualized servers can be accessed and maintained from a single location.
• In the event of server failure, affected virtual machines are automatically restarted on other production servers.
• A library of pre-configured virtual machine templates make it easy to rapidly create a test or production environment.
• Centralized patch management makes it easy to keep virtual servers updated.
• Easy migration of virtual systems to from one host server to another makes it simple to maintain host servers.
• XenServer is open-source and takes advantage of the intellectual contributions of thousands of users, hundreds of companies and partners.
• XenServer is compatible with most server hardware that is currently available.

Desktop Virtualization
XenDesktop is Citrix’s desktop virtualization solution.  As an on-demand service, XenDesktop will deliver a Windows desktop to any user, anywhere.  Features include the following:

• XenDesktop users can access their desktop and corporate applications from any PC, Mac, thin client or smart phone.
• XenDesktop gives users a computing experience that rivals a local PC, even when using Multimedia, 3D graphics or VoIP-integrated applications.
• Each desktop is customizable to meet the performance and security needs of individual users.
• XenDesktop will work with your existing hypervisor, storage and Microsoft infrastructures—you don’t have to spend more money buying compatible programs.

Application Virtualization
XenApp is Citrix’s application virtualization solution that allows users to directly access Windows applications from through a desktop computer or web browser.  Benefits include the following:

• Windows applications can be accessed on devices that have non-Windows based operating systems—more than thirty operating systems are currently supported.
• This solution requires that only one virtualized copy of an application such as Office 2010 be installed and maintained, while allowing any number of users to access and use it as if it was locally installed.
• Applications can be streamed directly from the host server for users working on the corporate network or remotely.  Permissions can even be set up to allow users to download and access apps while offline.
• Virtualized applications function as if they are locally installed.
• Application delivery and access is customizable for each user and their preferred device, network and typical access location.

Virtualization Management
Essentials for XenServer is an add-on enhancement that complements XenServer by providing additional features and integrated management capabilities for server, desktop and application virtualization.

• One-click access to native storage makes device management simple.
• Automated high-availability protection will move virtualized machines from a failed host server to another physical server.
• Automated management of lab infrastructures decreases the complexity, time and cost of managing non-production environments.
• Automated workload balancing will move virtual servers to hosts with more available resources based on pre-configured policies.

There are many use cases for Citrix virtualization, including the standardization of desktops, the delivery of legacy applications, enhanced security, being able to deliver a uniform user experience on a variety of different platforms, and others. These all enable lower total cost of ownership and other benefits to the organizations that deploy virtualization technologies.

This post is a very brief overview of Citrix and virtualization technology. The Citrix website is an excellent place to learn more about this important technology.

Thanks for reading.

Introduction to Kanban

The purpose of this post is to provide a general overview of the practice of Kanban in software development and its relationship to Scrum. There is a lot of great material available on the Web on Kanban, and one of the best of them is this article: Kanban Development Oversimplified. The main website for Kanban is here. For comparison purposes (and for reference) review my post on Agile Development.

This is a discussion and definition of Kanban from Karl Scotland:

"While the word Kanban comes from the Japanese for “visual card”, the term Kanban as used by the Kanban Software Development community, represents much more than a standard task-board. Additionally, the Kanban Software Development community have not tried to replicate the mechanism of the Toyota Production System kanban tool exactly, but have taken the underlying principles in order to achieve similar effects in software development. So what is a Kanban System for Software Development?

A Kanban System visualizes some unit of value. This unit of value could be a User Story, Minimal Marketable Feature, Plain Old Requirement or something else. This is different from a task-board, which generally focuses on visualizing the current tasks.

A Kanban System manages the flow of these units of value, through the use of Work In Process limits. This is different from a task-board, which generally has no WIP limits, but aims to have all tasks complete by the end of a time-box.

A Kanban System deals with these units of value through the whole system,from when they enter a teams control, until when they leave it. This is different from a task-board, which generally only deals with the work in the build/test stage, but shows no information about what work is being prepared, or what work is ready for release.

By putting these 3 properties of a Kanban System together, we can describe a Kanban System for Software Development as one which allows value to flow through the whole system using WIP limits to create a sustainable pipeline of work. Further, the WIP Limits provide a mechanism for the Kanban System
to demonstrate when there is capacity for new work to be added, thereby creating a Pull System. Finally, the WIP Limits can be adjusted and their effect measured as the Kanban System is continuously improved.

A task-board simply shows what development tasks have been predicted to be done in the current time-box, with their status."

Kanban fills a niche in the world of Agile Development in that it provides a system to control the flow of work where the development team has other duties (production support, multiple projects) and cannot work in dedicated Scrum Sprints (Agile iterations). Kanban allows for teams and individuals to work on specific units of value and advance them through the various stages based on WIP limits.

Here is a great story from the  Kanban Development Oversimplified article that illustrates some of the key pieces of Kanban:

"You’ll find a lot of terminology in Lean software development comes from Japan and from the Toyota Production System in particular. Kanban translated literally: “Kan” means visual, and “ban” means card or board.

Picture yourself on a Toyota production line. You put doors on Priuses. You have a stack of 10 or so doors. As you keep bolting them on, your stack of doors gets shorter. When you get down to 5 doors, sitting on top of the 5th door in the stack is a card — a Kanban card — that says “build 10 doors.” Well it may not say exactly that — but it is a request to build exactly 10 more Prius doors.

You pick the Kanban card up, and run it over to the guy who builds doors. He’s been waiting for you. He’s been doing other things to keep busy while waiting. The important thing here is that he’s NOT been building Prius doors. He takes your Kanban card and begins to build doors.

You go back to your workstation, and just a bit before your stack of doors is gone, the door guy comes back with a stack of 10 doors. You know that Kanban card is slid in between doors 5 & 6. You got the doors just in time. The whole thing sorta works like magic. Only you wish you had the door-building job. That guys seems to have a lotta free time on his hands.

Kanban cards are used to limit the amount of inventory the factory builds. It doesn’t do the Toyota factory any good to build doors faster then they can assemble cars. It just wastes money on excess doors, and parts of doors. Excess work in progress is considered to be waste in Lean manufacturing. (It’s probably waste in non-Lean manufacturing too.) In the above completely made up example, you’ll never have more than 15 finished doors hanging around. (Mudha is Japanese for waste. Learn it to impress your Lean friends.)"

The article goes on to the more practical aspects of the process:

"Kanban thinking in software development attempts to do a similar thing. We want to limit unnecessary work in progress to be no higher than it needs to be to match the throughput of the team. Kanban thinking applied to Agile development results in sweeping changes that throw out much of what Agile practitioners consider necessary practice.

In Kanban development:

• time-boxed development is out
• stories are larger and fewer
• estimation is optional or out completely
• velocity is replaced by cycle time

By now you should be scratching your head a bit. Exactly what’s left of Agile if we get rid of time-boxes, change the meaning of stories, and stop measuring velocity. And, exactly what do car doors and Kanban cards have to do with software development?"

A key component of Kanban is the visual board that is used for managing work in process. Most of the time it is a physical board similar to this one:

This board was reconstructed from photos of boards used at Yahoo.

There are also online versions of Kanban boards such as LeanKit Kanban and Kanban Tool. The key is to use some type of information radiator so that everyone can see what is on the board and what the status is. Seeing the flow is also important so and bottlenecks can be identified and cleared out. It is important to set limits for each stage in the process as this will govern the flow of cards from point to point.

All of the columns should be customized to the team and the project being worked on. There are several aspects of Scrum that need to be upheld, especially in the area of collaboration and communication. Just because there isn't a defined iteration schedule does not mean that the software is not demonstrated and planning meetings are not needed. These are scheduled at some interval so that the customer gets to see working software and the team is able to work together to keep the flow moving. Regular review of the process (similar to the Scrum Retrospective) is also done as part of Kanban. There are other aspects of Scrum and Agile that the team can use as part of this process. Again, customization of the process is encouraged.

This is a very brief overview of one of the emerging software development methods. Please access some of the references on the Limited WIP Society website for more in-depth information.

I hope you found this interesting and informative. Please post questions and comments below.