Lean Software and Systems Competencies

Alan Shalloway, CEO, Net Objectives, Lean Competencies Chair, Lean SSC.

Note: The Lean SSC wants to acknowledge that the concepts presented on this page originate with Net Objectives

How the Lean SSC Competencies Are Laid Out

Software development is a complex endeavor. While people may have roles, they are highly interactive. We have found it best to present competencies in the context of the value stream in which appear. A simple value stream is shown in Figure 1:

Value Stream

Figure 1: A simple value stream.

In this diagram we see ideas originating from customers, being discussed, selected and prioritized by business stakeholders into a collection of products and product enhancements. In an IT organization these products / enhancements is the software that supports the services the business needs/provides.
Competencies lie in four main areas:

  • Business
  • Team Agility
  • Technical Agility
  • Management

Business – responsible for value:

  • Prioritization
  • Business iterations
  • Release planning

Team – responsible for delivering software

  • Incremental
  • Creative problem solving
  • Quality
  • Sustainability

Management – responsible for flow:

  • Value stream visualization
  • Cycle time
  • Impediment impact
  • Workflow as process
The software industry is at a cross-roads. There are several agile camps. Dividing lines exist in both their focus and belief systems. These different areas include:

  • Where do you focus your efforts?
  • Is there such a thing as a value-stream?
  • Is software development such a complex process that no causality should be inferred by any actions
  • What is the role of management?
  • What is the purpose of certification?

While more organizations are adopting agile methods it seems many (most?) are having serious challenges in their adoption. We believe in a scientific approach. The lack of definition of Agile methods has hurt their adoption. Basic concepts that have been around for decades are unknown to most Agile teams. However, just providing lots of knowledge doesn’t necessarily improve anything.

Our approach to certification is based on the following steps:

  1. Identify the challenges if effective software development.
  2. Do root-cause analysis for these (Ask 5-whys?)
  3. Determine what skills are necessary to address these root-causes
  4. Determine how to teach these skills including how to affirm that the skills are being taught properly
  5. Determine how to affirm that the person learning them can demonstrate their knowledge

This last one is the certification process itself. This sequence of steps is to illustrate that one can’t meaningfully have any certification program unless one says what it means for someone to be certified. That is, how will they act differently? Certifying someone in having taken a course misses the point. Even if you could confirm that the students learned something, that may not have any true bearing on their future actions. For example, knowing the rules of baseball does not make you a better baseball player.

In other words, certification is a last step – not a first. Starting with a course on certification leaves me a little mystified, personally.

This wiki-page represents a start to determine our challenges, the root-cause of these challenges, and what skills are necessary to solve/avoid these challenges. The issue of how to teach or determine if someone has learned them and can demonstrate them will be addressed at a later time after we’ve laid this foundation.