Perfect Tulips

Not everything is as perfect as tulips in the spring!

Process improvement is a critical 21st-century survival skill all organizations need to embrace.  In the late 20th-century process improvement was a code word for cost-cutting and outsourcing, in 2020 it is about reinvention and changing capabilities so that organizations and teams can seek a new short-term equilibrium. Change is initiated by defining scope and making decisions about what will be within the focus of a process improvement initiative, but that just gets the ball rolling.  The next step requires diagnosing a set of problems. IDEAL combines both identifying and qualifying opportunities. At the risk of messing with the acronym, I’m going to approach components separately beginning with identification.  (more…)

Two Pollo Tacos

The Ideal Tacos

The world’s economy is suffering a tremendous shock. Every other email that pops into my email box screams crisis. Businesses are experiencing a crisis of cost containment driven by falling revenues coupled with a looming debt crisis. Gallup Research is sponsoring a webinar on May 7th to talk about the problems being caused by rising health care costs. The bottom line, every budget manager is going to be pushed very hard to manage their budget closely, spend as judiciously as possible, and deliver the most value possible. The noise level about cost issues in the computing media, suggests a strong need for integrating lean concepts into agile approaches. Many organizations falsely believe that they are less sensitive to cost considerations. The IDEAL model provides a useful framework for finding ways to generate more value and to prove it.  A quick definition of IDEAL: (more…)

You Are Here?

Assessments in agile come under a wide variety of names: appraisals, health checks, audit or even assessments. These terms are commonly conflated.  Assessments are a tool to prove a point. There are many approaches to assessing agile in a team or organization ranging from self-assessment questionnaires to formal observer-led appraisals. What gets assessed and the approach an organization chooses depends on the point of the assessment. All assessments create a baseline, a line in the sand from which to measure change.  At the same time, an assessment is a benchmark. Benchmarks are a comparison against a standard (real or implied). For example, an organization could use the principles in the Agile Manifesto or the framework in the Scrum guide as a standard to compare their behavior against to generate a benchmark. Put very succinctly, baseline defines where an organization (or team) is at a point in time, while a benchmark is a comparison to a standard. Assessments of any type, whether to generate a baseline, a benchmark or both, require time and effort which might be better spent creating a product, unless there is a good reason to do an assessment. There are three macro reasons why an organization might assess the agile journey that can generate value: (more…)

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

https://oembed.libsyn.com/embed?item_id=6969007

SPaMCAST 509 will feature our essay discussing if you can demonstrate incomplete work.  My knee-jerk reaction is no…or maybe heck no, but knee-jerk reactions are not always right.

Blog entries in the what happens to incomplete work theme:

Frequently Asked Questions: The Sprint Is Over, What Do I Do With Incomplete Stories? https://bit.ly/2P9mm09

Frequently Asked Questions: Can I Demo Work That Isn’t Donehttps://bit.ly/2wfJzXv

Frequently Asked Questions: Can I Resize A Story If It Is Harder Than We Thought?https://bit.ly/2MvkB0a

Frequently Asked Questions: When Can I Demo Work That Isn’t Done https://bit.ly/2PCs0Zz  

We will also hear from Gene Hughson (Form Follows Function). Gene talks Architects!  Gene and I discussed his essay, So what exactly does an Architect do? Contact Gene on LinkedIn – https://www.linkedin.com/in/genehughson/

Bringing the cast home this week is Jon M. Quigley.  Jon brings his marvelous Alpha and Omega of Product Development to the cast this week in order to discuss the root cause analysis. Process improvement is most effective when we diagnose the real problem rather than just a symptom.

Re-Read Saturday News

In week 5 of re-read of The Checklist Manifesto by Atul Gawande (use the link and buy a copy so you can read along) we tackle Chapter 4, The Idea. In Chapter 4 Gawande shows how checklists can help push decision-making outward, which empowers teams and makes them more responsive.

Current Installment:

Week 5 – The Ideahttps://bit.ly/2PCs0Zz (more…)

Exit Sign

Get Team Problems Out

Not every team issue can be solved with a standard pallet of techniques. However, nearly every consultant (internal or external) will have set of tools that they have ready just in case. The following is a set of techniques packaged as a model, or the very least in order of precedence. The techniques referenced in this article are often used as a group and are only deployed as a correctively after diagnosing the problem (root cause analysis). (more…)

No Mowing Sign

The Environment is Complex

Having been involved in the world of buying, building, maintaining, and testing software for many years, one of the longest running conversations between everyone involved with delivering value is the impact of complexity on cost, effort, quality and even on the ultimate solution to business problems.  The concept of complexity and the impact of complexity is unfortunately – complex.   The importance of developing an understanding of complexity is complicated by a lack of a crisp definition and a confusion of the topic with the concept of complicated.  The difference between complicated and complex is not a mere nuance; the distinction will affect the options we perceive are available to solve any specific problem.

(more…)

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…)

3-29 2013 poop

Why do death march (gruelingly overworked and therefore high risk) projects still occur? While poor processes, poor estimation and out of control changes are all still factors, I am seeing more that reflect poor choices based on business pressure.  How often have you heard someone say that the end justifies the means?  It is easier to say yes to everything and avoid hard discussions about trade-off and just admonish the troops to work harder and smarter.

In Agile, we would expect backlogs and release plans to help enforce those sorts of discussions. Unless, of course, you stop doing them.  I recently talked to a group that had identified the need to do a better job of breaking accepted backlog items down into tasks during sprint planning (identified during a retrospective), only to fall prey to an admonition to spend less time planning and more time “working” leading to rework and disappointing sprint results.

As you discover messes, whether in the code you are working on or in the processes you are using to guide your work, you are obligated to clean up after yourself.  If you don’t, sooner or later no one will want to play in your park  . . . and  probably neither will you.

Sherbrooke Dam Wild Water

A few drips of water are fairly non-threatening. Rarely can a drip or two wash people or cars away or change the flow of a river. Constricting the flow of water harnesses a great deal of potential energy that when released can be used to generate power if it is run through a turbine or if released randomly the impact might be difficult to control.

Develop a backlog of potential changes and keep the list prioritized so that the effort you have to affect change can be channeled for greatest value. A backlog of process improvements is very much like the dam that collects the drips of water until it can drive the turbine of change. Like the dam if it is always collecting and never being relieved it burst and change will happen in a much less controlled manner.

Chicago Metal Bean Reflection

A few months ago I arrived at a conference in Chicago a few hours early and spent the afternoon wandering around the downtown area.  I love Chicago!  There are always new things to see and do.  Regardless of my mission, I always try to make time to see the Cloud Gate (the metal bean); rain or shine, hot or cold).  Why?  Cloud Gate reminds me that regardless of how I try to see things from different angles there are always different ways to see and experience the world around me.

Seth Godin, the marketing guru, counsels us to have a bias toward action; to  have the guts deliver our products, ideas and processes to market. The advice is sound because without delivering there is no possibility of feedback. Incorporating techniques such as diverse, cross functional teams, short development cycles, incremental deliveries and constant feedback loops into how you deliver process improvements will let you deliver and then gather feedback. In other words use techniques from agile and lean development to change how you improve your processes.

Deliver and then stand under your own Cloud Gate and watch, listen and gather feedback from all of the possible perspectives then deliver again.