NBUFD for Agile Change

• The concept of No Big Up Front Design is applicable to Agile change management (Design) as well. 

• One view is to have every piece of organizational change in place before the transformation can be initiated / continued. Another and more rational view is to work along the way in each initiative, identify the non value adds and remove them.

• The intent to deploy agile coaches is to ensure changes happen across teams that will meaningfully contribute to and transform the organization in their quest for enterprise agility. The notion along this journey that having a x number of coaches, each with their own view of what Agility means will lead to "Agile Fragmentation" may be ill-conceived because the intent is not to have a centralized control over the experience, rather it is to organically grow the abilities of team and in this the agile coaches support and help in clearing the obstacles via NVA removals.

ZBB Essentials - Mckinsey

• ZBB or Zero Based Budgeting is a a budgeting process where on a very granular level, you go through a company's spending and determine what resources various business units require. That means looking at individual cost categories across all business units. The process puts the burden of proof on the manager who's asking for resources. He or she must demonstrate almost on a continual basis the reasons the resources are in fact still required to achieve business objectives. 
• ZBB is fundamentally different from Cost Cutting initiatives. Standard cost cutting programs typically start with a directive to reduce the previous year's spending levels. As a result, executives naturally focus on the largest expense categories -- the tallest trees in the forest. ZBB instead asks everyone to rebuild their budgets from the bottom up, with no carryover from the preceding years. This process identifies many small pockets of waste that add up to big savings.
• ZBB shifts the burden of proof from those tasked with driving cost reductions (finance team or productivity program management office) to the business leaders and front-line organizations which must contribute to both identifying unproductive costs and eliminating them in practice.
•  The whole intent of ZBB is to ensure that right money is behind the right projects.

Skunk Works - Lockheed Martin built (the fighter jet) in 143 Days (courtesy Lockheed Martin and red-gate.com)

Quote this example for Agile / Rapid Delivery

• In 1943, the U.S. Army’s Air Tactical Service Command (ATSC) met with Lockheed Aircraft Corporation to express its dire need for a jet fighter to counter a rapidly growing German jet threat. 
• Engineer Kelly Johnson and his team designed and built the XP-80 Shooting Star in only 143 days, seven less than was required.
• Kelly's 14 Rules & Practices (some of the 14 rules and practices reflect upon the close analogy to agile practices).

• The Skunk Works® manager must be delegated practically complete control of his program in all aspects. He should report to a division president or higher. -->> AUTONOMY

• The number of people having any connection with the project must be restricted in an almost vicious manner. Use a small number of good people (10% to 25% compared to the so-called normal systems). -->> SMALL TEAMS

• A very simple drawing and drawing release system with great flexibility for making changes must be provided. --> NO BIG UPFRONT DESIGN / SMALL 

• There must be a minimum number of reports required, but important work must be recorded thoroughly -->> NO OR MINIMAL DOCUMENTATION

• There must be a monthly cost review covering not only what has been spent and committed but also projected costs to the conclusion of the program. // Funding a program must be timely so that the contractor doesn't have to keep running to the bak to support government projects -->> INCREMENTAL FUNDING (and Review).

• The contractor must be delegated and must assume more than normal responsibility to get good vendor bids for subcontract on the project. Commercial bid procedures are very often better than military ones -->> COLLABORATION OVER CONTRACT NEGOTIATION

• There must be mutual trust between the military project organization and the contractor, the very close cooperation and liaison on a day-to-day basis. This cuts down misunderstanding and correspondence to an absolute minimum. -- >> TRUST / OPENNESS / RESPECT, etc.

Bottomline: This only proves that the Agile principles are indeed tried and tested and not just philosophies of good craftsmanship. 

Importance of various personality traits in an Agile Team - Mckinsey

Fractals and Agile

Fractalfoundation.org

A fractal is a never-ending pattern. Fractals are infinitely complex patterns that are self-similar across different scales. They are created by repeating a simple process over and over in an ongoing feedback loop. Driven by recursion, fractals are images of dynamic systems – the pictures of Chaos. Geometrically, they exist in between our familiar dimensions. Fractal patterns are extremely familiar, since nature is full of fractals. For instance: trees, rivers, coastlines, mountains, clouds, seashells, hurricanes, etc. Abstract fractals – such as the Mandelbrot Set – can be generated by a computer calculating a simple equation over and over.

Mathematical fractals are generated by applying a feedback loop to a system.

Z = Z2 + C

Tathagat Varma. 

• Mathematical fractals unlike natural fractals can keep self repeating indefinitely. 
• They are the best examples of - Simplicity leads to complexity.
• They appear complex, but are essentially repeating a basic shape repeatedly, infinitely.
• Fractals are nature's mechanism to replicate organization without exhibiting a central control. 
• Agility could be modeled as a fractal behaviour of software teams to ensure the core focus on agility loop is always retained, despite scale.
• In practice, the notion of agility at each level would undergo changes but the core behavior of agility loop gets preserved, and allows agility to grow scale free!

How Agile relates to Fractals
=====================

Agile Cereal Box for Product Vision

• Source - Reqtest.com
• Product vision describes the product’s goals and customer value. It relates to the problem that the product solves.
• Vision improves clarity.
• A good vision can be used to accept or reject requirements. 
• Product vision box was introduced by Jim Highsmith and can be used for both traditional as well as Agile projects. 
• Basic idea: create and actual physical box that has to be used to market the product. Common analogy is a Cereal Box.
• Divide team into two. Multiple boxes. Series of intermediate boxes. 
• Takes 40 minutes to 1 hour.
• Front - product name with picture or drawing, slogan, and three to four main selling points. 
• Back - a more detailed view of the product, listing functionality, requirements, etc.

Lean Canvas - Leanstack.com - Ash Maurya

• Lean Canvas is a planning method to get to the heart of your "idea". 
• It is a single-page business plan
• An elaborate business plan with financial forecast and a detailed product road map, many times, may be too early because a lot of this information may be simply unknown during the early stages. 
• Forcing an elaborate plan as a pre-condition to funding silently kills a lots of ideas out of sheer inertia because a lot of things never get started / or the world has changed.
• Lean Canvas is an adaptation of Business Model Canvas.
• 
  

DevSecOps Technology Stack

Code Refactoring

• System entropy (disorder) / decay can be decreased by frequent code refactoring.
• Start a Refactoring Backlog of all the things that need clean up. 
• User retrospectives to discuss refactoring. 

How Scrum Benefits -- Mike Cohn

• Higher productivity and lower costs
• Improved employee engagement and job satisfaction
• Faster time to market
• Higher quality
• Improved stakeholder satisfaction
• What we have been doing no longer works

5 Trademarks of Agile Organizations - McKinsey

• Old paradigm - Organizations as Machine Model aided by principles of scientific management (Taylor).
• New paradigm - Organizations as living organisms

Disruptive trends challenging old paradigm

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

1. Rapidly changing environment

2. Constant introduction of disruptive technology

3. Accelerating digitization and democratization of information

4. New war for talent (acquire, retain, and nurture best talent).

Jack Reeves on Software Design...

The final goal of any engineering activity is the some type of documentation. When a design effort is complete, the design documentation is turned over to the manufacturing team. This is a completely different group with completely different skills from the design team. If the design documents truly represent a complete design, the manufacturing team can proceed to build the product. In fact, they can proceed to build lots of the product, all without any further intervention of the designers. After reviewing the software development life cycle as I understood it, I concluded that the only software documentation that actually seems to satisfy the criteria of an engineering design is the source code listings -- Jack Reeves

The design of a software project is an abstract concept. It has to do with the overall shape and structure of the program, as well as the detailed shape and structure of each module, class, and method. The design can be represented by many different media, but its final embodiment is source code. In the end, the source code is the design. --  Robert Martin

Intentional Programming

"Intentional Programming is a programming paradigm (Charles Simonyi, Microsoft) that encodes in the software source code the precise intention which the programmers ( or users) have in mind."

A Java program that writes numbers from 1 to 10 looks like this.

for (int i = 1; i <= 10; i++) {
    System.out.println("the number is " + i);
 }

However, this does not "does not capture the intentions of the programmer". A modified code would look like this.

for (int i = 1; i <= 10; i++) {
    System.out.println("Printing the numbers 1 to 10 " + i);
 }

TDD encourages intentional programming. You are able to state your intentions (via TDD) even before you code.

TDD vs. Create Test Case After Code

Test Case After Code

Test Case Before Code (TDD)

-         Focus is on artefacts -         Writing tests after the code is a combination of recall of what has been coded and re-reading. -         Relies much more on the discipline of the coder. -         As a coder you may end up writing more code than is necessary when doing a test case after code

-         Requires coder to have a clue about where they are heading with the code. -         It is the beginning of a detailed code design -         We use the tests to literally drive function into the code, so that the fit between the test and code is much higher. -         By writing a test before we are challenging ourselves to pass it. -         TDD creates a narrowed focus, a narrow bandwidth to solve the issue on hand thereby ensuring optimized solution.

By writing test first, we force ourselves to design the program to be both testable as well as callable. This leads the class to be decoupled from its surroundings.

Diagram courtesy: Cohn

• TDD takes about 15% longer than not doing TDD. But there is evidence that TDD leads to fewer defects. Bugs go down by 24% to 38%.
• TDD may initially take a longer time, but will benefit the team in terms of reduced defects, reduced bug fixing and maintenance time.
• 
  

SOLID Principles

Courtesy: Uncle Bob

SOLID is an Acronym for the five Object Oriented design principles

• S: Single Responsibility Principle
• O: Open-Closed Principle
• L: LISKOV Substitution Principle
• I: Interface Segregation Principle
• D: Dependency Inversion Principle

Single Responsibility Principle: A Class should have only one reason to change.

"If a class has more than one responsibility, the responsibilities become coupled. Changes to one responsibility may impair or inhibit the class's ability to meet the others. This kind of coupling leads to fragile designs that break in unexpected ways when changed."

Christopher Avery's views on Organization as a Living System.

Organizations are living systems. We can never direct a living system, only disturb it and wait to see the response. We can't know all the forces shaping an organization we wish to change, so all we can do is provoke the system in some way by experimenting with a force we think might have some impact, then watch to see what happens -- Christopher Avery's views on Organization as a Living System.

There can't be an End State in a process that calls for continuous improvement

 -- Mike Cohn...

Succeeding with Agile Software Development - Mike Cohn

Why transitioning is hard

1. Successful Transition is neither top down or bottom up ONLY. 
1. Successful change is both top down and bottom up. "Change is best introduced bottom up with support at appropriate points from the management - both local and at a higher level". An organization attempting transition without top management support will encounter resistance that cannot be overcome from below (happens when the process begins to affect areas outside the original team). Without bottom up engagement, the transition will feel like sitting under a ceiling fan in an open air restaurant in Mexico; just a bunch of hot air blowing down from above. Individuals resist being told what to do.  
2. The end state is unpredictable. 
1. "Having a chance to change or personalize a process (or a framework or practices -- XP, Scrum, or another) to fit themselves seems to be a critical success factor for a team to adopt a process." 
2. You may have a clear vision of what "doing Scrum" means to you, and you may get others to buy into exactly that same vision, but where the organization ends up is likely to be somewhat different. In fact, to even refer to end states in a Scrum transition is incorrect; there can be no end state in a process that calls for continuous improvement. 
3. This creates a problem for an organization that wants to transition to Scrum thru a traditional change approach that relies on gap analysis and then on closing the identified gap. If we cannot anticipate the end state of a Scrum Transition, we cannot identify all of the gaps between there and the current state. So, a gap-analysis driven approach will not work. The closest we can come is to identify gaps between where we are now and an improved, intermediate state.
4. Organizations are living systems. We can never direct a living system, only disturb it and wait to see the response. We can't know all the forces shaping an organization we wish to change, so all we can do is provoke the system in some way by experimenting with a force we think might have some impact, then watch to see what happens -- Christopher Avery's views on Organization as a Living System.
5. Transition to Scrum cannot be a process that "articulates and defines the entire change process required to bridge the gap between "as is" and "to be" and creates tactical plans." Creating such a plan would require leaping two impossible hurdles - first knowing exactly where we all want to end up; and second, knowing exactly the steps to get there. Because we cannot overcome these impossibilities, the best we can do is adopt a "Provoke and Observe" approach in which we try something, see if it moves us close to an intermediate improved state, and if so do more of it. These pokings and proddings of the organization are not random. They are carefully selected based on experience, wisdom and intuition to drive a successful transition to Scrum.
3. Scrum is Pervasive:
1. Affect an Individual at a very fundamental level. A change like, say, "introducing an operational readiness check" is an isolated change. This is not a pervasive change; even if the dev team has to go for it, the change is unlikely to affect them fundamentally in how the accomplish their daily work -- they can still continue doing the majority of their work unscathed. As a comparison, a developer transitioning to scrum will need to change herself fundamentally -- work on smaller pieces of work, do TDD, write automated tests, remove off headphones while doing pair programming, and a lot more. These changes are not something to be relegated to a few hours a week like code inspections. Resistance in such cases will be a lot more.
2. Affect has implications beyond the team adopting it. For example, introducing operational readiness check may not have impact on finance, sales and other departments, but introducing Scrum will definitely impact those departments. 
4. Scrum is dramatically different.
1. On Scrum, members need to unlearn their past behaviors (testers testing to compliance, programmers trained to analyze problem in depth for a perfect solution, etc). They need to adjust to the concept of emergent design. 
5. Change is coming more quickly than ever before. 
1. Change is coming too fast, too often and teams are mostly not prepared for change. Teams are asked to do more with fewer people. Outsourcing and distributed teams are now more common. Constantly accelerating change of technology. 
6. Adopting best practices 
1. Is dangerous for Scrum - what works for one team doesn't work for another.

Satir change model

Courtesy: Virginia Satir

Doing-Being Agile

Evolutionary Delivery

Courtesy: Exoftware

Future Backwards

Courtesy: Andrew Rook, Cognitive-edge.com

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

The Future, Backwards method was created to aid in widening the range of perspectives a group of people can take on understanding their past and the possibilities of their future.

Typical Uses

=========

1. As an alternative to traditional strategic/scenario planning which place excessive emphasis on ideal future states.
2. To embed lessons from organisation’s past in decision making
3. To aid in conflict resolution between different groups with opposing views

How To

======

1. Divide participants into groups. 6-10 people per group.
2. Time box
3. Start with current state ("Here" below). Within 5 mins ask the teams to write as much about the current state as possible. (One per post it note)
4. When time box is up, have the group write about the most significant recent event preceding the current state. [this forms the History, backbone).
5. Now ask them to write the Good and the Bad (Improvements) currently.
6. Follow it up with the Good and the Bad of the future. The "bad" of future is risk management.

Narrative Paradigm

My personal disposition towards human narratives has been this. [Never heard of Walter Fisher until today.] 

• Every human experience is a narrative, a story to be told later.
• You see / view, remember things selectively based on your conditioning, underlying belief system, and your prejudices. And when you recall them from memory you apply the same paradigm to weave a shape out of it. 
• You are perceived by how beautifully you are able to narrate this to others - what ingredients it has, and how impactful it is and can connect with the audience / listener.
• Different people looking at / experiencing the same experience will narrate it differently  - Rashomon Effect - each a Truth on its own. 

Walter Fisher's Narrative Paradigm

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

• Everything we do can be laid out as a story.
• Humans are essentially story tellers. 
• What we do and how we think is swayed by history, biography, culture, character. 
• Rationality is determined by -- 
• a. Narrative probability: coherence of narrative
• b. Narrative fidelity: whether the story rings true with what we already know to be true.
• We continually choose stories that we keep company with. And these stories are constantly changing.
• Narratives are selective realities. We choose what we want to believe (influenced by ext factors).

Best examples of selective narrative paradigm as a selective reality is Media.

Lean Coffee

Lean Coffee - Facilitator's Guide
=======================

https://medium.com/agile-outside-the-box/lean-coffee-facilitator-s-guide-d79d9f13d0a9

Lean coffee format
==================

1. Set Up (To Do, In Progress, Done)
2. Collect Ideas
3. One sentence introduction of the topic
4. Dot vote
5. Prioritize
6. Discuss
- Time box ( 5 minutes)
- Vote (next item or 2 more minutes)

Excerpt from Lean Product Management - Mangalam Nandakumar

• "The engineering that went into the honeycomb contributes to a specific way of life that is suited to the bees. It is important to realize that the first bees didn't initially build wax hexagonal tubes. They iterated over many generations and responded to feedback from nature (which is often harsh and can result in extinction). Bees have pivoted to this model and it seems to have worked rather well for them."
•  "Engineering in isolation adds no business value".
• "Business functions acting in isolation without the context of business outcomes or creating value to the customer are not sustainable".
• What works for bees doesn't / may not work for ants.
• On why delivering value is important--
• "By carrying over software delivery frameworks of meeting timelines, budgets, and customer satisfaction, we are in a way restricting ourselves to looking at outputs instead of outcomes."
• "Product management shouldn't be about measuring effort or productivity; it isn't about measuring output"
• 
  

DIY Sprints (Design Sprint)

Courtesy: Jake Knapp

• Monday: Map out the problem and pick out an important place to focus.
• Tuesday: Sketch competing solutions on paper
• Wednesday: Make difficult decisions, turn ideas into testable hypotheses
• Thursday: Hammer out a realistic prototype
• Friday: Test with real human beings

Japanese Lean Terminology

Chaku Chaku

==========

Chaku chaku is an efficient style of production in which all the machines needed to make a part are situated in the correct sequence very close together.

The operator simply loads a part and moves on to the next operation. Each machine performs a different stage of production, such as turning, drilling, cleaning, testing or sandblasting.

Example...

Gemba

======

Gemba walk is an essential part of lean management philosophy. Gemba is the factory floor where the actual value is produced. The philosophy behind Gemba is problems in business process or production become visible / best improvements come from by actually "visiting the place where value is created" -- Go and See the work as it is being produced. It encourages communication, transparency and trust. Shouldn't be employed to point of flaws of employees.

Hanedashi [Lean Manufacturing]

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

Device or means of automatic unload of the work piece from one operation or process, providing the proper state for the next work piece to be loaded. Automatic unloading and orientation for the next process is essential for a “Chaku-Chaku” line.

Hansei 

=====

Reflection / self reflection. Similar to retrospective / post-mortem, review. Look at yourself in the mirror.

Design Sprint

Courtesy: Jake Knapp

• A Design Sprint is a time-constrained, 5 phase process using design thinking to reduce the risk of bringing a product, service or a feature into the market. 
• Savioke's 5 Day Process is summarized below: [Savioke considered dozens of ideas for their robot, and then used structured decision making to select the strongest solution to prototype and test the idea with customers]. Objective was to come up with a prototype that delivered one specific functionality (delivery a single toothbrush to a guest).
• 1st the team cleared a full week off their calendars with OOO replies.
• Manufactured a deadline
• Made arrangements with hotel for a live test on the Friday.
• Now there were only 4 days to design and test.
• Day 1: Savioke reviewed everything they knew about the problem. [they reasserted the importance of Guest satisfaction after every service, which the hotel religiously tracks]
• Savioke created a map to identify biggest risks. (A Customer Journey Map kind of -- Guest meets robot, robot gives customer toothbrush, guest acknowledges the receipt, etc.). There may also be other points where Guest-robot interaction could take place. Team had to prioritize where to spend the effort based on the risk it carried.
• Some challenges: Where to start (eventually team chose The Moment of Delivery, Should we make robots appear smarter - some people may try to interact with the robot and if they didn't respond people might be disappointed, etc.
• Day 2: Team switched to problem solving. Instead of brainstorming each member came up with own solutions -- CEO, Head of Bus Dev, Chief Robotics Engg, everyone participated and came up with own solution. 
• Day 3 (goal was which ideas to test and document potential soln in detail so that only the execution is left out): Sketches, notes on conf hall walls, old ideas discarded, 23 competing solutions. Voting and structured decision to narrow down ideas. 
• Day 4: Execution. programmed and tuned up robot's movements (laptop and playstation controller, sound effects, face mock up.
• Day 5: Live Test. Lined up interviews with guests, duct-tape webcams etc.