CHAPTER 9

Fragile FRAMEWORK

Limitations of Emulating Scaling Frameworks

Monday, February 24, 2020

“Ahh, this fatigue, headache, and muscle pain. I cannot breathe well.”

Cindy looks completely worn-out walking at the hospital parking. She is under the weather with chemotherapy side effects. I have taken the day off.

I ask Dr. Anu about the possibility to suspend her chemotherapy.

“Normal cells become cancer cell when they continue to grow and divide out of control. It is this unchecked cell growth which keeps spreading when untreated. We need to expedite her chemotherapy before it is too late. We are ensuring that we track down the reasons of any more abnormal side effects.” Dr. Anu assures.

“We will need to keep her in the hospital for more tests.”

I try to wave our hands from outside the glass door. Cindy has a faint smile on her face and waves back.

I return home in the evening to Ami and Tina after a rather subdued day at the hospital. I finally get the chance to update the Kanban board.

Table 9.1 Kanban board

To-do	In progress	Done
•  Identify challenges in FA@ST •  Testing the hypothesis: Does scaling framework bring agility? •  The TIM WOODS analysis •  Explore a simplified alternative for backlog management	Doctor appointment	The latest Building Block: h) Shibumi sprint and seven Zen design principles

Figure 9.1 Text—Cindy and Neil

Early in the morning, I see a text message from Cindy, letting me know that she is feeling much better after yesterday’s scare. All her tests came back normal.

I come out of the shower and quickly make sandwiches while getting Ami and Tina ready for their schools.

Soon after, I hear a ding of missed call and find a voicemail from Seth.

“Hey Neil, Hana is insisting for compliance reviews and risk documentation, which could take about two to three weeks for us to start the project officially, and Tim has asked us to follow FA@ST processes for funding and business case approval processes. We cannot meet Daisy’s timelines with all of these.”

Did our agile framework make us fragile? I ponder.

I decide to get exception approval to exempt following FA@ST.

I start my day in the office late, at 11:05 a.m. with a list of tasks to action by the end of the day.

As I am walking toward the elevator, I see Paris in the large conference room with employees from store planning. With the subdued look and somber mood of the room, I instinctively realize they are being let go!

In the next room, the repetitious and mandatory three-hour monthly introductory training on the framework is in progress. I see closely that there are 12 folks, most peeping at their laptops or phones. I shake my head, realizing that they are still doing their day job during the trainings.

Too many projects and programs. We have more than needed people in certain roles like project managers, but we have asked them to shift overnight to agile ways of working. Some project managers are partially allocated 8.33 percent to a total of 12 projects. We have a mammoth 400 IT and digital projects in the company.

I always wonder how could a human being work precisely 8.33 percent of his time on a project? How could they turn off at a precise number, even when the work is not done? Are all projects equally important?

I can’t help but reminisce on recent conversations with Dr. Anu about the uncontrollable growth causing cancer. I start to think deeply about this, as I realize that there might be another type of uncontrollable processes, tools, and red tape at Walkers.

We have excessive forms, templates, policies, procedures, and too much documentation. And not mention, our many status reports, many siloed departments, too many consultants, excessive processes, practices, multiple types of meetings, systems, and tools—all leading to an ocean of Nonvalue Adding, that we are drowning in.

Is this not creating a kind of unchecked growth?

We have created the huge inventory of methodologies. In the next hour, Sid, Seth, and Saira join me in the WALL area.

“But … why is agile and lean managed by two different groups?” Sid raises a brow.

I openly admit that I am one of the parties in that entire saga, along with another person named Doug Dicky from Lean CoE.

I vent my frustrations for the next few minutes explaining constant bickering between me and Doug. I propose to come back to this problem in the next session, so we don’t derail the agenda.

Everyone nods in agreement. It is almost noon, and everyone looks to be hungry.

We make time for a lunch break at a nearby Indian restaurant to continue our conversation. We are at the Mirchi Chowk restaurant known to have the buffet style lunch. Our mouthwatering plates served with kebabs, chicken tikka masala, palak paneer, mushroom chana, aloo bhaaji, poppadoms with naan, and lassi arrive at our table.

The only sounds I hear for the next 10 minutes are the sounds of everyone enjoying their meals, crunch, guzzle, gobble, and gulp.

Sid breaks the ice and initiates the conversation on our framework.

Identify Challenges in FA@ST

“So, how do you guys feel about FA@ST? The Framework for Agile@Scale Techniques.”

Keisha is the first one to share her thoughts.

“I find this framework to be complex and rather prescriptive.” She looks at me and chooses her words carefully, noticing that I was a champion of FA@ST.

“Clearly the framework did create a fair amount of excitement initially but did not deliver the results, we anticipated. There are delays, problems, release-related disruptions, and stability issues in the software.” I add to encourage an unbiased conversation.

“But it was positioned to us as the best framework in the industry. Many certifications and trainings were organized locally in our branches, domestically and internationally.” Seth adds.

I nod in agreement “Yeah, I know. I still own the annual budget of almost $10 million for its adoption.”

“So, improving FA@ST is part of this budget, right?” Sid asks, taking a sip of his mango lassi with a smirk written all over his face.

“Who wants a dessert? Lunch is on Neil, our director!” He jokes as everyone laughs.

I bring them back to the topic “But on a serious note, our company is heavily invested in adopting the framework with almost 600 people getting trained in the last two years with at least 350 plus certified practitioners in the organization. Most of them have started adopting cursorily and some even left the organization, piggybacking on their new credentials.”

Tim and Hana need to hear it too. I quickly forward the invite to them, to join us before heading back to office.

“Don’t you think most people got trained and certified because they think it will get them a better job?” Keisha implies, reminding there were three resignations recently.

“Yeah, in the course of rising popularity of FA@ST, hundreds have got trained and/or certified in agile from ubiquitous providers. Most of the people have a shallow awareness centered on fancy buzzwords with limited understanding of intent and relevance of lean–agile values and principles. It’s a charade of transformation!” I admit with a sense of failure.

As we reach the office, I see both Tim and Hana, looking spellbound and staring at the WALL.

All are looking at me to kick off the meeting with two additional audiences.

“Our hypothesis is that our scaling framework slows us down due to more roles, processes, and formalities than needed, consequently leading to confusion, waste, and reduced innovation. It lowers customer centricity as we are always looking inwards and getting internally focused. The teams need to thoroughly unlearn their older concepts, roles, and then learn newer versions of a framework.” I make the opening remark.

Hana speaks up, surprisingly “We have tried somewhat to sloppily align our titles, funding, structure, and tools but there are too many changes, and change was all too fast due to FA@ST.”

“The roadmap to make transformation a true success for our customers, our talent, our vendor partners, and our shareholders was actually never there. We suffered a lot in GRC” Hana continues to complain.

“The framework was required by all the teams and it also created a lot of shortcuts and a whole lot of hidden factories of processes, where things were getting done for the sake of it without much value for the teams.” Tim acknowledges.

“…. And this doesn’t sufficiently encourage a philosophy of self-improvement. … This reminds me of our earlier efforts of ISO and CMMi, where the focus was primarily on getting certification and not always to maximize the value for customers.” Sid suggests.

Figure 9.2 Fragile framework

Testing the Hypothesis: Does Scaling Framework Bring Agility?

“Let us talk about how well framework supports agile manifesto.” Hana raises a good point.

We all unanimously decide to leverage the agile manifesto and lean thinking to demonstrate a hypothesis of how a scaling framework becomes heavy, prescriptive, ceremonial, and ultimately fragile.

Tim asks, “How many roles have we added?”

“I think seven or eight. But let me call Paris to confirm on this.” I insist.

“So actually, the empty and cursory aspects of the framework could make it highly counterproductive to genuine agility and business value.” Gus says.

“In hindsight, this provided a false sense of transformation. It is a masquerade, totally perfunctory. Instead of agility, the framework ended up obliterating whatever was agile earlier. It made us fragile.” I admit.

Figure 9.3 Manifesto view 1

Figure 9.4 Manifesto view 2

Table 9.2 Contradictory effects of scaling framework

Agile Manifesto value	The contradictory effects of the scaling framework
Working solutions over comprehensive documentation	•  The framework has multiple versions, whatever has been learned needs to be quickly unlearned, and there is a need to learn newer versions in a matter of a few months. A new version every year requires constant retraining and recertification of the people •  Frameworks get over engineered because they need to be commercially viable and sell faster. More documentations get created adding to an ocean of content
Customer collaboration over contract negotiation	•  The framework led to contractual obligations with three types of companies: framework consultants and coaches; training providers; recruitment agency for staffing new roles •  Created a whole new set of training providers, event organizers, and freelance consultants and coaches but reduced customer collaboration
Responding to change over following a plan	•  Many aspects of frameworks are “one size fits” all with little or no flexibility to adjust •  More money spent on consultants for creating additional models, presentations, and methods and ultimately leading to additional complexities
Individuals and interactions over processes and tools	•  A two-year plan was defined by our service provider to adopt the framework covered on practices and processes. The culture and mindset shift were not given enough attention •  The framework has added more processes and procedures that have recreated top-down bureaucracy and hierarchy in different names, shapes, and forms

Table 9.3 The TIM WOODS analysis of scaling framework

Transporting something farther than necessary: •  Reorganizing people in different levels: portfolio, program, and team	Inventory due to supply in excess of immediate and reasonable demand: •  Production of new training content •  Creates additional practices, roles, and hierarchy
Moving people more than required: •  Moving people for large planning gatherings and multiple ceremonies	Waiting for the completion of a step to start the next step: •  During the set up of new tools, teams, practices, and structures •  During the mobilization of new roles
Over processing to an extent that customer may not find valuable: •  Lots of theoretical concepts •  More buzzwords and jargons •  Expensive in terms of time spent	Over documentation with more than required content: •  Lengthy descriptive playbooks •  Large events creating additional documentation
Defects that require rework or redoing: •  Half-baked interpretations	Skills (and Intellect) due to underutilization of the talent of people: •  Effort for mastering the lingo •  Focuses on memory of models and not understanding of concepts

Table 9.4 The Writing on the WALL No. 11

11. Fragile scaling frameworks
What does it mean?	•  A formula centric, purist, and prescriptive execution of agile by blindly following a scaling framework and going by the book becomes counterproductive •  Cosmetic standardization and consistency efforts without rationale
What are its effects?	•  Diminishing return on investment in longer term •  More complexity in processes, procedures, and practices •  Less focus on the softer aspects of change in culture and mindset

Figure 9.5 WALL No. 11 and 12

We finally see that the framework gave us a highly complex tree structure for our backlog.

We see nine levels of backlog decomposition.

Table 9.5 The Writing on the WALL No. 12

12. Ineffective learning and development
What does it mean?	•  The training emphasizes theoretical and academic aspects which people fail to apply in their work •  The unintentional consequence of stressing the certification of frameworks leads to learning by rote
What are its effects?	•  Waste of time and effort of all •  Does not translate to the intended business results

Explore a Simplified Alternative for Backlog Management

“I believe our current backlog structures do not make us agile; on the contrary, we struggle to make it work and it is too much work to align creating overheads.” Keisha says decisively.

“I agree.” Seth nods forcefully and adds “Most teams were told to follow and tried to stick to this half-heartedly and incompletely.”

“It needs to be kept simple to manage for agile teams. In most scenarios, it’s a four-level backlog construct, where Objectives, key Results, Epic, and Story are sufficient. The tasks need to be used if the team wants to add more details.” Sid adds.

ORES: Objectives, key Results, Epic and Story.

“Just like ores are natural rocks containing valuable minerals, this construct of ORES encapsulates valuable requirements. We need to remove the layers of backlog, to reduce the overhead and complexity. The ORES helps to keep it simple, easy to remember, and intuitive.

Does it make sense?” He looks at all of us.

Most of us are still thinking this through and I insist that we align on the specifics of its implementation.

Figure 9.6 BB i

OKR—Finalize epics or OKRs (Objective and Key Results) based on relevance to customer experience and financial performance:

Commonly observed numbers in the ORES construct: For each Objective, there are 3 to 5 key results to measure and 1 to 3 underlying Epics to implement; for each Epic, there could be 10 to 30 stories, and if needed, 3 to 10 tasks for each story which could be created at individual levels.

Do not estimate every minor effort—anything which is 30 minutes could be task, but don’t create more than three to four tasks in a day; otherwise, it could be overkill and lead to overheads.

Keisha has another tricky question: “How do we know which objective is more important than others and which epic has a higher priority?”

I suggest we use a simple matrix I had learned during six sigma training.

A customizable matrix based on quality function deployment technique of neutral rating and establishing a score-based correlation of objectives with epics.

Example:

Table 9.6 Epic to objectives correlation

No.	Objectives	Weightage	Epic 1	Epic 2	Epic 3
1	Objective 1	6	3	9	3
2	Objective 2	3	6	9	3
3	Objective 3	9	9	9	6
4	Total score		117 (3 × 6 + 6 × 3 + 9 × 9)	162 (9 × 6 + 9 × 3 + 9 × 9)	81 (3 × 6 + 3 × 3 + 6 × 9)

“Epic” needs to have a correlation or enabling effect to an “Objective.”

In the example:

Key subject matter experts join the C-suite leadership to conduct a team-based voting to decide weightage of the Objective and correlations. Democracy wins, and not the one who is the highest paid individual.

After a quick coffee break as I walk back to the room, I see Paris entering with her laptop. She projects her laptop screen on the large screen.

“I am pleasantly surprised by how quickly our projector got connected this time,” Paris smiles.

“We can clearly see that there are more roles than we thought. There is a total of 10 roles as per HR records are directly attributed to this framework for our managers and team leads, and some did exist earlier.” I say it loud for all to hear clearly.

Wow that’s exactly what I was thinking about.

We see six levels of hierarchy.

Tring tring. We hear the classic telephone ringtone. Tim walks out for a few minutes to take a call. I use the chance to sensitize everyone on ground reality.

“Last year, Tim had used his closeness to Richie and pushed HR to ensure each program and project manager has a dotted line reporting to PMO. A common KPI was now added by HR in their performance evaluation ‘Adherence to company’s project management processes defined by PMO’.”

Each of the agile teams is considered a project team as well. Each member of agile team is mapped to a project in the official HR roster. And each project is expected to also follow the PMO processes, many of them overengineered by Tim and his team of PMs. Folks spend 20 to 30 percent of their time for this kind of stupid process adherence work. There is this constant friction between the PMO, agile teams, and the projects.

“The projects which are agile are funded based on what they deliver, while projects are funded for their entire schedule irrespective of its timeline. If you have a project, you need to have it on the PMO sheet; otherwise, it will not be funded. The PMO has already alienated and disengaged most of the project managers and scrum masters, playing with almost interchangeable rules to satisfy the PMO needs.” Seth is distraught.

We have bias and inequalities in our funding model. This conversation is another cue for us that we need to resolve funding complications with PMO.

Figure 9.7 WALL No. 13

Table 9.7 The Writing on the WALL No. 13

13. Redundant roles and inflexible HR policies
What does it mean?	•  The numerous departments, manifold team structures, geographies, methodologies, and frameworks have created an inventory of roles, titles, and designations which create confusing identities and redundancies in roles and responsibilities •  Certain roles by design are about (micro) managing people and lead to unhealthy dynamic when people have more specialized knowledge, skills, and competencies than their managers
What are its effects?	•  Hidden factory of overheads, complexities, and overlaps •  Lack of accountability and ownership (when everyone is responsible then no one really is!)

Table 9.8 Kanban board

To-do	In progress	Done
		•  Contradictory effects of the scaling frameworks to enterprise agility •  Complex frameworks translate to diminishing return on investments in medium to longer term
		The latest Writings on the WALL: 11. Fragile scaling frameworks 12. Ineffective learning and development 13. Redundant roles and inflexible HR policies	The latest Building Block: i) ORES (Objective, Results, Epics, Stories)