Archive for September, 2009

Launched Sept 2009

Gov 2.0 University begins on September 29th & 30th at LMI in Tyson’s Corner, Virginia.  Modus Cooperandi has been working with Hinchcliffe & Company and LMI to create a cutting-edge curriculum that focuses on how to employ 2.0 technologies, patterns, and practices. Courses are already scheduled into 2010. The university includes personal briefings for high ranking officials, two day managers’ seminars, and five day practitioner courses.

World Bank in Washington DC

Modus Cooperandi is excited to announce our upcoming personal kanban project, where we will use our Personal Kanban techniques in a directed exercise with knowledge workers from around the world.  From the 21st through the 25th of September, Jim Benson and Tonianne DeMaria Barry will be working with The World Agroforestry Centre and the World Bank to lead their Capacity Building Program on the Opportunity Costs of Reducing Emissions from Deforestation and Land Use Change (OpCost) Writeshop, at the World Bank Institute in Washington D.C. The intent of this directed exercise is to create a comprehensive technical document. As small working groups and as a unified team, participants will use personal kanban to maintain project coherence and track completion. The project is expected to achieve rapid release of a highly technical product by knowledge workers from around the world.  The multi-lingual, multi-disciplinary group will benefit from personal kanban’s visual controls and work flow.

We will be blogging and tweeting about the event as it unfolds.

Photo: Brixton

Enterprise 2.0 in Zurich

On the 2nd of November, 2009, Jim Benson will be teaching Enterprise 2.0 as part of Somesso’s Leveraging Corporate Social Media in the Finance Sector event in Zurich, Switzerland. The Enterprise 2.0 track is part of our on-going strategic partnership with Dion Hinchcliffe and Web 2.0 University.  Using Dion’s courseware, Jim will be teaming with a German counterpart to tailor the materials to the European financial community.

Photo: BeatKüng

Instant Karma: Due Out Q4 2009

Coming Soon, Instant Karma: 10 Principles of Social Media for Business

Buy Scrumban!

Buy your own copy of  Scrumban

Corey Ladas’ groundbreaking paper “ScrumBan” has captured the imagination of the software development world. Scrum and agile methodologies have helped software development teams organize and become more efficient. Lean methods like kanban can extend these benefits.

Kanban also provides a powerful mechanism to identify process improvement opportunities. This book covers some of the metrics and day-to-day management techniques that make continuous improvement an achievable outcome in the real world.

ScrumBan the book provides a series of essays that give practitioners the background needed to create more robust practices combining the best of agile and lean.

PAY NO ATTENTION TO THE MAN BEHIND THE CURTAIN!

What is the curtain? 

The enterprise is the curtain.

In concurrent posts, SocialText’s Michael Idinopulos discusses killing pilot projects and the true nature of Enterprise 2.0. He explains:

Enterprise social software isn’t one application. It’s a range of collaborative modes that includes blogs, wikis, micromessaging, personal dashboards, collaborative spreadsheeting, and social bookmarking.

When Michael discusses killing pilot projects (small rollouts as proofs of concept), he is spot-on in saying that the real value inherent to those types of projects is borne of network effects, not in the efficacy of the technology. So pilot projects = proving the tech and not realizing the business value.  It would be like if I told you I wanted to know what University life was like, and you suggested I speak  to a professor for a day to “try it out.”

Today, Dion Hinchcliffe compiled a list of Web OS trends.  His first one is perhaps the most important:

Innovation is one of the easiest and least risky areas that can be tapped by most organizations.

Michael and Dion’s quotations complement each other beautifully, and can be restated as:

Enterprise social software isn’t one application. It’s the realization that innovation has become the easiest and least risky way to solve problems within an organization.

Perhaps most important here is the word “enterprise.” I submit that the term has fundamentally shifted from a consolidated model to a distributed one.  The enterprise is no longer a central node with dependent groups hanging off of it. Rather, it has evolved into a network with greater nodal autonomy, faster communication, and improved decision making power.

This nodal structure was there all along. We see it in the human circulatory system, we see it in the layout of ant colonies, we see it in flora and fauna.

The hierarchic enterprise is the curtain. We have been fooled into believing that there is, or even should be, one central corporate OZ qualified to make all decisions. Over time, centralization has created costly information and decision making bottlenecks. Does this mean hierarchy is dead?  Obviously not.

Enterprise 2.0 is not a panacea, it is a tool to allow corporate structures – congested by unnecessary bottlenecks – become leaner organizations. By redistributing information and decision making, companies limit waste, reduce costs, and are afforded the freedom to innovate. Microenterprises joined as nodes to a larger enterprise have the simultaneous ability to function both independently and as part of a cohesive whole.

What this means for Enterprise 2.0 is not that it becomes the next ERP, but that it becomes a host of spot-applications or, as Michael says, collaborative modes that allow us to realize Dion’s inexpensive and relatively painless innovations.

P.S. I really appreciate Michael’s “collaborative modes” – it re-orients the conversation from one of techno-miracles to one of business process. Not what are we going to use, but what are we going do?

Blogged at Ebeneezer’s Coffee House in Washington DC.

Photo by Tonianne

Integration is Enterprise 2.0.

This week my friend and colleague Dion Hinchcliffe posted an article on ZD Net describing 14 Reasons Why Enterprise 2.0 Projects Fail. In it he paints a picture of valiant workers surreptitiously cyber-skulking on dank distributed web sites, efficiently working and making money for their companies – all the while keeping an eye out for dagger-wielding IT staff looking to keep their security models and networks digitally pure.

He’s right, this absolutely happens. I’ve seen it in small companies, government agencies, and Fortune 10 behemoths. It is beautiful.

These localized projects are the seeds of true Enterprise 2.0.

Dion’s list of 14 reasons is long, so I’ll let him tell that story (read his post). Here however, we can discuss how those “failures” might fail outright or undervalue success, but our collective definition of success may need some rethinking.

Several of Dion’s 14 (2, 3, 8, 10, 13 and 14) revolve around building Enterprise 2.0 environments that people will use and in the provision of a corporate culture in which they can be used. Another group (4, 5, 6, 7 and 11) call for a coordinated social management plan. Political buy-in is covered in 9 and 12.

Dion’s #1 reason is that solutions can end up being departmental successes, yet not work their way into the rest of the organization.

I believe in the loosely coupled aesthetic.

Those departmental successes that don’t spread to the organization (Dion’s #1 type of failure) may be the real definition of Enterprise 2.0 success.

Corporate Social Management Plans should lay out flexible and forgiving models where workers can select any application they want, and IT should provide simple APIs to connect to any relevant central data hubs. Corporate cultures should back up these plans by rewarding the active seeking out and usage of tools to solve specific problems. Workers should be empowered to use the best tool for the job at the time.

Dion is absolutely correct, Enterprise 2.0 should be about flexibility and solving problems and not about the pervasive use of specific apps across an organization.  Why? Because there is a tipping point between what is a popular application and what becomes an institutionalized application. Once we hit that tipping point, it’s no longer Enterprise 2.0.

To sum up

Enterprise 2.0 should be a structure that allows great flexibility in the choice and use of applications throughout an organization, supporting the applications with APIs to allow data to be taken from and deposited into central data stores.

And

Enterprise 2.0 currently “fails” because we are attempting 1.0 deployments of 2.0 applications.

Photo by Certified Su

When I began to write a succession of posts on personal kanban back in July, I thought a few people might benefit from the idea. I never expected that the series would attract tens of thousands of viewers to my blog, Evolving Web.

Less than two months later, there is a growing and enthusiastic personal kanban community which has been posting photos, discussing innovations, and advancing the meme.  In a few short weeks, the community grew large enough to support a dedicated web site.

So I am pleased to formally announce the launch of personalkanban.com, a blog and resource for personal kanban.  Already, about a dozen guest posters and regular contributors have stepped forward to take the meme and run with it.

Those of you who have been reading Evolving Web for a while know I’m all about community, process, and collaboration. Seeing this community form, that it’s based on a lightweight personal process, and that collaboration is already taking place is therefore an awesome birthday present for me this year.

Please give the personalkanban.com a visit and subscribe to the feed. If you have personal kanaban stories to tell, please e-mail me at jim !at! soundbag !dot! com. The community would greatly benefit from your experiences and writing. 

In the previous post, we discussed why you would want to measure your performance in Personal Kanban. Today I’ll begin with the most powerful – but perhaps most intimidating – technique. In upcoming posts we’ll look as some less intense methods,  so don’t let this post scare you.

In kanban for software design, a “cumulative flow diagram” is used to track performance. A big part of the cumulative flow diagram is its ability to visualize how close you are to completion of a large project, and where bottlenecks or waste appears in the process. It’s a very powerful and descriptive tool.

Above is the cumulative flow diagram  for the Modus Cooperandi Personal Kanban.  The diagram illustrates how many tasks we have in a given part of our workflow. This is our workflow, so you don’t need to emulate it. The components are as follows: 

Backlog: Items that have yet to make it into the workflow.

Priority 3: Items that are coming up in importance.

Priority 2: Items that are important.

Priority 1: Items that need to be done soon.

Working: Items in the process of being done.

The Pen: Items that are waiting for external input.

Complete: Items we’ve done today.

Archive: Items we’ve completed in the past.

On this particular day, we completed 96 things in the past, accomplished  2 that day, sequestered 3 in the pen, and so forth.  Of course, as time goes on, your archive is going to become bigger and bigger.  In a directed project with a finite number of tasks, this is a very important part of the diagram. For personal kanban however, where tasks will build up forever, it shows us how much we’ve done or are capable of doing.

Simply from a flow perspective though, we might want to eliminate that part of the diagram.

So here, with no archive, we can discern some interesting patterns.

First, we see where we complete some serious work. We also notice where we gain a lot more work.  So on days where there is a tremendous dip in the number of tasks, in the above chart (but no dip in the first), we know that we moved a tremendous amount to the archive.

We can also see where we build up backlog again.  So, essentially what we have here are two graphs that show us (1) we are completing work and the number of tasks completed is continuing a fairly uniform rise, and (2) we see the actual variations in our work and when we take work on.

Since the chart is a time slice taken daily at midnight, the parts of the kanban with a WIP limit should be uniform, and represented by fairly flat bands, with the only variation coming from “The Pen,” “working,” and “done.”  If we have work in the backlog, we should be maintaining a fairly even amount of work in the queue.  The diagram illustrates that we’ve been working to achieve this, and as we’ve worked more closely, the uniformity is starting to manifest itself.

What we want to avoid is having the backlog band grow at an alarming rate. We want work there to feed the queue, but if it gets too overwhelming, we then know we have to start saying no to tasks.

The time it takes to move a task from backlog to completion is called “lead time.”  The time it takes to complete a task when you start working on it is  called “cycle time.” “Work time” is how long tasks were on your board, and active.  “Wait time” is how long a task sits idle in a queue, while waiting to be moved.  In a personal kanban, you might move one or even dozens of tasks across your board in a single day, so for you these are the numbers to watch for variation. 

If at some point you notice your lead time jumps to 20 days, it’s obvious that you have too much backlog. If your cycle time jumps, something is stopping you from starting work.  If your work time jumps, something is stopping you from completing work. If your wait time jumps, something might be stopping you from working at all.

So…how do you measure this?  At the end of each day, you can track the information in the cumulative flow diagram by counting the cards in each part of the work flow, and entering them into a spreadsheet.  For the “times” you can write start and end dates on the cards, and calculate from there.

Or you can use Agile Zen - which is where these images came from – and leave the tracking up to Nate.

One cannot choose wisely for a life unless he dares to listen to himself, his own self, at each moment of his life.
- Maslow, The Farther Reaches of Human Nature

Okay, so we’ve gone through several ways kanban can look, be used, and operate. We’ve discussed ways to prioritize work. But we have yet to address how to measure (gulp) performance. But what exactly is “performance,” and why do we care?

Toyota’s Taiichi Ohno is credited with the initial deployment of kanban, and the creation of Lean and Just-in-Time management concepts. His goal was to make Toyota the world’s leader in automobile production, so he needed some metrics. Ohno understood that simple numbers did not drive performance, but that Toyota’s staff and its suppliers needed the will to work better.  

Along the way, physicist Eli Goldratt came up with the Theory of Constraints (TOC). (You can hear Goldratt say he needs 4 days to define TOC in this video.) His glowing gem of wisdom is that we conceptually overcomplicate problem solving by identifying way too many constraints to arrive at a solution. When we want to get to a goal, we tend to lose the goal from all the little issues that surround it. But, usually there are one or two big constraints that, if solved, will both provide huge results and often solve a lot of the little constraints or make them irrelevant.

The beauty of both these messages is that small changes make big differences – if they are the right small changes. What do you need to identify the right small changes to increase the will to work better? Awareness.

Personal kanban helps give us that awareness, enabling us to begin to listen to ourselves. A few posts back I discussed retrospectives, how they were vital at the beginning and became less so as we incorporated self-improvement into our normal actions. As you focus less on that massive pile of little nuisance constraints that surround you, and move instead to the high-payoff constraints, you move to what Ohno calls a “kaizen” state. You begin to continuously look for ways to improve your quality of life.

Please notice, I’m not telling you how to improve your life or even suggesting what improvement looks like. That’s totally up to you. If you want to work towards helping to save the rainforests, that’s fine. If your goal is smoking 10 cartons of cigarettes a day while watching cage fighting…well, I guess someone has to do it.  Our goals are our own. They’re not for retirement, they are for living. If you want wifi and code, you design your life to allow wifi and code.

If we can clear the big things that Goldratt calls constraints or Ohno calls waste from our plate, what’s left is a clear and open space to do some real living.

Musicians must make music, artists must paint, poets must write if they are to be ultimately at peace with themselves. What human beings can be, they must be. They must be true to their own nature. This need we may call self-actualization.

- Maslow, Maslow on Management

In upcoming posts, I will cover a few ways – some absurdly simple, others a little more complicated – for how your personal kanban can tell you some pretty amazing things about how you work. Hidden in those post-its is some pretty awesome insight.

Image: The Programmer’s Hierarchy of Needs

cc. David Flanders