The top-level purpose (the “why”) of the LSS is, as it says on our website, “to improve the world by improving its systems.” In broad terms, the approach we encourage is to deploy this “why” into “how’s” by applying systems thinking within the Lean (e.g., value- and people-centered) paradigm, under all system contexts. System contexts are often composed of other systems that are even more human-centered and complex than the main systems on which we are working. So they too are key to effective systems work.

To help fulfill our main purpose and its “how’s,” we decided from the beginning to have our Board and Community Council drawn from among our Fellows. This means that the people tending LSS operations come in vetted as knowledgeable and effective systems workers. It’s a different orientation than the typical one of taking leaders from a pool of management-oriented MBA’s.

Using primarily systems instead of business people (though we do have a couple on the Board who wear both hats; who have their own commercial companies outside the LSS) is a two-edged sword. On the plus side, it means the Board members have enough understanding of how systems work that we can apply systems thinking to the LSS itself. So we are “drinking our own KoolAid®” by making the LSS work better as a system.

On the minus side, as an incorporated non-profit we must all still navigate through many of the same management instruments that MBAs have been doing since their late-night study groups at Business School…and by now do routinely in their sleep. Tasks get distributed across the Board, not just to those of us with significant business experience, so we wouldn’t claim to be as fast at this on the whole as MBA-based organizations. 

Having a Board of systems people has another positive effect though. We look at  business-planning instruments  through the lens of systems thinking. We are finding that many are built upon faulty assumptions about or violated-principles of systems theory. So we are not just working through these instruments more slowly because most of us have done less of that…we are also challenging the typical forms and processes as we work to reach a plan that is consistent with Systems Thinking.

This has prompted quite a bit of reflection on the Board. Traditional management instruments like strategic plans tend to be based upon “Management By Objectives” (MBO); the concept–now meme–of driving toward numerical and date-stamped achievement targets. MBO was introduced by Peter Drucker in his 1954 book, “The Practice of Management.” MBO focuses first on the “what” (with metrics) and then moves to “how” and doesn’t even always reach the “why.” This carves the opposite path to Simon Sinek’s Golden Circle, which starts with “why” and works through “how” to “what.” This aspect alone makes MBO the reverse of a systems approach. (In all fairness, Drucker did say you must think of the system while doing MBO…a piece of advice that is almost universally ignored. And it is ignored because MBO naturally leads to fragmentation of systems into silos, another opposite of the system perspective.)

There’s yet more problems with using the traditional “goal-metrics” approach as a foundation. Of MBO, Deming said,

“If you have a stable system, then there is no use to specify a goal. You will get whatever the system will deliver… If you have not a stable system, then again there is no point in setting a goal. There is no way to know what the system will produce.”  (“Out of the Crisis”)

A recent and excellent blog post from Kelly Allen put it this way:

“The setting of objectives does not assess capability. If the capability does not match the need, take actions to increase the capability.” (http://bit.ly/HAQ4q3)

Increasing organizational capability automatically improves performance. Demanding improved performance (the MBO approach) cannot guarantee either improved performance or increased capability. In fact, the very act of demanding improvement often makes performance worse…for instance, by moving people from intrinsic to extrinsic motivation. Fortune Magazine backs this up, summarized by Ed Powers as

“70% of CEO’s who fail do so because of lack of execution and not strategy” (http://bit.ly/ZM2iVn).

The list of the main human motivators, identified by Daniel Pink as “Autonomy, Mastery, Purpose” (in his book “Drive”), also support the case against MBO. “Old-style strategy” often culminates in a set of specific but ineffective demands upon performance improvements. The LSS is not going down that path.

So, we on the LSS Board have focused our strategic planning effort on assessing and improving LSS capabilities as a system at achieving the values our community (Fellows, Patrons, practitioners, other LSS stakeholders) substantially agree upon per the many interviews we’ve conducted. Adding new or strengthening existing capabilities will bridge the gap between our combined vision of where our values lead (again, based upon interviews with LSS stakeholders), and our ability to get there.

One example of a strengthened LSS capability already in works is the new “Reactor Conference” format,  rolling out for the first time this September in our Denver conference. It is a far more capable approach than the traditional conferencing format we used in our predecessor organization, the LSSC.

The “Reactor Conference” format is just one manifestation of a new “catalyst” approach we have developed (with much consultation of Fellows and others) to bring together systems stakeholders to solve systems problems and raise the systems sea level. We are also evaluating other ways of  delivering this approach besides conferencing. The result will be a better environment for building long-term ties between all kinds of stakeholders for many reasons, including business, improving theory, and collaboration. 

Other LSS capabilities we are currently or will soon be improving include

• tying systems work more strongly to both reality (including complexity, unpredictability and economics) and solid science
• improving systems work “at scale” (e.g., Enterprise-level)
• helping the majority of people who are not systems professionals become more aware of the way systems work and make better systems decisions (politically and otherwise)
• increasing the value provided to everyone who participates in the LSS in any way

These capabilities are already in the draft plan. So are other, longer-term capabilities. We also want to keep hearing your ideas about needed capabilities. Those that tie into our shared values and priorities will likely go into future versions of the plan.

Besides the learning curve and system analyses mentioned above, activities like interviews with many Fellows and other LSS stakeholders have taken considerable time. The good news is that we are progressing well and are nearly ready to release “strategic plan rev 1.” I’ll be a little wiser than before and not claim a specific release date for now. We’ll let the work finish playing out to give the most benefit to the community of the LSS. But it will be “very soon.”

And it will evolve quickly based on your feedback. We want and need to hear your thinking. Being systems-based, this plan will be more useful and effective than an MBO-based set of goals and target metrics. It will focus us on the continuing activity of improving the LSS to help our systems work be as effective as possible…both for the sake of our own professional growth, and for the benefit of the world.

We believe you will find the result useful and worth the wait. The new ideas and thoughts from working on it have been fascinating and full of potential.   

Jim Sutton

When are iterations useful? I find this an intriguing question.

“If you are not discovering new things, you aren’t pushing it”

Being in product development means you are in the risk taking business. As Donald Reinertsen puts it, we make money by doing new things.

Doing new things means taking risk. Removing all uncertainty also means removing all value adding

This makes a case for fast learning and iterations is the predominant tool. So during rapid discovery, iterations makes sense.

But how many development projects are really about establishing new business using new technology?

Not too many. A more common scenario would be to grow/sustain existing business using technology created by your team, which should be known -occasionally stumbling into code created by other teams aka new technology.

Are iterations value adding value here, or, is it a poor excuse for accepting bad quality (in both input and output)?

What’s first time pass?

First time pass means what we strive to get to a point where we can deliver a working result in one pass, without quality defects. This implies:

• When work arrives, it’s prepared so that that we can deliver it in one try. We do not accept unprepared work to enter our pipeline.
• We have the skills available to deliver the work
• We have working tools to do our job

“First time pass” rewires the brain

The best effects I’ve got was to use first time pass as a coaching tool. Two complete different sets of answers emerge if I ask the question “what should be improved” vs. “what would need to be in place to get first time pass?” It’s like answering “what would be better in your garden” vs. “how about moving to a completely different neighborhood”. It also focuses the improvements on real work, not just improvement in general.

I recommend you to try it.

Mattias Skarin, Crisp

Kanban/Agile Coach @ AgileSparks

Disclaimer – I’m not a CMMI expert. Far from it. My experience with CMMI sums up to working with a few organizations that already have a CMMI certificate and are looking at Lean/Agile as a way to improve, some organizations who improved their performance using Lean/Agile and are also looking at a CMMI certification of their maturity, and a reasonable amount of reading and following people like Hillel Glazer, Richard Hensley, David Anderson who have more experience in the matter. Call me a Kanban Practitioner reaching out…

In several recent engagements with enterprise-level organizations the topic of CMMI has come up. It typically comes up as an early question that goes something like “But what will our CMMI Appraiser think about this?” this being – The emphasis on learning through working software, actual feedback, adjusting plans, rather than comprehensive phase gates and specification documents. When I describe the fact that the process itself will shift some of the people having post-traumatic stress from preparing to their CMMI audits really lose it… From a naïve perspective this should come as a surprise. After all, CMMI talks about Continuous Improvement as the ideal maturity level (Maturity Level 5). Doesn’t that mean you will actually have to change your process as part of that improvement? Isn’t it clear that improvement means improving the system of work and if your maturity model says you are documenting the way you work, then it means changing that documentation?

I think the conflict arises from the fact that on one end many CMMI Appraisers come from an experience of waterfall/phase-gate environments and their approach to CMMI calcified around comprehensive planning, documentation and handoffs as a way to show maturity. On the other end many agilists carry the revolutionary flag waving Manifestos and lack of any planning/documentation using reasons/excuses such as empiric processes, emergence, uncertainty. The poor practitioners in the field think they have to choose a side. And this obviously creates fear of exploring the “other side”. Which is a shame. Yes CMMI seems to be quite complex. Yes there is a definite overhead. But it does seem like it brings some formality and discipline that many organizations can benefit from to take their maturity to new levels. Yes lean/agile preaches different trade-offs trying to reduce your batch sizes and emphasizes moving ahead with imperfect information and exploring the requirements uncertainty as well as execution uncertainty. Yes you will have to revise your processes. Yes you might have to revise your processes quite frequently. But for most product development/IT shops today it is becoming more and more a necessity not a choice. Therefore I believe we should try to work together.

There’s been an ongoing thread of activity on the subject of bridging the perceived gap between CMMI and Lean/Agile. See some materials for further reading down below. I’m seeing more and more openness for going agile in a CMMI environment. On the other hand CMMI is still perceived as very heavy and formal and a certification-oriented method rather than a potential maturity improvement approach by organizations not forced into it by their clients/ecosystem. Are we throwing the baby out with the bath water? Isn’t there something useful about CMMI that these Product Development companies are missing because they are afraid of the overhead? Is the CMMI vision/intent of being an approach for guiding process improvement underserved by its current perception as a certification scheme for project companies based on evidence of comprehensively documented and audited work processes? I think this might be the case.

One of the steps I took to bridge the perceived gap was to try mapping Kanban – my favorite method of guiding your lean/agile journey – into the CMMI model. The Kanban Method as described by David Anderson includes 6 key practices:

1. Visualize
2. Limit WIP
3. Manage Flow
4. Make Process Policies Explicit
5. Implement Feedback Loops
6. Improve Collaboratively, Evolve Experimentally (using models/scientific method)

I recently looked at a few diagrams outlining the CMMI model (actually starting with a keynote David gave at Agile Israel back in 2010 – see Video and PDF). Take for example this one:

(By Sally Godfrey (What is CMMI ?) [Public domain], via Wikimedia Commons

I started to think that there might be an interesting mapping between the core Kanban practices and the CMMI Maturity levels. This ties into discussions about the order of the practices back in the 2012 Kanban Leadership Retreat in Austria.

(Picture of reordered practices courtesy Hakan Forss from his great blog about the subject)

A twit of my early thoughts/sketches seems to have resonated with quite a few folks in our community. There were some questions as well as reinforcements to the thinking.

I took in some of the comments/suggestions and my current suggestion looks like this:

Basically, I see the Kanban Practices as helping you take the CMMI maturity steps. In addition you follow the Kanban foundational principles of “Starting with what you do now” and “Agreeing to pursue incremental, evolutionary change” as another way to look at this maturity journey. You also need to “Encourage acts of leadership at all levels” these acts of leadership being setting the direction towards higher maturity and leading there by example, expecting it from your teams and people, including it in your day to day management routine. Note that while this diagram calls for an order between the Kanban practices (similar to the one Hakan documents above), you can of course start doing a practice in lower levels of maturity, but it would typically mean you are doing some optimization before achieving qualitative management or fully defining your process. I think that is fine. Do what works. My fellow sparkies (AgileSparks Coaches) are wondering whether the majority of organizations will proceed linearly or will need a more complex mapping similar to the “Kanban Depth Kivieats”. This is certainly a big question. Trying to map several of the organizations I’m familiar with shows promising results (most of them at Level3 btw – which shouldn’t be a big surprise…) but the jury is still out. I’m really hoping a simple linear mapping can provide guidance for many situations as I think while not as comprehensive it is more directional which is a benefit. A related point is that of course these maturity levels don’t indicate the agility level of your processes and interactions (e.g. high-trust culture). The maturity level SHOULD indicate the pace at which you are improving your agility/leanness. Low maturity will indicate there is a good chance your capabilities are standing still or even deteriorating. High maturity SHOULD indicate focus and improvement (If not, then we are measuring inputs/outputs and not outcomes, which will be a shame).

How will you use this? As both Hillel Glazer and Richard Hensley (respected thought leaders and practitioners in both the Lean Systems and CMMI space) recommend – After you use Kanban to make a maturity improvement step, you can then use CMMI to appraise/certify your current level. Then take another maturity step, and re-appraise or certify. As David Anderson comments in his Agile Israel 2010 keynote mentioned above there are some process areas in CMMI that Kanban doesn’t explicitly guide you towards so you might need to go an extra mile to actually match a certain maturity level you are seeking. But Kanban done right with leadership and discipline will certainly take you a long way quite quickly.

The mapping can be only a starting point though. I see a deeper opportunity here. As I mentioned above, Product Development companies refrain from taking on CMMI if they don’t really have to (and most of them don’t). But what if there was a light-weight CMMI-inspired model that provides some extra guidance beyond the Kanban Depth model, something that organizations will be able to grasp without requiring expert help, that they will feel brings them real value (not just a stamp of approval), can help them in the pursuit of incremental evolutionary change towards higher maturity, can make acts of leadership more concrete for the leaders? I think some of the more serious product development companies would love to embrace such an approach. Now that might be an interesting mashup/love story that can help us in this quest for improving the world of work through its systems…

Yuval Yeret
AgileSparks

Further reading:

Shortcut to CMMI – Lean First, by Hillel Glazer – www.agileCMMI.com/index.php/2012/03/short-cut-to-CMMI-lean-first

CMMI or Agile? Why not embrace both – by Hillel Glazer, Jeff Dalton, David J Anderson, Mike Konrad, Sandy Shrum – http://www.sei.cmu.edu/reports/08tn003.pdf

Viewing a Lean System through a CMMI lense – Richard Hensley at Lean Systems and Software Conference 2010 – http://www.leanssc.org/videos/lssc11/Hensley/Hensley.html

Agile CMMI: Why Isn’t This Conversation Dead Yet? (Cutter Journal issue available for purchase) http://www.cutter.com/itjournal/fulltext/2012/11/index.html

Liz Keogh

Independent consultant, Lean / Agile coach and trainer

When I was first taught about value streams, they looked a lot like this:

The idea is that you look at the different activities through which the work flows, and the gaps between them, then narrow the gaps, because waiting around for things to happen is wasteful.

We’re used to thinking of software in terms of phases. We talk about analysis, design, implementation, testing and production. If we’re feeling more Agile and our teams are more collaborative, we might talk about work that’s ready, in progress, and done.

As companies get larger, the value streams tend to get more complicated, but we still talk about our software in terms of those original phases. Those are the ones we see every day on our Scrum or Kanban boards. We don’t always notice the things that happen outside the team… and it’s often there that the magic happens.

In software development, work is more like product development – designing a new car – than like a production line where we churn the same thing out over and over again. The length between phases often changes. Our biggest constraints are often not the length of time it takes to process “work”, but the length of time it takes to get feedback and learn from that feedback. Our Kanban boards signal the impediment of flow of work, but that also means an impediment to feedback; this is why it works. Reducing the length of the value stream gives us feedback on the whole of our product.

Outside of the development team, the gaps between phases can be quite small. Other ways to shrink the stream might involve eliminating phases entirely, or minimising the work that needs to be done, rather than worrying about the gaps between them. One of the tricks I’ve learnt with value streams is to stop asking what happens to work, and to start asking who it happens with. Who wants this in the first place? Who’s providing the budget or deciding that this is high priority? Who will give you feedback? Whose feedback might end up being “no”?

So the development team get their requirements. Who do they get them from? Is it the users? An analyst? Are they able to just go off, get the requirements and work, or is there some kind of scope control, and who applies that? Ah, there’s a funding body! And a feasibility study group… and another funding body for the feasibility study. The things we discover!

Going out from the team the other way, we start finding what happens before code will be used. Who wants to test this before it goes to real users? Who needs to certify the app before it hits the store? Who is actually going to do the release, and what do they need? Who needs to tell the users so they actually start using the code?

At this point all kinds of gatekeeping stakeholders can also appear; people who will not let the code be used, or who won’t give their support, unless their needs are met. The support team need monitoring and logging to be in place. The architecture team may have performance requirements or maintainability and changeability requirements. Security, legal and audit groups pick the release apart. Sometimes it’s as simple as just telling the marketing department, but even that can be forgotten in the relief that comes with actually being finished (except you’re not).

As we start tracking down the individual groups, we can start seeing that the value stream for much of our software is in fact a value watershed, complete with tributaries, dams, a vast delta to get bogged down in, and even the occasional oxbow lake, cut off and isolated as soon as the river floods.

Now we can start looking at how long it takes to get the information and feedback we need from the different groups. In some cases, we may discover that nobody has ever engaged the group at all. Our non-functional requirements were little more than a note saying, “Remember performance!”, and our security requirements derived from some years-old story that’s still retold around the water cooler in hushed voices. Yet there’s still someone out there who knows the real story, or has the real figures. The best development teams, to them, are the ones that help them sleep soundly at night.

For over a decade now, we’ve known that getting testers involved early on, before the code is written, can help to improve the quality of the code as well as discovering some of those annoying scenarios that we wouldn’t otherwise consider. Acceptance Test-Driven Development (ATDD) and Behaviour-Driven Development (BDD) were both conceived along these lines. But what’s to stop us from getting any stakeholder involved? Why shouldn’t we talk to every gatekeeping stakeholder and turn that person or group into an educator instead?

If we were to do that for every stakeholder, it would result in even more analysis. We’d be moving the effort from one side of the stream to the other, rather than reducing the length of the stream. We know that doing a vast amount of analysis up-front doesn’t always help.

So how do we shrink the value stream from here?

In many cases, the stakeholder requirements are already so well known that we don’t need to talk to them. We use Active Directory for logging in. We know to avoid SQL injection attacks. Our performance requirements are minimal; we’re pretty sure our code will meet them. In these cases, letting stakeholders test afterwards – often in parallel – is the best thing to do. In others, providing proof may be enough – through performance metrics, or code complexity metrics, or continuous review, for instance. It might lengthen the development phase, but it’s usually worth it for the faster feedback and the elimination of later testing phases.

This is often referred to, vaguely, as “baking quality in”, though when I talk to development teams they often have little idea what “quality” means, or how to measure it, or who cares. Mapping the value stream with people can change that.

We’ll also be engaging new stakeholders, or meeting new requirements for existing stakeholders. A question I like to ask is, “What’s different about this project? What will it let the company do that they’ve never done before?” This is Cynefin’s complex domain; a place where outcomes emerge, rather than being predicted, and in which feedback is absolutely crucial.

By engaging these stakeholders earlier, getting their feedback on prototypes and in showcases, we can often eliminate a large bulk of the testing that needs to happen afterwards. Their testing phases merge with that of the development team. Since this is the space in which most discoveries will be made, it’s also a great place to work out if projects should go ahead at all (beware of any consultants or coaches who “guarantee success” with their approach!) and to deliberately pivot, Lean Start-Up style, if the original assumptions around feasibility or usefulness turn out to be wrong.

Now that we know where feedback is needed most, we can use our value stream the traditional way. We can look for gaps in the stream where we’re waiting for people, and see if we can free them up to respond more quickly. We can look for anything which creates large batches, and see if we can get agreement to make those batches smaller by reducing transaction cost (incremental funding can be a big win).

Another question I often ask my clients is, “Where does your influence end?” This helps us see where quick wins can be made, and where we may need to start pushing for change outside that sphere. For those of us who aren’t always engaged at the C*O level, that awareness can help to focus conversations… and can start to give us a value stream for change programs themselves.
Development teams who consider the people in their value stream usually invite the right people to showcases. They have a better awareness of scope, and risk, and tend to do the newer, riskier pieces of work first. Their story cards tend not to start with “As a user…”, but instead, “As Mark from the Security Audit team…” And they speak not just the language of the department who asked for the application, but the language of the whole business, carrying that language into their code too.

One of our tenets in Lean is, “Respect for People”. I’m increasingly coming to believe that this isn’t as much a pillar of Lean as one of its most fundamental tests. If we do it right, people are respected – not because we force ourselves to behave a certain way, but because a good system leads us, inevitably, to take their needs and frustrations into account.

Our value stream is made of people. Let’s find out who.

Liz Keogh

Liz is an experienced Lean and Agile consultant and well-known international speaker. Coming from a strong technical background, her work covers a wide variety of topics, from software development and architecture to psychology and complexity thinking. She is best known for her involvement in the BDD community, and was awarded the Gordon Pask award in 2010 for deepening existing ideas in the space and “coming up with some pretty crazy ones of her own”.

Israel Gat

Fellow and Director, Cutter Agile Product & Project Management Practice

The grand successes of Facebook and Instagram demonstrated the new economics of the web. The money these days is in breakout hits powered by network effects. Such breakouts are primarily enabled by thoughtfully exposing API’s. Hence, we are witnessing a dramatic increase in the number of web API’s that get publicly exposed (as distinct from internal API’s). We have, by now, reached the level of 8,000 such API’s. Extrapolating the pattern indicated in Figure 1, we could easily expect some 20,000 exposed API’s at one point in time or another during 2013. For most practical purposes, a “web beyond the browser” is getting formed in front of our eyes.

Figure 1: The accelerating pace of exposed API’s
(Source: ProgrammableWeb)

This new “web beyond the browser” has profound implications not “only” on the way we do software, but on the way value is generated and delivered. Essentially, the nature of assets changes in a profound manner. Your company’s assets might be physical, but they have corresponding information representations in your company’s pipes and vaults that are potentially valuable to a broad spectrum of applications. For example, various users are already spawning off bazaars on top of the Instagram photo sharing service (click here and here for recent articles on the subject). Imagine the limitless possibilities that could open if/when an advertising API is exposed by Instagram.. Needless to say, other kinds of API’s that might potentially be exposed by Instagram could be most intriguing…

From a software process perspective, the effects of the “web beyond the browser” manifest themselves in quite a few ways. Here are six of the more noteworthy ones:

1. The changing nature of the business you are in: More often than not, value for the end user is not generated by your own programming team, but through an eco system of developers that build their apps on top of your company’s exposed API’s. Schlumberger’s Ocean app store – screen scraped as Figure 2 below – is a good example. Schlumberger, who actually defines itself as an “oilfield service provider,” is (de facto) in the business of software these days. Similar metamorphoses are taking place all over.

   
   Figure 2: Schlumberger’s Ocean App Store

2. Business design: The way an API is exposed determines the nature of the business the company is pursuing. Figure 3 illustrates about twenty kinds of business designs that are driven through the different ways in which an API is exposed. Hence, exposing an API becomes as important a decision as any traditional business design decision such as how a company discovers and develops its customers, differentiates its services or goes to market.

   
   Figure 3: API -> Business Design
   (Sources: Source: John Musser, HoJin Ha and Jim Plamondon)

3. The systemic uncertainty of value generation: Traditionally, a product team developed a whole application as the primary vehicle to generate (and thence recapture) value. Nowadays, value is more and more generated through applications that other folks, possibly in a developer community, develop on top of the API’s the company’s product team implemented (and exposed). Quite often, such apps create value in novel ways that had not been foreseen nor foretold at the time the API was exposed.
4. Your customers are your developers: Developers might or might not pay you directly (see Figure 3 above), but for most intents and purposes the folks who develop the applications on top of your API’s are the primary target clientele the product team needs to cater to. The success, or failure, of your exposed API’s is only as good as the quality of the applications produced and delivered on top of them.
5. Open Source style of governance: You can incentivize the developer community to code to your API’s in various ways, but you can’t manage them in a traditional fashion. As a matter of fact, an Open Source style of governance is usually the most effective way to manage an expanded software process that incorporates the developer community as a pivotal organizational construct.
6. The changing role and skills of the product manager/owner: Historically, decisions about API’s and their design were largely the realm of architects and programmers. In view of the business design implications, these decisions are now becoming more and more the domain of product managers/owners. To succeed in defining both the API and the corresponding business model, the product manager/owner needs to excel in architecture, business design and developer relations.

Examining these six changes, it becomes obvious that the connection between the macro – the market – and the micro – the process a firm uses to shape the market – is much tighter nowadays than it used to be. In this new reality, a metamorphosis of the software process is taking place: customers become developers; self-organizing teams becomes developer communities; and, the product manager/owner’s job becomes the definition and monetization of API’s.

In the aggregate, the six changes listed above force companies to shift their focus to full life cycle optimization. Such optimization can’t be attained without major expansion in the scope within which Agile/Lean/Kanban/devops techniques will be applied. My hunch is that we will soon witness the application of such techniques to new and exciting areas. I will elaborate in a follow-on blog post on the areas/industries I expect to be most promising for so doing.

We live in interesting times….

Jim and Tonianne’s writing has been based in large part on Jim’s groundbreaking application of the Lean-Kanban technique – invented decades ago in Japan to increase factory flow – to improving knowledge work and people’s everyday lives. As original kanban released the hidden potential in factory production, Personal Kanban is releasing great potential in individuals and families.

We are privileged to have Jim and Tonianne in the Lean Systems community. They make us the richer for their great insights, and by both being wonderful people.

All four keynote speakers at this conference are LSS Fellows and exemplify the breadth and depth of the Fellowship, and the potential for bringing together great minds to help improve the world by improving its systems.

As with all the other recognised events, Agile Australia is aligned with the Society’s Credo, we support it as a great opportunity for learning and interaction within the community, and we highly recommend attending.

•  Re:think Kanban, 14-15 June, Antwerp, Belgium

This is another event which is aligned with the Society’s Credo, which we support as a great opportunity for learning and interaction within the community, and which we highly recommend attending.

I’ve recently finished reading Johan Lehrer’s The Decisive Moment: How the Brain Makes Up Its Mind. I have found myself increasingly fascinated with aspects of neuroscience, in this case related to how we might make better decisions about the way we work. Lehrer describes of the way our dopamine neurons learn patterns and get more excited by surprising events than predictable ones, and how the training of these neurons by experts helps them to spot the unexpected and leads to instinctive decisions. This helps explain ideas such as Information Theory that I learned from LSS Fellow Don Reinertsen, and Pattern Entrainment that I learned from LSS Fellow Dave Snowden.

This all leads to the conclusion of the book, where Lehrer suggests two reasons why the aviation industry’s safety record dramatically improved from the early 1990s. Given the often-poor reputation and success record of the software and product development industry, it seems we can learn from these two reasons. As an aside, it is exactly this sort of cross-fertilisation and learning between disciplines and industries that is why I continue to be involved in the Lean Systems Society. I hope that as a community we can continue to share experiences and ideas for the common purpose of improving the world by improving its systems.

Simulation

The use of flight simulators became a viable and common practice shortly before pilot error rates declined. Simulators provided a “safe to fail” environment in which pilots could practice decision-making, and thus train their dopamine neurons better. Mistakes in the simulator by pilots are actually seen to be positive because of the learning that results during subsequent debriefing. As a result, in real emergency situations pilots are able to rely more heavily on making instinctive decisions based on practical experience, rather than having to recall the theory of what they had learned in a classroom.

This would suggest that a similar use of simulations for software and product development initiatives would provide equivalent benefits, enabling leaders and managers to make better decisions based on practical experience.  I know that people like Troy Magennis and Larry Macherrone are already working in that direction, and products such as FLOWer are already starting to appear. I believe this area is ripe for research and development and may provide us with substantial steps forward.

Crew Resource Management

Crew Resource Management (CRM) was also introduced from the early 1980s after it was realised that many pilot-error incidents were a result of pilot being in sole command of the aircraft, rather than working with the rest of the crew as a team. Instead of the pilot’s viewpoint being the only one, diverse viewpoints are encouraged and shared. As Lehrer says “the best decisions emerge when a multiplicity of viewpoints are brought to bear on a situation”. CRM is more than just another name for collaboration though, but can be described as a “management system which makes optimum use of all available resources – equipment, procedures and people – to promote safety and enhance the efficiency of flight operations”. (http://www.crewresourcemanagement.net/)

While CRM may not sound like anything new to Lean and Agile teams used to being cross-functional and self-organising, I wonder what there is still to learn from the way the approach is taught and used within the aviation, medical and other industries that have adopted it.

Karl Scotland

Rally Software

• Lean Kanban Nordics, 12-13 March, Stockholm 
• London Lean Kanban Day, 16 March, London

These are events which are aligned with the Society’s Credo, which we support as great opportunities for learning and interaction within the community and which we highly recommend attending.