Contents
A Philosophy for All Work
Taken together, some concepts I have been reiterating throughout this site lead to what may be a surprising conclusion. Here’s a quick review:
- Projects involving unknowns do not fit waterfall.
- Capacity planning prevents overwork and burnout, benefiting workers and the company.
- Sprint planning provides high short-term predictability.
- Kanban improves the throughput and quality of almost any kind of repeatable work
- Self-organizing teams outperform traditionally led teams.
- Agility fits the psychology of (any) humans working in small groups better than other work management models.
Now review this definition from the Project Management Body of Knowledge (PMBOK): “A project is a temporary endeavor undertaken to create a unique product, service, or result.” A project also has a definite start and end, the PMBOK says, though the output is usually long-lived.[4]
Expand your thinking across your company, government agency, nonprofit organization…whatever your “enterprise” is. How many groups in that enterprise spend part of their time doing projects defined that way? Ignore the nature of their work. Include temporary efforts like specific improvements within your continuous improvement strategy. Now how many groups?
The answer is, “Almost all of them.” Finance professionals perform monthly and quarterly closings, each a “unique… result.” Human resources departments don’t think of themselves as doing projects, but each hiring, termination, performance appraisal season, and investigation of misconduct fits the PMBOK definition. Every continuous improvement effort is a project: quality circles in Manufacturing do nothing but projects! Any large document such as a report is a project, as is changing the physical layout of an industrial plant.
In most of these groups, people must cooperate to some degree to create the output, and there are at least “known unknowns.” I’ve observed or read studies about enough top leadership teams to state firmly that every one of them would get the same benefits of team charters and/or Scrum as any software team. Janitorial services, security guards, Customer Support and most others that do not do projectized work can benefit from Kanban.
The most obvious benefit to the enterprise is elimination of Scrum Pox. When top executives and all stakeholders are agile, interface conflicts go away. In fact, the Agile Liaison role goes away, too. Instead the Customers and Team Guides in each organization would merely work together to coordinate dependent requirements.
After direct comparison of agile manufacturing (AM) and Agile software development, a journal article concluded, “the current agile software development models could be extended towards higher organizational levels and even to enterprise-wide value chains following the AM principles. This leads to holistic total-company systems thinking where agile capabilities provide sustainable competitive advantages building in part both on the software product development functions as well as on the related manufacturing operations of the (new product development) company.”[5]
This part of the site puts Full Scale agile™ (FuSca™) into the context of enterprise-wide change that will not only bring greater internal and external happiness within the company by eliminating Scrum Pox, but most likely greater financial success as well. It shows how changes not typically addressed in Agile transformations can extend the philosophy side-to-side, and more critically, top-to-bottom throughout an enterprise. There are no step sets because I am not an expert in implementing these ideas. Those experts are already in your Finance, HR, Legal, Manufacturing, and Procurement departments, if they are willing to learn. I urge you to take whatever action you can, given your place in the company, to evangelize these changes and help to implement them.
Resistance is Natural
I don’t know why ineffective management practices persist from generation to generation. One study I read suggests the primary reason is that leaders tend to fall back on what their bosses did—even if they disagree with the technique.[6] Presumably this is because they feel overwhelmed with daily challenges. Seeking and trying alternatives takes time. As a result, they seek piecemeal fixes rather than accepting that the entire structure is antiquated and unsound. It doesn’t help that much of the advice on the Web and in management books makes little reference to scientific data on business operations. Most teambuilding companies are so out-of-touch with psychological reality, their claims border on fraud.
For example, consider personality tests. The most popular in the working world ignore advances in personality research over recent decades. More to the point, studies show personality has far more to do with the way people do a particular behavior, not which behavior they choose in a given situation (see “The Personality Scam”). Environment and situation are the key drivers of behavior, the former in this case meaning corporate culture. A study considering why project teams tend to use the same organizational structures, despite significant differences between their projects, concludes, “Three major themes started to emerge… ‘top-down prescription,’ ‘imitation,’ and ‘common background of managers.’”[i] Yet many executives and those who mislead them for money continue to focus on personality tests instead of changing the environment.
All humans make decisions for seemingly logical reasons that psychologists consider literally irrational. To cite just one example from a list of 19 I carry around to jobs, we humans have a tendency to only adjust so far from a previous estimate, even if the circumstances that led to that estimate have changed significantly.[8] In earlier sections of the site, I’ve mentioned the proven tendency to underestimate, and you can throw in our foibles around, among other filters:
- Procrastination even when logic supports immediate action.
- The assumption what we’ve personally experienced reflects the larger pattern.
- The tendency to focus on what is important to us regardless of that factor’s level of objective importance.
- Our preference for information that supports our existing opinions (“confirmation bias”).
Top executives, like everyone else, can’t be experts in everything. They have to rely on internal advisors, but outdated advice is another issue. I’ll use HR as just one example. I have been arguing for many of the concepts on the next page (“Structuring for Agile”) since the early days of my work with self-directed teams in the 1990s. All have strong scientific backing. Speaking as a former member of the Society for Human Resource Management (SHRM), I know there are strategic thinkers in that field pushing similar changes, and HR people are as smart and dedicated as those anywhere in any company. Yet for more than 20 years, I have run into more resistance than assistance from HR.
Those HR reps may be blameless. Most of the Web postings on Agile from the HR perspective only date to 2015. The first time I saw Agile addressed in relation to HR in a presentation, at either SHRM or Agile gatherings, was not until 2017. The speaker, HR consultant Fabiola Lyholzer, confirmed something I had long sensed: Finance and Legal departments shackle HR policies. Because of this, her slides said, “HR instruments are driven to handle poor performance and mediocrity… (and) must make up for weak managers and uninspiring leaders, costing companies billions.” Therefore, she said, “HR practices work the way they were intended,” but the needs they were intended to address are not the strategic needs HR should be filling.
Add in that executives are likely getting bonuses based on unchanging financial targets within the only budgeting system they have witnessed their entire careers, driven by Finance professionals trained and mentored to run things that one way. As you will read under “Annual Budget Games,” that is not the only or the best way, yet it remains the predominant system.
The logical conclusion is, you will need to be understanding and patient. The persuasion effort will take considerable time.
↑ Agile Management | → Structuring for Agility
Full references are in the Agility Bibliography.
[1]–[3] Removed.
[4] Project Management Body of Knowledge (Project Management Institute 2013).
[5] Kettune 2009.
[6] Zhang, Higgins & Chen 2011.
[7] Removed.
[8] Gino & Pisano 2008.
Note: Footnote [i] either was mistakenly omitted at the time its quotation was added or later deleted by accident. I regret the error.