Listen Now
Subscribe: Apple Podcast
Check out the podcast on Google Play Music

Software Process and Measurement Cast 490 features a return visit from Michael West.  Michael West is the author of Return On Process (ROP): Getting Real Performance Results from Process and Real Process Improvement Using the CMMI Michael and I talked process improvement and how process improvement translates to the bottom line.  Mr West originally appeared on the SPaMCAST 308 [https://bit.ly/2ITlKsf]

Michael’s bio:

Michael West is a life-long practitioner and student of process improvement. He is the co-founder of Natural Systems Process Improvement (Natural SPI), a consultancy specializing in designing, developing, and deploying process systems that enable measurable business performance improvement gains. Mr. West’s process insights and innovations have helped many organizations in various sectors of the economy achieve real process and performance improvement. His process consulting clients include ATK, Autodesk, AVL, BAE, BB&T, Crane Aerospace, DCS, Deloitte, Sandia National Labs, Reliability First, and the US Navy. Mr. West frequently presents and speaks at industry conferences, and is the author of Real Process Improvement Using the CMMI (CRC Press, 2004) and Return On Process (ROP): Getting Real Performance Results from Process Improvement (CRC Press, 2013).

Contact Michael at:

Web: http://www.naturalspi.com/

Email: michael@naturalspi.com

Twitter: @ItsTheProcess

Re-Read Saturday News

In week five of the re-read of L. David Marquet’s Turn the Ship Around! (https://amzn.to/2qujXmL) we tackle chapters five and six.  These two chapters, titled Call to Action and Whatever They Tell Me To Do! continue to tell the stories that form the basis for Marquet’s leadership model.

Current Installment:

Week 5: Call to Action and Whatever they tell me to do!https://bit.ly/2IXZugS


Previous Installments: (more…)

Advertisements

The goal of learning and leveraging lean principles in an organization is to improve value delivery. In order to get the biggest bang for the buck, practitioners need to take a systems approach to what they analyze and change. Lean, like agile, works best when we change the flow of work. This is one of the reasons value stream mapping is a powerful lean tool. Given the expansive – soup to nuts – perspective, lean practitioners use many techniques to stay focused. The 5 Ms from lean manufacturing is a focusing tool. The 5 Ms provides a framework to consider five of the controllable inputs into any process. While the 5 Ms are part of lean manufacturing, it takes very little imagination to use the 5 Ms as a focusing tool for any process flow. The 5 Ms are: (more…)

Quote from Mark Twain - too much whiskey is barely enough

Can you prove it?

Organizations and team embrace a framework or technique for a purpose. That purpose is generally to address a real or perceived problem.  When you get very specific, each change is done a different reason.  When teams or organizations are asked whether they attained their goals, solved the problems they intended or realized the promised benefits, very few have gathered more than a handful of success stories before losing focus and moving to the next big thing. Unless you can answer whether the framework or technique delivered tangible value,  leaders will be reluctant to spend money on changes.  Best practices are a point in case.  Best practices are, by definition, practices that some have found useful (or at least that someone has professed are useful).  Every process improvement and/or best practice adoption that is not legally mandated needs to follow the following high-level feedback loop.

  1. Decide why you are making the change and what the outcome of the change will be in tangible terms. Developing a solid reason for why you are making a change may sound like a trivial step, however, the rationale will often directly impact the passion for making the change. People pursue survival changes with a lot more vigor than incremental quality of life improvements.
  2. Develop a hypothesis of why the change you are making will satisfy the rationale for the change.  Changes that actually work rarely are the outcome of magical thinking or dumb luck. If there is no logical reason the change you are proposing will have an impact you are very likely wasting time and money.  Use the scientific method!
  3. Set SMART goals that will be used to track and evaluate the change.  As a reminder, SMART stands for specific, measurable, achievable, relevant, and time-bound.  The goals should cover the journey and outcome based on the hypothesis crafted in step 2.
  4. Benchmark the process you are changing.  Consider collecting data specific to the change and data to evaluate the impact on the overall system.
  5. Make the change.  You still have to make and support the change.  Your journey measures will be helpful to make sure that the change is being implemented well.
  6. Collect the data to show the impact (compared to the benchmark developed in step 4) for several cycles after the change has been implemented.
  7. Use the data you collect to tune the process. Pick a feedback loop and tune the process.  Rarely are major changes perfect right out of the box.  Using feedback to tune the process helps to ingrain the change and to make sure it is delivering value.
  8. Report your findings.  Share the impact with everyone involved.  Positive data will help to reinforce the change and will help sell the next round of changes.  In scenarios where the change doesn’t deliver value reporting reinforces the principle of transparency.  If a change doesn’t deliver, don’t double down on a failure; revert back and try something else.

People make changes to how they work on a daily basis.  Some changes are minor and, in some cases, are not worth developing a full-scale proof of impact. For example, deciding on whether to order grilled tofu or pizza for the team lunch doesn’t require a proof of impact.  Some large-scale changes like adopting Scrum, Kanban or DevOps require a great deal of time, focus, and money. It makes sense to be able to answer the question of whether you got what we thought you would get with something more substantive than a shrug.

Next an example

Listen Now
Subscribe on iTunes
Check out the podcast on Google Play Music

SPaMCAST 455 features our interview with Michael King.  We talked about Michael’s approach to Agile, process improvement and the CMMI at Halfaker and Associates.  Michael provides a glimpse into making a change in the real world.  Mr. King delivers more than just theory.  One word describes the interview – insightful.

Michael’s Bio:

Michael King serves as Chief Technology Officer at Halfaker and Associates (www.halfaker.com), leading customer solution architecture, internal IT operations, business process architecture, and quality management activities.  Michael has 14 years of systems engineering, project management, and process design experience within the Federal contracting industry.  He has previously served as Halfaker’s Chief Operating Officer.  Prior to Halfaker, Michael worked within Lockheed Martin’s Critical Infrastructure Protection group, providing system engineering support related to identity management, physical security, and cyber security.  Michael holds a Bachelors in Computer Engineering from the University of Virginia, a Masters in Information Systems and Technology from Johns Hopkins, and several professional certifications (PMP, PMI-ACP, SAFe SA).  Michael King writes about organization design, Agile, and process management at https://designinggreatorganizations.com.

Twitter: https://twitter.com/mikehking

LinkedIn: https://www.linkedin.com/in/mikehking/D

Re-Read Saturday News

This week Steven dives into Chapter 3 of Paul Gibbons’ book The Science of Successful Organizational Change.  This chapter has provided me several sleepless nights considering the difference between complicated and complex systems.  Understanding the difference is important making change happen, work, and stick!  Remember to use the link in the essay to buy a copy of the book to support the author, the podcast, and the blog!  

This week and previous installments: (more…)

Listen Now
Subscribe on iTunes
Check out the podcast on Google Play Music

The Software Process and Measurement Cast 434 features our essay on Change Implementations – To Big Bang or Not To Big Bang? The knee jerk reaction amongst transformation leaders is usually a loud NO! However, the answer is not nearly that cut and dry.  Big Bang approaches to change have a place in bag of tricks every transformation leader has at their fingertips.

The second column this week is from Steve Tendon. Steve Tendon brings another chapter in his Tame The Flow: Hyper-Productive Knowledge-Work Performance, The TameFlow Approach and Its Application to Scrum and Kanban, published by J Ross (buy a copy here) to the cast.  In this installment, we talk about Chapter 16, The (Super)-Human Side of Flow. In Chapter 16 Steve and Wolfram go into detail on in Kotter’s attributes of flow state.  A good discussion and a good read.

Our third column is from the Software Sensei, Kim Pries.  Kim discusses Fermi Problems. Fermi problems or questions are a tool to teach approximation and estimation.  These problems usually can be solved logically as a back-of-the-envelope calculation. The last time we talked about Fermi Problems was when we were re-reading How To Measure Anything (Hubbard).

Re-Read Saturday News

This week we tackle Chapter 7 of Carol Dweck’s Mindset: The New Psychology of Success (buy your copy and read along).  Chapter 7, titled “Parents, Teachers, Coaches: Where Do Mindsets Come From? explores the impact of some of the most intimate and earliest relationships on our mindsets. Understanding how parents, teachers, and coaches affect mindsets helps us learn to lead change.

We are quickly closing in on the end of our re-read of Mindset.  I anticipate two more weeks (Chapter 8 and a round up).  The next book in the series will be Holacracy (Buy a copy today). After my recent interview with Jeff Dalton on Software Process and Measurement Cast 433, I realized that I had only read extracts from Holacracy by Brian J. Robertson, therefore we will read (first time for me) the whole book together.

Every week we discuss a chapter then consider the implications of what we have “read” from the point of view of both someone pursuing an organizational transformation and using the material when coaching teams.   (more…)

A Thali is an incremental meal

Incrementalism–doing small changes in order to achieve a larger effect–comes in many styles and flavors.  The many variations of this approach have titles such experimentation, continuous process improvement, kaizen events, and plan-do-check-act cycles (PDCA).  To paraphrase 20th Century toothpaste commercials, 4 out of 5 process improvement professionals recommend incrementalism.  Agile and Lean are full of examples of branded incremental change models including the Toyota Production System, Scrum and Kanban (when applied to process improvement). We can see the impact of incrementalism on how these frameworks are constructed by observing the individual techniques such as sprints and time boxes, daily stand-ups both in scrum and XP, and retrospectives, to name a few.  Each technique reinforces taking small steps and seeking feedback for re-planning.  If you don’t want to consider frameworks or techniques remember that the agile mantra of inspect and adapt is a statement of incrementalism.   Incrementalism makes changes to how work is done by shifting the focus from the one big project or implementation to taking small steps, gathering feedback and then reacting. This approach to change is not new. Deming popularized the PDCA cycle early in the 20th Century.  Practitioners embrace incrementalism because making many small changes one after another provides feedback fast, which enhances organizational learning and mitigates many of the risks seen in Big Bang models. Four attributes support learning and risk reduction:

  1. Learning – PDCA type or inspect and adapt models all are built on the expectation that when a change is made, the impact will be reviewed and then the feedback will be used to improve how work is done.  Feedback is used as a learning device, where the faster feedback is generated the higher the possibility of learning.
  2. Risk mitigation – Steven Adams, agile consultant (SPaMCAST 412) stated, “Continuous process improvement is a less risky route.  But could be the slower.” Incremental changes typically will not imperil the organization in the way Big Bang or “bet the farm” type changes could.  For example which has more risk: a bank merger or adding hundreds of customers one at a time through a production interface? While this might not be a perfect analogy the larger change that gets feedback only when it’s completed will ALWAYS be riskier. Along with reducing the risk that size generates, smaller increments help ensure that that change programs don’t wander away from the vision that launched them.  Todd Field, senior project manager and Scrum master described it as, “I believe you need to have a Big Bang vision and an incremental improvements plan.“  Techniques like delivery cadence (e.g. Scrum’s sprint cycle) keep changes small and requiring product owner and stakeholder’s acceptance expose risks before they can become issues making incremental changes safer.
  3. Accumulation – Incremental changes building toward an overall goal are often compared to compound interest.  Small changes build on each other until the return is significantly higher than simply making each of the changes in isolation.  Dominique Bourget, the Process Philosopher described this concept as “It is like losing weight… you get more benefit by exercising one hour each day than to exercise 30 hours in a row on the last day of the month.”
  4. Adaptation to the pace of change in external environment – Software development environments are very dynamic.  New methods, techniques and tools are investigated, implemented and discarded as organizations try to get more done within corporate budgetary restraints. We all know the mantra faster, better, and cheaper.  Because of the rate of long term change in the development environment, change programs often lose focus or sponsorship.  Incremental changes are better at reacting to change and adjusting to the level of urgency within an organization.  Kristie Lawrence, IFPUG Past President, suggested that “continuous process improvement allows you to slowly and surely improve. The trick is to manage the scope of what is being improved – changing one thing changes the entire “system” and surface things that you never knew about.”  Implementing small changes provides a feedback loop to continually test the need for further changes.

Incremental changes provide organizations with a tool to minimize the risk of change.  Agile pundits, originally made the point in terms of software development.  The same ideas that make incremental change useful for software development are equally useful for improving the value of continuous improvement all across the business while reducing risk. As a result,  practitioners are predisposed to championing incremental change.

Vinigear Bottles

Not Sweet But Useful!

A big bang adoption of a process or system is an instant changeover, a “one-and-done” type of approach in which everyone associated with a new system or process switches over in mass at a specific point in time.  There are positives and negatives to big bang approaches.  We begin with the positives.

Patrick Holden, Project Portfolio Director – Software Development at SITA, struck a fairly common theme when asked about his preferences between the big bang and incremental approaches.  

While I favour incremental improvement, sometimes we really want to get on with the new, to change the mail system, phone, house, car or even your job you will need to prepare to different extents but you make the switch for one and all, it’s a Big Bang.  

The choice depends on divisibility, scope, and urgency.

The positives:

Big bangs fit some types of changes.  Not all changes are easily divisible into increments which lead to an all or nothing implementation. As I have noted before, most of the bank mergers I was involved in were big bangs.  On a specific day, all of the branches of one bank would close and overnight (more typically over a weekend) lots of people would change signs on buildings, customer files, and software systems. Perhaps it was a failure in imagination, but due to regulations and the need for notifications, it was easier for everyone to change at once.  Organizational transformations rarely have the same external drivers, regulations and notification rules; however, because of interactions between teams, it might be easier not to take an incremental approach.  Adoptions of large scale Agile methods and frameworks such as SAFe are often approached in a big bang manner. In SAFe many teams and practitioners are indoctrinated, trained and transformed together which by definition is a big bang approach to implementing scaled Agile.

Big bangs generate a too big to fail focus.  Large, expensive, and risky changes create their own atmosphere.  These types of implementations garner full management sponsorship and attention because they are too big to fail.  Christine Green, IFPUG Board Member, suggests, “it is harder to lose focus on big bang approaches when organizational leadership changes.” Big bangs can be used to address the risk of a loss of focus in some cases.  An example of an organization manufacturing a too big to fail scenario can be found in the often-told story of the early years of Fedex (Federal Express at the time).  It was said that the founder consciously borrowed money from smaller regional banks around Memphis so that he could use the impact of the risk of default to negotiate better service and rates.  Big bang changes are often too big to fail and therefore people ensure they don’t.

Management Expectations.   In many circumstances, management has little patience for the payback of continuous process improvement. As I was framing this theme, Christopher Hurney stated, “I’ve seen leadership expect Big Bang results in Agile adoptions, which is kind of ironic no? Considering that one of the precepts of Agility is an iterative approach. The expectation is often generated by a sense of urgency.  In this situation, a specific issue needs to be addressed and even though an incremental (or even iterative) approach would deliver bits and pieces sooner, the organization perceives value only when all of the benefits are delivered.  The Healthcare.gov marketplace was delivered as a big bang.

Even if the big bang approach to process improvement feels wrong, there are reasons for leveraging the approach. Chris Hurney stated that decision makers “tend to feel as though they’ve reached a point where a process has become unsustainable,” which makes the idea of implementing a change all at once worth the risk even though nearly everyone would prefer an incremental or continuous approach to change.

Previous Entries in the Big Bang, Incrementalism, or Somewhere In Between Theme

1. Big Bang, Incrementalism, or Somewhere In Between

Next:  Big Bang, The Cons!