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.
•