The 16 Rules of DMAIC

07/24/2022:

This multi-part article is the second in a series of five serialized parts that explores why all businesses, all

organizations, and all enterprises should consider daily standups as an integral part of their overall

project and operational communication planning.

Despite the adoption of the Agile framework globally, having a daily standup seems to have been thrown

to the side as a waste of everyone’s time. This article asserts the contrary, that maintaining a disciplined

daily standup regimen is absolutely necessary from a communication and conflict resolution perspective.

It explores eleven common reasons why projects - and by extension, daily operations - fail, and how daily

stand-ups are a necessary first step to achieving overall outcome success.

Go to Previous Part 1

Eleven Good Reasons for Daily Standups - Part 2

The Agile Framework

As outlined in the official history of the Agile Manifesto (agilemanifesto.org_1):

“On February 11-13, 2001, at The Lodge at Snowbird ski resort in the Wasatch mountains of Utah,

seventeen people met to talk, ski, relax, and try to find common ground-and of course, to eat. What

emerged was the Agile ‘Software Development’ Manifesto. Representatives from Extreme

Programming, SCRUM, DSDM, Adaptive Software Development, Crystal, Feature-Driven

Development, Pragmatic Programming, and others sympathetic to the need for an alternative to

documentation driven, heavyweight software development processes convene.”

In the two decades since the publication of the Agile Manifesto (agilemanifesto.org_2, 2001), the Agile

framework has been applied to all sorts of business processes, technical and non-technical, project efforts,

and ongoing operations. The backbone of that process is the daily “scrum”.

When it comes right down to it, the Agile framework is all about efficient and effective communication,

followed up by efficient and effective implementation, which often requires additional efficient and effective

communication, throughout. It is a modified example of the Plan-Do-Check-Act (PDCA) cycle.

I am a big fan of daily standup team meetings. Therefore, it should not be surprising that I am a big fan of

Agile. As far back as the early 2000s when I was first exposed to a book written by one of the original

manifesto signatories, Kent Beck. Beck’s book, “Xtreme Programming” (1999), the whole idea of creating a

“new discipline of development” (Beck, p. 5) organized and clarified many of the issues I had noticed as a

database developer, business analyst, and project manager.

Since that time, Agile has attained the status as the next new bright, shiny object in the never-ending

pantheon of IT and Quality Management delights. It follows previous bright shiny objects of TQM, ISO 9000

and 9001, Six Sigma, CMM, CMMI, etc. The Agile framework has been applied to all sorts of business

processes, technical and non-technical, project efforts, and ongoing operations.

Yet -- after over two decades -- there is still no empirical evidence available that objectively demonstrates

that Agile -- or SAFe, its enterprise, steroid equivalent -- is more efficient or effective than any other

framework being used today. Despite reported DevOps successes like the influential book, “Accelerate”

(Forsgren, Humble, & Kim, 2018) there is no confirmed data to justify a conclusion that Agile or SAFe can

increase productivity when applied to non-DevOps procedures, by itself.

For the purposes of this article, I will refrain as much as possible from referring specifically to Agile

terminology: e.g., “scrum”. “Daily standup” should be taken as its equivalent for Agile purists.

Communication is all about context. Technical terms are useful when talking to other knowledgeable

professionals in a specific field. When used in the context of a mixed audience -- technical professionals

and those who are not -- it is just an ego-driven way of excluding some from participation.

As reported in a November 2021 article entitled, “The Standish Group Reports 83.9% of IT Projects Fail --

How to Save Yours” (Opendoor Technology), only 16.2% of IT projects were reported as having been

completed on time and on budget. 52.7% of the reported projects were “challenged”, i.e., projects declared

to have been completed and approved, but whose outcomes were either late, over budget, and had fewer

features and functions than originally specified. The remaining report projects (31.1%), were considered to

be complete failures, projects either abandoned altogether or canceled.

Without splitting hairs to what extent, a “challenged” project might be declared a “success” to save one’s

professional career or to justify continued budget funding, let us minimally agree that project continuity and

success -- and by extension operational continuity and success -- still has a long way to go.

The opendoor.com article cites ten factors contributing to projects failing to achieve complete success: 1).

Incomplete Requirements, 2). Lack of user involvement, 3). Lack of resources, 4). Unrealistic expectations,

5). Lack of executive support, 6). Changing Requirements and Specifications, 7). Lack of planning, 8).

Didn’t need it any longer, 9). Lack of IT management, and 10).Technical illiteracy. I would add an eleventh

contributing factor: failure to keep pace with the increasing velocity of change.

Contrary to what many marketing professionals and business management consultants strongly imply, you

cannot just go out and buy a miracle. Having the right sort of fairy dust in hand, you cannot just sprinkle it

about and make all of your project and operational problems disappear.

My own professional experience -- and the anecdotal evidence collected in informal chats with other

process professionals -- leads me to believe that most frameworks -- including Agile -- are quickly adopted

in various hybrid proofs of concept efforts, and just as quickly abandoned or left to die at the side of the road

when stove pipe short-cuts are more convenient.

The opendoor.com article does not mention poor communication or a lack of accurate and timely

information as a contributing factor, neither is internal and external conflict resolution.

Not surprisingly, that seems more than a little odd to me.

(Continue to Part 3)

Reference

agilemanifesto.org_1. (2001, Feb). History: The Agile Manifesto. Retrieved from agilemanifesto.org:

http://agilemanifesto.org/history.html

agilemanifesto.org_2. (2001, Feb). Manifesto for Agile Software Development. Retrieved from

agilemanifesto.org: https://agilemanifesto.org/

Axelrod, A. (2008). Bradley: A Biography. Hounmills, Basingstroke, Hampshire UK: Palgrave MacMillan.

Beck, K. (1999). Extreme Programming Explained: Embrace Change. Reading, MA: Addison Wesley

Longman, Inc.

Burton, J. W. (1969). Conflict & Communication: The Use of Controlled Communication in International

Relations. New York: The Free Press.

Clark, T. R. (2022, Feb 21). Agile Doesn’t Work Without Psychological Safety. Retrieved from Harvard

Business Review: https://hbr.org/2022/02/agile-doesnt-work-without-psychological-safety?ab=hero-subleft-1

Fischer, R., & Ury, W. (1991). Getting to Yes: Negotiating Agreement Without Giving In; Second Edition.

New York, NY: Penguin.

Forsgren, N., Humble, J., & Kim, G. (2018). Accelerate: The Science of Lean Software and DevOps:

Building and Scaling High Performing Technology Organizations. Portland, OR: IT Revolution.

Hansson, H. (2020, FEB 14). Purpose of Meetings. Retrieved from dockethq.com:

https://www.dockethq.com/resources/purpose-of-meetings/

Kaplan, F. (2016). Dark Territory: The Secret History of Cyber War. New York, NY: Simon & Schuster.

Masli, A., Richardson, V. J., Weidenmier Watson, M., & Zmud, R. W. (September 2016). Senior Executives’

It Management Responsibilities: Serious It-Related Deficiencies and CEO/CFO Turnover. MIS Quarterly ,

September 2016, Vol. 40, No. 3, 687-708.

MCL & Associates. (2022, 03 17). PEOPLE: What the heck do we do with them? Retrieved from MCL &

Associates, Inc., Small Business Transition Blog: https://www.mcl-associates.com/People-

what_the_heck_do_we_do_with_them.html

Opendoor Technology. (2021, Nov 25). The Standish Group Reports 83.9% of IT Projects Fail - How to

Save Yours. Retrieved from opendoorep.com: https://www.opendoorerp.com/the-standish-group-report-83-

9-of-it-projects-partially-or-completely-fail/

Porter, J., & Baker, E. L. (2006). Meetings, Meetings, and More Meetings. Journal of Public Health

Management and Practice (Vol. 12, No. 1 (January-February), 103 - 106.

Powell, C. L. (2003, Oct 28). Why Leadership Matters in the Department of State. Retrieved from

GovLeaders.org: https://govleaders.org/powell-speech.htm

RingCentral, Inc. (2022, MAR 27). Meet with a Purpose: 5 Types of Meetings. Retrieved from

ringcentral.com: https://www.ringcentral.com/guide-to-better-meetings/types-of-meetings

Second Rise LLC. (2022, MAR 27). https://www.lucidmeetings.com/meeting-types. Retrieved from

lucidmeetings.com: https://www.lucidmeetings.com/meeting-types