Posts Tagged ‘lean’

Lean Camp New England: Boston, May 13

Tuesday, April 24th, 2012

OK, OK, so it’s Mothers’ Day in the US… but we all miss out on family matters all the time for things far less awesome than this.

Lean Camp New England is a one day open space event led by Jim Benson, author of Personal Kanban. It is an opportunity to share and learn about Lean and Kanban in software development, IT operations and services, and other knowledge work fields.

Lean Camp New England is an all day event at the World Trade Center Boston, on May 13th (Sunday).
Registration is open now at a cost of $300 – catering is included.
Register at http://lssc12.leanssc.org/.

Boston is the center of gravity for lean thinking in the US. However, much of that thinking has been in fields outside of IT and Software and Systems Engineering/Development.

If you live in New England, or people you know live in New England, and are interested in getting up-to-speed among the leading thinkers and practitioners in Lean in IT and Software and Systems Engineering/Development, I highly encourage you and them to register for Lean Camp New England.

This is a rare opportunity to enjoy a regional 1-day open space / unconference in conjunction with a large international conference, Lean Software & Systems 2012 – as a result a significant number of international experts will be present and participating.

Where else can you get direct coaching from the experts for only $300?

Like a Broken Record: Assume an Engineering Mindset

Sunday, March 7th, 2010
Engineering Mindset

I keep answering the same question over and over again.  On one hand, it’s good that interest in CMMI (and Agile) is growing.  On the other, I’d really like the development world to be able to move onto more interesting challenges.  I know it’s foolish to believe that answering a question on my blog will stop the questions from coming in, but at least once it’s answered, I’ll just point people here instead of repeating myself in emails and phone calls.

Whether the desire is to implement CMMI in an agile environment or a traditional environment, the key to making CMMI “work”, and by “work” I don’t mean “get you a rating”, or as people incorrectly call it, “get you CMMI certified”.  By making CMMI “work” I mean, incorporating CMMI into your organization in such a way that the resulting processes:

  • Add value to your organization and to your customers,
  • Are things people want to do,
  • Foster continuous communication and improvement,
  • Measure what matters, and still
  • Result in a desired rating (as a by-product, not the goal).

Here it is.  The “key” to making CMMI work is what I call, an “Engineering Mindset”.   Engineers realize that when they fail to be honest, precise, and thorough, things fail to work and many times this failure means someone is either disappointed, or worse, hurt or killed.  To avoid the undesirable outcomes, engineers have a sense of integrity. Not in the moral or religious sense, but in the sense that things are whole and complete.  An Engineering Mindset includes seeing things as problems or opportunities and their corresponding solutions or exploits.  So an Engineering Mindset has two elements: Integrity and Solutions.

For using CMMI, these two elements align nicely with what I’ve been saying for years.  These elements are not magic or glamorous, but people find them to be challenging, nonetheless:

  1. Be clear and honest with CMMI and how it works and what it really is and isn’t.  If you’re following in the path of Agile, you MUST also be honest with the Agile Manifesto. The “things on the right” *do* have value, and their value must be justified.  If you’re not all that concerned about “agile”, you MUST be concerned about value.  And for that you must get a grip on your work flow and be committed to knowing the value stream of your work flow and be committed to continuously and aggressively pursuing the elimination of non-value-added activities.  This often takes shape in investment in activities and a culture that appreciates and recognizes awareness, tools (methods, technology, assets, systems, etc.), LEARNING, pluralism, empowerment, and excellence.
  2. Recognize that CMMI PA practices are not processes but that each practice avoids some pitfall. Identify how your organization avoids that pitfall and you will have accomplished the intent of the practice. If how you avoid it is weak or absent, then it’s something you should build into your work.

Please pay attention to this next point: In my work, the organizations that embraced key point #1 had no trouble with key point #2, and, in many cases, required very little new or different to take them to any maturity level they wanted.

When we work with clients, we spend most of our effort to help them internalize #1 (if they need it).  When they’re able to do #1, they generally “get” #2 on their own AND they figure out where the value lies in the practices in CMMI they’re not already doing AND they figure out where and how to incorporate those practices into their own.

If your organization can’t figure out the value to your organization in CMMI practices, you’re not allowing yourselves to be creative enough and you’re not thinking like engineers.  An engineering mindset must exist first.  When it doesn’t, it’s a long and challenging road ahead.  Choose wisely.