Theory X and Theory Y - Gregory McDonald

Traffic Lights vs. Roundabouts - Agile - Bjarte Bogsnes

• To get good performance in traffic -- safe and good flow of work
• Traffic Lights: Those managing are those programming the lights. Based on some historical data, and some forecasts. Not entirely fresh information. No authority to act on information (traffic lights). Much easier. Rules based system. 
• Roundabouts: Alternative. Drivers are in control. Based on fresh, here and now information. Proven that roundabouts is more efficient - because access to fresh information. Difficult to drive in because it requires more competence. Value sets required to manoeuvre in roundabouts. We are much more dependent on the value system of other drivers. We have to interact with people in a very different way. It is a self-regulating management model. 

Third Wave of Agile

Hierarchical organizations are where everyone has their face towards the CEO and their ass towards their customers - Jack Welch

Organizations are hierarchical, but customers are not !!

Budgeting and Agile - (Courtesy Stephen Denning - Forbes)

• Traditional Budget cripples innovation, is cumbersome, time consuming,  wasteful, and riddled with gaming the system. Encourages unnecessary spending, hides accountability, is demoralizing, inefficient, ineffective and fundamentally at odds with the dynamics of business agility.
• In theory Budget (traditional) is a brilliant idea. Helps top management keep track of their strategies, plans, programs. It enables action, measures performance, etc.
• In practice, 
• Budget counts outputs whereas Agile management counts customer outcomes.
•  Process for arriving at budget is heavy, and takes a long time. 
• Creates a sense of entitlement -- regards the level of inputs from last year's budget as entitlement for the coming year.
• It encourages / tries to minimize commitment in terms of output -- level of outputs from previous year is often presented as a ceiling for the coming year. 
• Encourages the ethic of "spend it or lose it". Doubtful whether all the expenditures towards the end of the fiscal year are really high priority.
• Budget process itself is costly -- many disputes as to how to reconcile conflicting claims on budget.
• Budget is often treated as a combined TARGET, FORECAST, COMMITMENT and RESOURCE ALLOCATION process. It ends up performing none of those functions very well.
• Budget numbers is therefore a sub optimal compromise and therefore a poor basis for performance evaluation.
• Budget interlocks with other aspects of internal bureaucracy, therefore adjusting budget is not easy. To fix budget, you need to fix the other issues (organizational structure, cost accounting, HR system,  Executive compensation and share buyback, Disconnect with strategy -- all explained below). 

• Ability of top management to monitor minute details of spending / budgeting leads to such diktats as "Freeze all travel expenses", which deprives a genuine and important organizational plan. 
• Traditional budgeting is therefore predicated on mistrust (Can't trust an exec for travel expense, but is willing to give responsibility to manage a million dollar investment).
• Budget has a long horizon of 12 months.  But by 4th Qtr, the budget horizon reduces to couple of months. It allows only for minor ad hoc adjustments, as the attention shifts to preparing and agreeing for the next year budget.
• The appearance of control that budget offers to senior management is often an illusion of control not real control.

What does Fixing the Budget Involve?

=====================

There are a whole lot of issues to be addressed to fix the Budget issue:

• Organizational structure: budget reflects, reinforces and aggravates the siloed organizational structure, which gets into the way of delivering value to customers. Siloed teams hand off work to another silo, thereby reducing the pace of delivery.
•  Budget as an internal mindset -- budget reflects an internal mindset as opposed to customer-oriented mindset. "Hierarchy is

Flow efficiency

Why focus on features isn't advisable?

Source: Allen Holub

Thinking in terms of features is a disaster. The main problem is that there is no direct connection between the feature and the user's actual work. Features describe your work, not your customer's. 

Many orgs chase one worthless feature after another, never delivering anything of value, and then go belly up. Even the MMF is a flawed notion. You need to release long before an MMF could be implemented to get necessary feedback.

Instead of features, implementing user stories does focus on the user's work, making it possible to do that work in a system that is far from feature complete. That provides real value, and it is often a salable product. Even if you can't sell it, you can get immediate feedback. 

IEEE Systems Engineering Body of Knowledge (SEBOK)

https://sebokwiki.org/wiki/Main_Page

Ringelmann effect and Social Loafing

Ringelmann Effect: As team size increases beyond certain point, individual productivity is seen to diminish. This leads to loss of motivation, and coordination problems.

Social Loafing: The reduction of individual effort exerted when people work in groups compared to when they work alone is called Social Loafing.

Student Syndrome and Parkinson's Law - Procrastinate and Delay the task, Expand work

Culture, habit and Agile Transformation

• 40% of decisions people make everyday are not decisions, but habits. (Dr. Wendy Woods).
• Key to changing habits is not willpower, rather it is changing environment.
• Change requires organizational re-learning -- unlearning and learning everything new

Scrum retrospectives - focus on what?

Focus on improving desirable outcomes, not on playing by its rules. Don't focus on how you can improve the implementation of scrum, rather focus on the value delivery. 

Kubler-Ross Model adapted to Agile Transformation

Reference: Jonathan Smart on Medium.com

The Kubler-Ross Curve originated from psychiatrist Elisabeth Kubler-Ross’s work on grief, published in 1969. It has been found to be valid in the majority of situations relating to change and we have repeatedly observed this pattern to hold true via feedback from colleague surveys.

Project management vs Program management vs Portfolio management

Reference: PMBOK, pmstudycircle.com

Project: A project is a temporary endeavor undertaken to create a unique product, service or result. Projects cease once their objective is achieved.

Project management: Project management is the application of knowledge, skills, tools and techniques that helps projects achieve their objectives.

Program: A program is a group of related or similar projects managed in a coordinated way to get the benefits and control not available from managing them individually -- program has multiple projects that are similar, closely related.

Program Management: program management is the centralized, coordinated management of a program (inter-related, interdependent projects) to achieve its strategic objectives. Program management strives to:

1. Optimize resource utilization
2. Reduce friction or constraints between projects in program

Portfolio: is a group of related or non-related projects, programs. Portfolio may consist of multiple programs, or "multiple projects with no program at all".

Portfolio Management: is the centralized management of a portfolio to identify, prioritize, and authorize the projects or programs. (Based on organizational strategy, business objectives). Portfolio Management does not oversee any individual project or program.

Enterprise Business Agility - Brad Bennett (EPIC Agile)

Business Agility

Business Agility refers to the ability of businesses to rapidly respond and adapt to market changes (both internally and externally) -- respond flexibly and rapidly to changing customer demands, the ability to react to emerging competitors, shifts in market conditions, and rapid adaption to technology trends. All of this without compromising on quality, lead the change in a cost-effective way, and still be continuously holding competitive advantage (vis-a-vis its competitors).

This Enterprise Business Agility model (certified by ICAgile) comprises the following 7 pillars.  

Customer Centricity / customer seat at the table

a. Do you know who your customer is?

b. Are you engaging your customer (understand requirements and get their feedback early)?

c. Do you engage them regularly?

d. Do you change your roadmap based on the feedback of the customer?

Customer Seat at the Table is the same as Stephen Dennings' Customer Centricity - placing the customer at the center of solutioning.

Lean Portfolio Management

a. Do you have the ability to refresh the portfolio so all your best ideas are on the top?

b. And Bad ideas never get in?

Lean Portfolio Management is applying lean thinking to managing enterprise (agilityhealthradar.com), program and product portfolios to streamline high-value work. This ensures delivering most-high value work is delivered first, while limiting WIP, limiting interruptions, and aligning work to organization's intended outcomes and team capacity. 

Organizational Design and Structure

a. Do you have the ability to be able to redesign your organization based upon the missions and the high priority initiatives that happen?

Delivery Frameworks & Agile Mindset

a. Have you built multiple delivery frameworks (Scrum, Kanban, XP, etc.)?

b. Do you know what framework you are using?
c. How do you build an internal culture and a learning mindset within the organization?

Leadership and Culture

a. Have your leaders gone on the Agile journey?

b. Are they taking this on?

c. Are they embracing in?

Make it Stick (sustaining the change)

a. Do you have a Talent acquisition strategy in an Agile world?
b. Do you have the Capability growthmap for your employees?
c. PR & Comms around Agile happening (within and outside of the organization)?

Adaptive Technology

a. Do you have tech infrastructure in place to enable business agility?

Allen Holub on Twitter -- Selling Agile and Changing Mindsets

"Don't know if it's possible to "sell" agile. Politics should show us that people do not use rational thinking when it comes to ingrained beliefs, and anti-Agile literature and social media is rife with confirmation bias.

 It seems it's not facts or rational arguments that change minds or behavior. Has more to do with social interaction and status. Just look at politics.

Many intelligent and highly educated ppl are climate-change deniers. Facts do not change their opinions. Confirmation bias runs rampant. Same applies in the Agile realm, I think. E.g. If someone believes in cmd/control, you can't change that with facts.

There are very few approaches that work: If the new information comes from somebody you know and trust, you might pay attention. If the people around you believe something, you'll pay attention. If your status goes down if you don't do it, you'll pay attention.

In general, a rational argument will be of no use whatever. Even demonstrating that somebody's "wrong" (e.g. with a pilot project) will not change minds.

Ultimately, the only solutions that work are rooted in social interaction. We programmers tend to not believe that. We talk with incredulity about how ppl ignore "the facts," but facts will sway nobody."

"Yes, you can "sell" them on adopting the lingo, or maybe you can sell them classes or certificates, but selling them on the hard changes that have to happen to make things actually work is much harder. "

Allen Holub

Influencing agility

OODA Loop - John Boyd

Observe -- situational awareness, Orient -- interpret what's going on, Decide -- to do something or something different, Act -- Do and Adjust. 

POC vs. Prototype vs. MVP - Zignuts.com

1. POC: Identifies the Operational feasibility of the concept. It can either confirm or infirm your thought about the user and your application. 
2. Prototype: Helps you to visualize the actual design and flow of your idea or system., that is the actual blueprint of the idea.
3. MVP: Helps you recognize the core value of your system. It is that version which you can launch into the market to gain valuable product insights from users. 

Cyclomatic Complexity Calculation - with example

Source: Softwaretestingclass.com, Wikipedia, Guru99.com
Keywords: Cyclomatic complexity, Graph Theory

Cyclomatic complexity of a source code is the number of linearly independent paths within it.

Cyclomatic complexity is a way to calculate the complexity of a code. It quantifies the complexity for future source code modifications.

If the source code does not have any control flow statements (For e.g. If, Else, While, Do, For loops in C) then its cyclomatic complexity is 1. A source code with a single IF condition will have two paths through the code so its cyclomatic complexity will be 2. Likewise a code with one IF with two conditions or two nested IF conditions will have a code complexity of 3.

Formula for cyclomatic complexity

M = E - N + 2 * P

E = Number of edges in control flow graph
N = Number of nodes in control flow graph
P = Number of connected components

Complexity Score and Interpretation
=====================

Maintenance POV
==========

A higher complexity score means lower maintainability.

QC POV
=====

From a QC perspective, a higher complexity score means, it requires indepth testing.

Node & Edge
=======

Connected component
=============

A graph with 3 connected component.

Example
=====

Nodes = 8

Edges = 9

CC = E - N + 2 * P

      = 9 - 8 + 2 * 1 (connected component) = 2

Lipstick Agile and other terms

1. Lipstick Agile: Agile for namesake
2. Instagram Agile: Agile for Style, for eyeball count, and to build an online profile for the next gig.

MVP - USTWO

Prioritization Techniques

Kano Model for Requirement Prioritization

Product Prioritization Techniques - Periodic Table (FoldingBurritos.com)

https://foldingburritos.com/product-prioritization-techniques/