Vishwanath Ramdas

Agile Management for Software Engineering

Applying theory of constraints for business resultsDavid J Anderson

qqqq Represents high impact insights in the book, tagged for quick browse

Vishwanath Ramdas

THERE IS NOTHING LIKE READING THE BOOK..READ IT..

http://www.amazon.co.uk/Agile-Management-Software-Engineering-Constraints/dp/0131424602

Vishwanath Ramdas

Eli Schragenheim - Improving the flow of the Features that truly bring value to the customer and also have a good chance of

generating revenues for the software organization is what this unique book is all about.

• The relevance of the Theory of Constraints (TOC) to the software industry is twofold:– Vastly improving the flow of new products to the market.

• The Agile Manifesto principle of "Our highest priority is to satisfy the customer through early and continuous delivery of valuable software" is fully in line with the Theory of Constraint's objectives.

– Determining the real value of a proposed project, or even just a feature, to the final user. The underlying assumption is that if we know the real value to the user, it is possible to develop the right marketing and sales approach to materialize the value to the user and to the software organization.

• Learn how to make more with less. – Don't accept every claim David raises just because he says it is so. If you truly

want to make more with less, you need to be able to internalize the claim. – All I ask is you give it a chance. Dedicate time in order to rethink your

environment, and then see for yourself what to do. Overcoming inertia is the biggest challenge of any really good manager in any organization.

• A new Feature can bring value to the user only if it eliminates, or vastly reduces, an existing limitation– the examples of the value of “spell check” feature to end users

FO

REW

OR

D

qqqq

Vishwanath Ramdas

"Poor management can increase software costs more rapidly than any other factor” - Barry Boehm

• "if the only way this can be done is badly, then let me do it badly at a fraction of the cost."– Senior executives, perplexed by the spiraling costs of software development

and depressed by poor results, poor quality, poor service, and lack of transparency are simply shrugging their shoulders and saying,

• The result is a switch to offshore development and layoffs.’• many techniques do exist that can improve the competitiveness of

software development businesses that have been proven in other industries. Techniques such as the – Theory of Constraints [Goldratt 1990a], – Lean Production [Womack 1991], – Systems Thinking [Senge 1990],

• Improvements of 4 times are easily achieved. – The Agile manager must construct an Agile learning organization of

empowered knowledge workers and results will be dramatic. – 10 times is definitely possible. Imagine if your software engineering

organization could do 5 times as much work in half the time it currently takes. • What would it mean for you, your job, and your organization?

INTR

OD

UC

TIO

N

Vishwanath Ramdas

Accept Uncertainty, Manage with Transparency

• Knowledge work isn't like manufacturing. – Knowledge work is neither linear nor defined

• For e.g. Stamping out car bodies can be performed with a high degree of certainty. Failures and errors are rare.

• Manufacturing is in many ways predictable, linear, and, in the case of chemical processes, defined by scientific rules.

• The secret is to manage the right things and to do so with transparency • Management must learn to accommodate greater Uncertainty• IT staff/workers turn up for 4 Reasons

– The Cause – The Technology Challenge– The Money – The Boss [ this is the focus of the book]IN

TR

OD

UC

TIO

N

qqqq

Vishwanath Ramdas

The Agile Manifesto: The word "agile" implies that something is flexible and responsive and has an innate ability to cope with

change. Methods enable survival in an atmosphere of constant change and emerge with success.

– We are uncovering better ways of developing software by doing it and helping others do it.

– Through this work we have come to value:• Individuals & interactions over processes and tools• Working software over comprehensive documentation• Customer collaboration over contract negotiation• Responding to change over following a plan

– That is, while there is value in the items on the right, we value the items on the left more.

• Kent Beck, James Grenning, Robert C. Martin, Mike Beedle, Jim Highsmith, Steve Mellor, Arie Van Bennekum, Andrew Hunt, Ken Schwaber, Alistair Cockburn, Ron Jeffries, Jeff Sutherland, Ward Cunningham, John Kern, Dave Thomas, Martin Fowler and Brian Marick

– © 2001, the above authors, this declaration may be freely copied in any form, but only in its entirety through this notice.

INTR

OD

UC

TIO

N qqqq

Vishwanath Ramdas

12 Principles of Agile:

• Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

• Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

• Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

• Business people and developers must work together daily throughout the project.

• Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

• The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

• Working software is the primary measure of progress.

• Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

• Continuous attention to technical excellence and good design enhances agility.

• Simplicity—the art of maximizing the amount of work not done—is essential.

• The best architectures, requirements, and designs emerge from self-organizing teams.

• At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

http://www.agilemanifesto.org/principles.html IN

TR

OD

UC

TIO

Nqqqq

Vishwanath Ramdas

Chapter Summary

Ch

ap

ter

Nam

e

1. Objectives 2. Guidelines 3. Principles

1. Facts 2. Execution Apporaches

1. Benefits, Outcomes 2. Value

1. Best Practices 2. Innovations

1. Risks, Danger, Fear Perceptions2. Issues

1. Downside, Problems

Vishwanath Ramdas

Agile Methods is not a Fad but a trend: Rightly understood, management is a liberal art, drawing freely from the disciplines

that help us make sense of ourselves and our world. That's ultimately why it is worth doing – Magretta 2002

1. Lean Production at Toyota produced a 10 time improvement over its American mass production competitor

2. Can / If Agile software development do 4 time improvement within 9 months

3. Software development is about making more profit, not about making great code.

1. Defines 4 basic roles that form a 2-tiered management model along with set of practices for each role.

1. Methods to report believable, familiar statistics and have meaning to the business.

2. Demonstrate the economic advantages and focus on real business benefits.

3. Argue a business case based on hard numbers indicating better profitability and higher return on investment.

1. Framework to scientifically measure and assess Agile methods based on - Throughput Accounting from TOC

2. Agile Maturity Model: inside-out approach to phase out capability as working practices , traceability, metrics, learning, and eventually financial metrics and results.

1. Agile methods propose some unusual working practices. E.g. Extreme Programming

2. The strange language and the strange practices scare management

3. Agile methods introduce scary counter intuitive working practices.

1. Agile brings its own jargon and vocabulary not understood by management

2. Agile is adopted not based on hard facts and benefits but more as a FAD

INTR

OD

UC

TIO

N

Vishwanath Ramdas

The best companies in an industry build process that allows them to outperform their competitors“ - Louis V. Gerstner [2002]

• Peter Senge's fifth discipline [1990]–Systems Thinking– Approach the management of software engineering as a holistic business

problem. – Profitability and investment return from software engineering is treated as a

"limits to growth" system archetype. – "Limits to growth" systems archetypes can be addressed and improved using

Eli Goldratt's Theory of Constraints [1990].

1.

Th

eori

es f

or

Ag

ile M

an

ag

em

en

t

Vishwanath Ramdas

Theories that support and enable agile software development

• The Theory of Constraints– Underlying assumption: Production is as fast

as the slowest process in the chain. – Value chain is only as strong as the weakest

link in the chain. – Identify bottlenecks [capacity of the weakest

link] = current system constraint.– Exploit constraint - rate of throughput in

constraint is system throughput – Technique is known as Drum-Buffer-Rope. – Thereby Reduce inventory of material

throughout the system.• Just-in-Time Inventory

– Toyota Production System [Kanban Approach] - Taiichi Ohno [Ohno 1988].

– Minimize inventory in the factory – Ohno had based the technique on methods

used by American grocery store chains, ROI = {Throughput – Ops Expense}/ Value of System Inventory

– Throughput Accounting, reducing inventory reduces the level of investment. Competitive advantage of lower inventory levels is reduced the financing charges cost of storage space, thereby reduced Operating Expense (OE) and increased profitability.

• Total Quality Management– Japanese realized that better quality was

important – Quality Assurance - Edwards Deming through

Statistical Process Control (SPC) theory, – Interpret the control charts of Walter

Shewhart [Wheeler 1992]. – Improved quality improves the throughput of

a system. – TQM espoused the notion that manufacturing

could be more efficient (read "profitable") if quality were improved.

– Quality could be improved through improved traceability, which would provide audit trail information for verification and validation of quality.

– TQM gave rise to ISO-9000, Tick-IT, and other quality-related initiatives.

– Upstream process was the "supplier" and the downstream process the "customer."

– Everyone had an "internal customer" for their work.

– Quality improves production because it reduces rework. = less waste, less OE, and a higher Production Rate (R).

1.

Th

eori

es f

or

Ag

ile M

an

ag

em

en

t

qqqq

Vishwanath Ramdas

Theories that support and enable agile software development

• Lean Production– "Lean" was first coined by Womack and

colleagues in their book, The Machine That Changed the World,

– The Toyota Way," – The management method can be used beyond just production.

• Six Sigma– Refers to a defect level of less than four

per million [~represent perfection]– Improved quality and focused

investment to eliminate errors. – Associated with General Electric and

Motorola.– Two focus areas: quality assurance and

reduction of variance. – Better to have defects with a repeatable

pattern - common cause can be found

• Comparison & Evaluation of the Theories– TOC originally focused on bottlenecks. – JIT originally focused on reduction of

inventory. – TQM and SPC were focused on quality

and conformance to specification. – Lean is the effective combination of all

of them. – Six Sigma also focuses on quality and is

complementary to Lean – Theories produced an immense

economic improvement for society– e.g amazingly complex technical

products like DVD players < $20. • Has Improved Profitability Been the

Only Benefit?– Improved overall competitiveness. – Manufacturing is now more flexible and

faster to react to market conditions. – Mary Poppendieck [Lean Programming]

states that the theories of JIT and TQM can be applied to software development [2001].

1.

Th

eori

es f

or

Ag

ile M

an

ag

em

en

t

Vishwanath Ramdas

Three Phases of Scientific Development: Eli Goldratt suggested that the sciences evolve in three distinct phases

• Phase 1—Classification– Debate and standardize nomenclature is debated and agreed upon. – Agile Software Development: XP, Scrum, and FDD, though may not yet be complete. – OOAD : UML Modeling frameworks– Scott Ambler's Agile Modeling Initiative – ongoing effort – Agile methods as a combined science can be considered to be in the classification stage.

• Phase 2—Correlation– Corroborating evidence to show that a method works in practice. Correlation is a phase

of pattern recognition. – E.g Astrology to Astronomy | Alchemy to Chemistry – OOAD: Analysis Patterns [Fowler 1997], Object Models [Coad 1996], JAVA Modeling in

Color with UML [Coad 1999], and Streamlined Object Modeling [Nicola 2001]. Design Patterns [Gamma 1995]

– Agile: There is some evidence on the results • Phase 3—Effect-Cause-Effect

– Astronomy became a science after Isaac Newton proved why apples fall down, rather than sideways.

– For software management to be developed into a science, agreement must be reached • what is to be measured and what those measurements are called. • How one measurement affects another must be understood.

1.

Th

eori

es f

or

Ag

ile M

an

ag

em

en

tqqqq

Vishwanath Ramdas

Systems Thinking and Learning Organizations - Approach organization holistically , the first step towards learning. Systems

have feedback [learning] to provide opportunity for improvement.

• Empirical Versus Defined Processes – Schwaber and Beedle published their book describing

the Scrum method. – Webster's dictionary defines empirical as "Depending

upon experience or observation alone, without due regard to science and theory."

– Impacts how we measure measurements around observation repetition

– Schwaber defined that empirical processes are "chaordic," [lives on the edge of chaos]

– Used this to argue - that there is no point in planning • Convergent Versus Divergent Processes

– This may be more critical to how we control and manage processes

– Convergent = under control process will converge over time on a predictable solution.

– Divergent = under control produce inconsistent results

• Chaos Theory and Uncertainty– Renee Descartes [1625] - suggested that everything

could be gradually decomposed to scientifically explain behavior and composition.

– Its corollary held that something that was not understood simply had not been sufficiently decomposed.

– In contrast The principle of uncertainty [Hiesenberg] is closer modeling of reality

– TOC helps manage the business systems to cope with uncertainty

• Emergence– Phenomena described as "emergent." -- Complex

Adaptive Systems. – Simple rules govern the internal behavior of the

system, which results in the externally observed adaptive behavior.

– Understand what the simple rules are that produce often amazing results.

– Simple rules are what inspire ants to build great anthills and to work as a team to perform tasks that ought not to be possible for such basic creatures.

– software development is a complex adaptive system, – Agile Manifesto principle, "The best architectures,

requirements, and designs emerge from self-organizing teams."

– The proper jobs of executives are to set the goal for the adaptive behavior of the system and to select the method with which the goal is measured and the system feedback delivered.

– In addition, they may need to create an environment within which the complex adaptive system of software development can exist freely to self-organize at the appropriate level.

– What is important is that those setting the rules set rules that reflect the nature of the system holistically, which leads to delivery of global optima rather than local efficiencies

On anthills, it is predictable that a nest of ants will build an anthill. The size of the anthill and the area it will cover can be predicted with some certainty, based on knowledge of the type of ants and the population. What cannot be predicted is the precise shape, the precise time of completion, or the necessary level of effort. Nevertheless, predicting the growth of an anthill is like predicting the weather, it can be done with a degree of accuracy. It is not chaotic.

1.

Th

eori

es f

or

Ag

ile M

an

ag

em

en

t

qqqqqqqq

Vishwanath Ramdas

Agile Management

Section I

Vishwanath Ramdas

Consider the stages of the transformation of an idea into tangible working code.

• Systems are non-linear, have feedback and exhibit adaptive behavior– Systems have balancing loops which

makes the system to adapt • Systems thinking is difficult

– People tend towards detailed complexity [large projects, software code ]

– Systems complexity with feedback mechanisms and sensitivity is more difficult

– Understanding inherent complexity with varying rules and effects is difficult

• Throughput accounting for education.– Unit of Inventory = Pupil– Value of Inventory = Knowledge of Pupil– Investment = KnowledgeInput =

ValueInput– Value Added = ValueOutput - ValueInput– Throughput = KnowledgeOutput-

KnowledgeInput• To Summarize [in order]

– Increase Throughput (T)– Decrease Investment (I)– Decrease Operating Expense (OE)

2.

Man

ag

em

en

t A

ccou

nti

ng

for

Syste

ms "Tell me how you will measure me and I will tell you how I will behave.“ - Eli Goldratt [1990b]qqqq

qqqq

Vishwanath Ramdas

TOC is a method that helps Focus on the right problem within the value chain

3.

TO

C in

soft

ware

pro

du

cti

on

1. The Value chain is only as strong as the weakest link

2. The system is subordinate to the capacity constrained resource [CCR] – where inventory pileup happens

1. Identify the System Constraint.2. Decide how best to exploit the System

Constraint.3. Subordinate everything else to the decision in

step 2.4. Elevate the Constraint.5. If steps 1 through 4 have created a new

constraint, return to step 2.

1. TOC ensures that excess inventory in the system is eliminated, especially critical for perishable inventory

2. Assessment of incremental investment is done through throughput accounting

1. Exploiting the CCR is an area for innovative problem solving, waste elimination [Lean]

2. Subordination is driven through Drum-Buffer-Rope [Takt Time + Kanban]

3. Balance the flow of product through the system

4. Hire and develop Good people

1. Subordination to the CCR could / may result in stress elsewhere [ Road Runner behavior]

1. Systems can have multiple constraints that impede the flow

2. Choosing and recognizing constraints correctly is critical to successful TOC

qqqq

Vishwanath Ramdas

Uncertainty in software process is inevitable, which acts on the 5 general constraints at 4 levels

4.

Dealin

g w

ith

un

cert

ain

ty

1. There are 5 types of general constraints 1. People, Resources, Budgets,

Functionality, Time 2. There are 4 types of Uncertainty

1. Variability Foreseen, Unforeseen, Chaos

3. Uncertainty is handled through provision of a buffer

1. People constraints are most critical2. Time constraints could be externally driven as

in compliance and regulatory requirements3. Manage Scope constraint through tier-ing by

need e.g. “good to have” and by time4. Variation & foreseen uncertainties are

endemic and are called “common cause”5. Chaos & unforeseen >> are “Special Cause”

1. a 1. Add people buffers to the project early [ brooks law >> adding people to a late project makes it later!]

2. Time buffer is dependent on maturity and level of uncertainty

3. Complexity & Risk analysis are key to providing estimates without local safety

1. It is important that senior management see that buffer for people are needed as people are the most critical constraint

2. Good relationship /trust with users / business is critical to scoping

3. Creating too much local safety results in over buffering

1. Broken promises on scope and time are bad for business

2. Revealing “dark matter” is critical in the early stages of software design and architecture

qqqq

Vishwanath Ramdas

Uncertainty in software process is inevitable, which acts on the 5 general constraints at 4 levels

5.

Soft

ware

pro

du

cti

on

Metr

ics 1. focus on simplicity and relevance to the

system goal. 2. Metrics should be self-generating 3. Metrics should provide leading or predictive

indication of the system performance rather than lagging or reactive performance

4. Should relate to financial or economic goals

1. Throughput is the most important metric, shift from effort driven metrics

2. Non-functional requirement lead to measuring throughput, but one should follow minimalism

3. Tasks are not inventory – don’t represent customer interest

1. Operational Expense [OE]1. Average Cost per Function[ACPF]

2. Investment in the flow [I]1. Inventory levels in the flow [V]

3. Throughput of the flow [T]1. Production Quantity [Q]

4. Finance >> T I OE1. Production >> Q V ACPF

1. Littles Law >> inventory in the system is directly proportional to the lead time given throughput as a constant

2. Reinersteins advice – Metrics should be simple, relevant, self generating and lead indicators

1. Clients don’t value tasks and other inputs 2. What is inventory? In the flow?

1. Measurements that are effort and input driven which don’t add much value to the customer

2. Measurements that are complex and manual to maintain

3.

qqqq

Vishwanath Ramdas

Manage Software based on the level of uncertainty. Time, Budget and Scope are in increasing sequence of uncertainty.

6.

Ag

ile P

roje

ct

Man

ag

em

en

t

1. Agile methods require a negotiable scope and an agreed scope buffer in order to be successful

2. This requires trust between customer & team

1. Feature driven delivery FDD extends the model to make both Scope and budget flexible though tightly bound

2. Effort / task based planning does not represent systems thinking

3. PM needs to assist flow through maintaining issues log that impede the flow

1. Focus on better quality information for manage to enable decisions

2. Focus on outcomes and throughput and how it can be delivered on promised time

3. Segregate costs from value that customer perceives

4. Highlight issues and risks and deliver throughput early

1. Koskela & Howell >> 3 dimensional Model of Flow of Value through transformation

2. TA* depreciates incomplete code on time vs Cost accounting that appreciates code based on effort

3. TA considers efforts as OE not value, no need to timesheet

1. Traditional PMI, fix scope and focus on close estimates – worst case! with varying timelines for outcomes!

2. Traditional Cost accounting assumes that effort == earned value! [time-sheets]

* Throughput Accounting

qqqq

Vishwanath Ramdas

Project Planning is the process in which delivery uncertainty is managed [buffer, groups, parallel workflow] to ensure throughput

and timeliness

7.

Ag

ile P

roje

ct

Pla

nn

ing

1. Products are built from assembles that are done in parallel [feed chains]

2. Grouping is based on testing and release 3. Move away from local safety to group safety,

reduces overall buffer in the system

1. Develop CPM and PERT to plan 2. Non-Critical path items should be developed

based on cost implications not AEAP3. Monitor the buffer usage of each feeding

chain – constantly 4. All inventory that are blocked should have

issues logged5. Main constraint =Schedule/Time/Delivery date6. PERT should factor in resource Constraint

1. Measure – Buffer Usage through progress

1. Goldratt asserted that everything eventually hits the critical path

2. The resource constrained buffered plan is called the Critical Chain

1. How to buffer for parallel & serial tasks?

1. Hidden Assumption that all developer skills are equal

2.

qqqq

Vishwanath Ramdas

There are 4 management roles to define the new paradigm of agile software development

• Development Manager– Runs the system for software

production, maintain continuous flow– Motivate the team and understand the

development environment– De Lucas first law “Managing a team is

80% psychology & 20% technology”– Increase productivity, remove

constraints– Owns:Production Rate[R], Lead time [LT]

• Program/ Release Manager– Owns a Collection of project, what may

be called a platform, portfolio • Mcgrath Defines this as product line

strategy – Manage release sequence, control the

Rope in DBR and feed the constraint– Owns: Throughput[T], Inventory[V]

• Product Manager– Manages release or product mix,

defines what is the input to the flow– Manages the features to be released

based on throughput and development capabilities

– Generates ideas and captures requirements

– Owns: NP, ROI, Investment [I], AIPF

• Project Manager– Manages a specific release through the

code production flow – Does project planning [Ch. 7]– Issues, CCPM, PERT,CPM– Owns: Issues control, Buffer

8.

Th

e a

gile M

an

ag

ers

New

Work

Vishwanath Ramdas

Smooth flow can be interrupted by three causes: a bottleneck, poor quality, and an overly large batch size

9.

Ag

ile D

evelo

pm

en

t M

an

ag

em

en

t

1. Inventory piles up at the point where production rate is minimal

2. Use the right batch size to optimize the flow1. Batch reduces setup but increases

Queue time, waiting, fatigue, LT.. 3. Intellectual efficiency is the avoidance of

waste in the flow

1. Investigate reasons why stockpiling happens?2. Use Visual control for awareness & decisions

1. Calculate true cost of bottleneck using TA, at bottlenecks, lost time cant be recovered

1. What is the loss of capacity in cost and value terms

2. What is the true cost of Quality?1. The capacity and prodctivity impact of

re-work

1. In Projects, inventory is a better lead indicator than Lead time

2. Quality is more expensive, downstream in the flow as more areas would need rework, multiplying the impact

3. Capers Jones and Karl Wiegers [2002] studies suggest 10% of effort in developer peer review results in 45% defect reduction, 65% if unit tests are included and 80%if formal inspections are done

4. Small batches result in smooth flow5. The less pronounced S the better the team

1. It is dangerous to assume that bugs stand in isolation, when code fails regression testing, there may be multiple units of production lost through multiple stages of the system resulting in large loss of effort and outcomes

2. Too small a batch size results in high setup time [ context switching]

1. In software development, bad management gets compensated by free overtime, abuse of engineers

2. Large batches create execution fatigue resulting in defects

qqqq

Vishwanath Ramdas

Control the release of software inventory in order to reduce the WIP inventory, lead time, operating expense and waste caused by

excess queue and wait times.

10.

Soft

ware

Resou

rce P

lan

nin

g

1. Subordinate the MRP to the CCR [ TOC -3]2. Do not swamp or starve the CCR 3. Do not process the wrong or stale material4. Waste must be minimized.

1. Use Drum-Buffer-Rope system for production subordination,

1. CCR is the drum | production rate the beat | inventory buffer is the rope that protects CCR from starvation

2. use cumulative flow diagram to monitor production rate and inventory in the system

1. Requirements that get scrapped before delivery

2. Waste will increase if lead times are long. 3. Reducing LT has a positive derivative affect

on R and OE. 1. Increased LT >> More Waste >>

reduce R and increase OE.

1. Extreme Programming, is adept at coping with expediting. As it is "serial expediting."

1. As everything is an expedite request,2. No additional cost for short order

requests

1. Change requests can have an impact on the analysis, design, and coding of a software project

1. Swamping could result in expedition of work which has adverse effects.

2. Longer LT due to swamping results in time risks

3. Too much defects results in analysis paralysis

Vishwanath Ramdas

The Learning Organization Maturity Model: To examine whether business is under control and whether it is focused on making a

profit.

11.

An

Ag

ile M

atu

rity

Mod

el Stage Title Essence Todo

Stage 0 Analysis Ability 1. Decompose system input into basic units of measurement.

Stage 1 End-to-End TraceabilityTom DeMarco correctly observed, "You cannot control, what you cannot measure" [Wiegers 1996]

1. Implement system for capturing & monitoring measurements.

Stage 2Stabilize System Metrics

Demonstrate that software development can be brought under control with conformant quality. [ i.e. within some acceptable tolerance]

1. Inventory; lead time; production rate; 2. Demonstrate basic statistical process

control3. Show that system is stable against a

target and within a tolerance.

Stage 3System Thinking and a Learning Organization

gradually tightening the screws on the achieved metrics; look for the constraints, to determine how best to exploit them, to subordinate the rest of the process to that decision, and then to consider investment in order to elevate the constraint

1. Focus on continuous improvement. 2. New targets: lower inventory, shorter lead

time, higher production rate. 3. Identify constraints; exploit constraints;

subordinate to decision; elevate constraint.

Stage 4Anticipated ROI and the Failure Tolerant Organization

Not afraid to push the boundaries or to take on projects with high risk. An environment in which line managers are unafraid to take risks Organization must be completely mature along its entire value stream software system does not work in isolation

1. Encourage risk taking. 2. Focus on Throughput ($), not production

quantity. 3. Focus on market research/feedback (i.e.,

external constraints).

qqqq

Vishwanath Ramdas

The essence of Agile is to be highly delegated, "self-organizing." : plans should at a high level and the desired adaptive behavior

should emerge from the system.

12.

Sett

ing

th

e G

overn

ing

Ru

les

1. Establish the simple rules governing the system of software production

2. Focus on behavior & adaption, and tweak when outcomes are not observed

3. Main goals for managers: 1. Skills Gap Education2. End to End Traceability [V R LT]3. Production Metrics 4. Continuous Improvement5. Fault tolerance Organization

4. Engineers must be encouraged to focus on exploiting themselves as a capacity constrained resource

1. process that allows tracking requirements through the lifecycle must be introduced first

2. Introducing end-to-end traceability in the software development lifecycle is a nontrivial first step. This first barrier to entry defeats many organizations

3. Expected ROI metric, as the control of reward4. that team members understand what is being

measured and why

1. Reinertsen's Three Tiers of Control 1. Executives : Select system & Define

governing rules.2. Managers: Set tolerances & rules for

variance3. Staff: Adapt based on feedback from

system metrics.2.

1. Rules based on Maturity and ROI 2. Incentive based on overall system, rather than

local, production rate results in systems thinking

1. Engineers can be afraid of measurement schemes. They may rebel against them from fear of misuse

1. [DeMarco and Lister] Process improvement is primarily focused on quality, estimation scope

2. in CMMi, organization develop balanceing loop at high maturity and stagnate [risk averse, not take up truly valuable projects]

3. Production rate metrics fail to sustain challenge over long term, through wrong incentives

Vishwanath Ramdas

Taking Staffing Decisions

13.

Sta

ffin

g D

ecis

ion

s

1. TA as the basis for costing value of employees lost

2. Adding Staff is OE, they don’t become productive immediately

3. Outsource resources?1. Costs, Resource Constraint

4. Ensure that a non-constraint is not elevated5. Ensure that there is balanced maturity across

the flow before outsourcing

1. properly analyze the Throughput Accounting implications of a decision to outsource and to understand its true contribution to Net Profit and ROI before any decision is made

1. 1.

1. Outsourcing challenges1. Can org managing vendor

relationship? 2. How good at writing requirements? 3. What will be the lead time from the

vendor? 4. Agility of offshore dev vendor? 5. CR Process and costs of CR?

1. Bad management causes staff turnover. 2. tendency to take staff turnover as "industry

standard" or "normal." 3. Cognitive dissonance that turnover is

management induced and preventable. 4. Failure to understand the true costs of staff

turnover

Vishwanath Ramdas

This is the essence of Agile management: Create a culture of openness, trust, a common understanding of the issues and to

debate the opportunity for improvements

14.

Op

era

tion

s R

evie

w

1. Issues should be surfaced not concealed, disguised, or shrouded in a sea of meaningless data.

2. Should not intended as a control mechanism. 3. Daily feedback based on production metrics

should be used for control.

1. all business owners upstream and downstream in the same value chain should be invited

2. operations review should be held monthly—not quarterly!

3. visually present the information that the business needs to operate successfully

4. director of operations for the business unit should have recorded the minutes of the meeting

1. Learning opportunity, vital to the health of a learning organization

1. Lead with Financial Information 2. Driven Through visual control

Vishwanath Ramdas

An Agile IT department is one focused on high-quality business analysis, selecting only the most valuable feature requests for development whilst capping the total release size using strict

inventory control

15.

Ag

ile M

an

ag

em

en

t in

th

e I

T D

ep

art

men

t

1. Effectiveness of a corporate IT department, it is necessary to show that it can add value to the business

2. Budget basis, value of deploying systems in comparison with system budgets

3. True Basis for Financial metrics, value of operating & improving systems in comparison to incremental usage benefit

4. Calculating Value add is critical

1. The key metrics for a CIO are the level of inventory of ideas (V), total sum of money invested in IT (I), cycle time (LT).

2. Throughput = Budget Basis– DDC*3. True Basis == also adds the improvements

post deployment, lifecycle ongoing = Value Add – [DDC – Ops costs]

1. significantly reduce OE, 2. Net Profit increased and investment

decreased, 3. Significant improvement in ROI

1. ROI = [T – OE] / Investments+

1. Monitoring the flow of inventory is the most important action a CIO can take to improve the performance of the IT business unit.

2. Calculate both Budget and True Basis ROI 3. Focus on how to improve ROI through T,

Investment, Lead time & OE4. Manage by Objectives and outcome [OE]5. Monitoring the flow of inventory is the most

important action a CIO can take6. Key Metrics are: inventory of ideas (V), sum

invested in IT (I), and cycle time (LT) 1. Requirement Bulge = minimize audit, paper work, reduce travel and interaction costs, penny pinch

2. Bloated Lead time 3. Bloated OE = manage by objectives, smaller

releases [reduce WIP]

1. Budget Basis which is derived from Biz Case is not agile, estimate effort accurately, scope lock down,

2.

* DDC = Direct deployment costs which involves all input materials like licenses, hardware etc.. Not including people time

+ includes all investments in ideation, requirements, design, analysis,

Vishwanath Ramdas

Understand the unpredictable variable in the finance equations—Throughput & the Learning Is Not Restricted to Engineering

16.

Ag

ile P

rod

uct

Man

ag

em

en

t

1. Cross-functional team work is essential to success

2. Considering end of life in accounting during new releases provides clarity to accounting, reporting and decision making [controversial]

3. Holistic approach to feature config that attribute to sales, what’s sales worth? [Kano]

4. 3 levels of marketing goals: must have, Desired and optional

5. Product mix must be prioritized in order to protect the scope constraint in the system.

1. Net Profit = SalesForecast – OEEngg -OEdownstream 2. ROI = [T(t)Engg – OE(t-1)Engg] / I(t-1)Req

3. Do not assign cost and value to individual features!! [ messy, inaccurate, need effort]

4. Calculate the $$ / Hrs of time on the system CCR and ranking from highest to lowest to derive product mix priorities

1. TA helps provide End of life decisions for systems

1. Agile Best is to build only what the customer needs, wants, and values

1. not waste energy creating features customers ignore

2. Writing of the current product as it is replaced3. Cluster features into groups for release

management & product mix [DSM]

1. Marketing forecasts are as big a black art as typical software engineering level-of-effort estimates

2. Measuring the effectiveness of engineering depends on other areas of business being efficient

1. Cost Accounting depends on the burden of time-sheeting by developers

2. TA cannot provide strategy on when to stop new investments and stagnate the product into a cash cow

qqqq

qqqq

qqqq

Vishwanath Ramdas

Throughput Accounting approach to a service industry treats the whole service as a system.

• A service is something paid for on a renewing basis. User has no perpetual rights—there is an implied annuity e.g: Telephone

• Services need to consider the mix between Fixed and Variable costs [e.g. Pizza, Telephones]

• Derive Operational margin [NPBIDTA] and use the fixed costs as investments to derive ROI – Throughput = Sales.Release - Direct costs.Release . – NPIDTA = Throughput – OEBIDA– ROI = Throughput / Investments

• This model depends on market research to identify customers who would have switched if there were no new releases [controversial]

• Ensure the organization / business deals with uncertainty– it is better to have some numbers correctly aligned with a systems thinking

approach to the business than no numbers or numbers aligned with the wrong model.

17.

Fin

an

cia

l M

etr

ics f

or

Soft

ware

Serv

ices

qqqq

Vishwanath Ramdas

Revisit the 12 principles of Agile methods and examine what they really mean from a business perspective [1/2]

• Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

– Agile methods believe in Throughput dollars– Deliver client-valued functionality in a systematic,

process-oriented fashion of continuous production. – Delivered at a steady pace

• Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

– Accept that change is a fact of life. – Stale requirement is valueless, Throughput dollars are

0 for a useless, obviated req.– Cope with change, even late change. – Genetic fitness implies agility.

• Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

– Short lead times & low inventory levels. – Reduce Investment & OE in producing software. – Generate greater ROI through focus on

• Increased value added – More Net Profit through Throughput dollars

• Reduction of Operating Expenses. • Reduced Investment

• Business people and developers must work together daily throughout the project.

– Waste is extremely costly and rework is undesirable. – On-site client who can catch misunderstandings and

correct problems with analysis and design. • Build projects around motivated individuals. Give

them the environment and support they need, and trust them to get the job done.

– leadership and delegation. – TOC >> focus on identifying constraints and removing

them through exploitation and elevation. – Think Demings 14 principles .

• The most efficient and effective method of conveying information to & within a development team is face-to-face conversation.

– minimizes setup time and eliminates by-products such as documentation.

– It is not zero documentation, but on an optimal set of minimal documentation,

– Improving communication, trust and understanding– Shorten lead times, which reduce OE, reduce

Inventory and Investment, resulting in increased Throughput

18.

Th

e B

usin

ess B

en

efi

t of

Ag

ile M

eth

od

sqqqq

Vishwanath Ramdas

Revisit the 12 principles of Agile methods and examine what they really mean from a business perspective [2/2]

• Working software is the primary measure of progress.

– Main metric: production quantity (Q)- code that deliver client-valued function.

• Completed Inventory or Throughput dollars– Compatible with Throughput Accounting, they

measure delivered value.• Agile processes promote sustainable development.

The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

– Cash flow & lead time are important. – Sustainable systems of software development turn

Investment into Net Profit faster– Encourage flow and believe in slack (below maximum

efficiency). – Slack allows for regeneration of staff and training to

improve their skills• Continuous attention to technical excellence and

good design enhances agility.– Rework and waste are costly to production and

profitability. – Value high-quality craftsmanship. – Personal mastery discipline [Senge 1990] is a vital

element in maturing a learning organization.

• Simplicity - the art of maximizing the amount of work not done—is essential.

– focus on simplicity of design • Reduce lead times through faster coding, less

testing, less likelihood of bugs, and overall higher quality.

– Simpler designs that can be built faster potentially increase the overall production, leading to higher Throughput dollars.

• The best architectures, requirements, and designs emerge from self-organizing teams.

– This is perhaps the only principle of Agile methods that cannot be easily justified in business terms.

– The premise that self-organized teams, rather than teams commanded and controlled by a manager, produce better designs leading to shorter lead times could be tested using the metrics described in this book.

• At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

– Principle of a learning organization [Senge 1990]. – Culture where every member is encouraged to think

about how they work and devise mechanisms for improvement,

– Continuous learning: Most important business benefit is the tendency toward a culture of continuous improvement. 1

8.

Th

e B

usin

ess B

en

efi

t of

Ag

ile M

eth

od

sqqqq

Vishwanath Ramdas

More than Agility

• Coping with change ensures successful projects rather than failed projects. – By focusing on genetic fitness, agility delivers survivability.– Especially in a world in which up to 30% of projects become extinct before

they have ever delivered any business value for the client. • Agile is "Lean Development"

– a term being popularized by Mary and Tom Poppendieck and Bob Charette [Highsmith 2002; Poppendieck 2002].

– Is about just-in-time delivery with total quality.

18.

Th

e B

usin

ess B

en

efi

t of

Ag

ile M

eth

od

s

Vishwanath Ramdas

A Survey of Methods

Section II

Vishwanath Ramdas

A survey of various software development methodsBoth Traditional [2 methods] & Agile [3 Methods]

• 2 flavors of what Agile methodologists call "traditional" or "heavyweight" methods. – A general interpretation of the Software Development Lifecycle (SDLC),

• often referred to as the Waterfall method, incorporating structured analysis and design.

• method is used to represent a very traditional software development process. • Although such a process is seldom used today in the precise form described, it will

serve as an example of how traditional methods got into trouble and why they are no longer favored.

– A traditional object-oriented software development method will be considered.

• Initiated by Ivar Jacobson, it has been known by several names: – Object-Oriented Software Engineering (OOSE), Objectory, Rational Unified

Process (RUP), and Unified Development Process (UDP).– precise definition of RUP/UDP used is that defined in The Rational Unified

Process: An Introduction by Philippe Kruchten [2000]. And a thicker volume by Jacobson and colleagues [Jacobson 1998].

• Three of the most popular Agile methods will then be considered– Feature Driven Development (FDD),

• A slight bias of content towards FDD due to the 5 years of experience – Extreme Programming (XP), – Scrum.

• Generic Rapid Application Development (RAD) process.

Vishwanath Ramdas

SDLC, is based on the theory of structured methods - if everything was understood, the project would be of little value. Someone would have done it before. Software projects tend to have an

element of the unknown.

19.

Pro

du

cti

on

Metr

ics f

or

Trad

itio

nal M

eth

od

s

1. Waterfall method helps the cost accounting approach of tracking inventory, simplify and push through together

2. Specification is fixed >> Variance measure from initial requirements

1. Inventory in structured methods is measured using the Function Point (FP) metric

2. Wrong mental model >> specification-budget-schedule + cost accounting == mass production + needs for specialists + Phased lifecycle.

3. For efficiency, large batch sizes, denied uncertainty in scope [reduced variance ]

4. metrics based on energy expended rather than output.1. key advantage of FPs as a metric is their

repeatability, provides a benchmark1. FPs are standardized and controlled by

an international body

1. Unwind the systemic problem - measure delivered value;

1. Inventory is treated as an asset.1. As raw material is processed towards a

finished product, 2. Specification is the project element with the

most uncertainty3. Phase approach multiplies inventory and

complexity4. long wait time, large batch sizes mean high

inventory levels, Lack of flow tat creates long lead times and waste.

5. All estimation anlaysis methods, used to better understand the product are Waste

6. Lack of slack – re-work not accounted into resource time

1. Issue with structured methods is not structural decomposition, use of FP or software analysis and design techniques involved.

2. The real issue is high levels of inventory, and focus on documentation to ensure flow

Vishwanath Ramdas

UDP, which can be defined as rigorous dev method;

19.

Pro

du

cti

on

Metr

ics f

or

Trad

itio

nal M

eth

od

s

1. UDP has two granularities, iterations and phases.

2. iteration is a a batch of inventory in a phase.

1. UDP is an architecture-centric, Use Case driven method – Vision document called Marketing requirements doc

2. Use Cases can be used to describe the business activities

1. key advantage of FPs as a metric is their repeatability, provides a benchmark

1. FPs are standardized and controlled by an international body

1. Business Use Cases lead to several downstream tech use cases, which should not be counted as inventory [double counting!]

2. UDP adopts the PMI/ISO mental model for project management, scope-budget-schedule.

3. UDP does not recognize software development as an innately human activity. It does not recognize the engineer as a capacity constrained resource.

4. UDP has Use Case as unit of inventory; not very fine grained.

SDLC UDP

Raw Material

ideas delivered as a functional specification

UDP is an architecture-centric,

Inventory Function Point (FP) metric Business Use Case form inventory, though Use cases don’t have standards,

Investment cost of creating functional specification and costs in performing the FP analysis

Inception phase creating Vision Document and related material

Lead Time time to take a single Function Point through the lifecycle of analysis, design, coding and testing until delivery

Time for Use Case to pass through the Elaboration, Construction, and Transition phases

Throughput

dollar value added from the delivered Function Points

$$ value added of the software delivered into production at the end of the Transition phase

Production Rate

simply the number of Function Points in any given time period

number of Use Cases passing through any phase

Process Iterative incremental method, with iterations and phases

Inventory cap

Inventory Cap is reached, no more requirements would be gathered

No defined minimum

Documentation

Business Use Cases, a Vision Document, supplementary requirements, system Use Cases, phase plan, iteration plans etc..

Structure Waterfall, phased linear batch approach

Release, Phase, Iteration

Vishwanath Ramdas

19,2

1,2

6,2

9,

33 P

rocess E

lem

en

ts &

Metr

ics

Production Definitions in various Software Models SDLC UDP FDD XP SCRUM

Raw Material ideas delivered as a functional specification

UDP is an architecture-centric, Feature List I raw material of XP, taken to extreme, is the knowledge of the customers

requirements statements defined in product backlog

Inventory Function Point (FP) metric Business Use Case form inventory, though Use cases don’t have standards,

Stories are recognized as the correct basis for Inventory—they are units of client-valued functionality

does not track Inventory (client-valued func.), but instead a series of tasks

Investment cost of creating functional specification and costs in performing the FP analysis

Inception phase creating Vision Document and related material

cost of acquiring the Feature List

cost of acquiring inventory is very low in XP, usually 1 day. Investment by results

Out of scope but for metrics: cost of acquiring requirements + analysis to maintain Product Backlog

Lead Time time to take a single Function Point through the lifecycle of analysis, design, coding and testing until delivery

Time for Use Case to pass through the Elaboration, Construction, and Transition phases

Each iteration is fixed to 2 weeks; total lead time is a multiple of # of iterations

Throughput dollar value added from the delivered Function Points

$$ value added of the software delivered into production at the end of the Transition phase

dollar value of a User Story value of a delivered Release or a delivered Sprint

Production Rate

simply the number of Function Points in any given time period

number of Use Cases passing through any phase

number of Features delivered in a given time period

"velocity" of the team; rate of completion of Story Points per 2-week dev iteration

burn-down rate: rate of tasks completed in Sprint Backlog

Process Iterative incremental method, with iterations and phases

RAD approach to Lead Time: delivery date fixed, scope, budget moderated

Inventory cap Inventory Cap is reached, no more requirements would be gathered

No defined minimum success of XP is the fact it caps inventory levels by strict 2-week iterations and 3 mo Release

number of tasks that can be undertaken in a Release or Sprint

Documentation

Business Use Cases, Vision Doc, supplementary reqs, system Use Cases, phase plan, iteration plans etc..

No Requirements in document form

Structure Waterfall, phased linear batch approach

Release, Phase, Iteration Products, Release, Sprint, Tasks

Production Metrics

FP Metrics Use Cases based metrics, with higher uncertainty

Features completed by time across 6 stages of transform

Time volumetrics on story points |

Sprint review outcomes | Feature volumetrics

qqqq

Vishwanath Ramdas

Financial Metrics in various Software Models

Traditional [SDLC/UDP] FDD XP

Inventory V Function points or Use Cases Total Features in the List including Not started, WIP, Not deployed

Story points held in all story cards

Investment I Capital in Inventory of raw material plus in system [ PCs, servers, and software tools]

Capital in raw material, process across lifecycle

Capital in raw material, process across iterations

Operating Expense OE

including direct labor, for the design, coding, and various testing stages

All costs, including direct labor OE Iteration * # of Iterations

Throughput T value of the delivered Function Points less the direct costs involved in deploying

value of the delivered Features using Throughput accounting

value of the delivered Stories

Value Added T – OE calculating the Net Profit figure [T-OE]

calculating the Net Profit figure [T-OE]

ROI [T-OE] / I [T-OE] / I [T-OE] / I

Accounting for Change

Change could increase or decrease scope and this should reflect in I

Change could increase or decrease scope and this should reflect in I

Change could increase or decrease scope and this should reflect in I

Accounting for rework

Rework must be ignored in accounting; Rework should not be shown as new Features; Mark features as unfinished

How is re-factoring handled? Continuous or as whole iterations?

Double counting

Differentiate between I & OE

Structure Release, Phase, Iteration

20,

24,

27:

Fin

an

cia

l M

etr

ics f

or

Meth

od

sqqqq

Vishwanath Ramdas

FDD is essentially a software management method, rather than a software engineering lifecycle development method

21.

Pro

du

cti

on

Metr

ics in

FD

D 1. FDD genesis -- 1997 -1999 at United Overseas Bank SNG by Jeff De Luca based on earlier material by Peter Coad

2. Feature is a small piece of client-valued functionality: a tangible result

1. Step 1—Shape Modeling: UML Class Diagram, non-functional requirements & architectural model

2. Step 2—Feature List, Understand scope, outline for a Functional Specification, prioritize

3. Step 3—Plan by Subject Area: Group Feature Sets (FS) & Subject Areas (SA), schedule of delivery

4. Step 4—Design by Feature Set: in-depth UML modeling, Class Diagram, Sequence Diagram

5. Step 5—Build by Chief Programmer Work Package: CUT, work window of < 2 weeks

1. Level of effort is based on 5 point weghted scale

2. FDD claims that estimation is repeatable, unique claim as agile says this is unobtainable

1. FDD defines four layers of architecture: UI—User Interface, PD—Problem Domain (business logic), DM—Data Management, and SI—Systems Interfaces

2. FDD works best when modeling is jointly done by business owners and developers

1. During the planning, the team is only guessing at the complexity of the sequence diagramming, but a good guess is good enough. Normally, there are enough Features that errors in the guessing will average out over the whole project

Vishwanath Ramdas

Self-organizing construction within planned assembly, aggregate design control along with individual feature left for development

by teams

22.

Pro

ject

Man

ag

em

en

t w

ith

FD

D

1. it is important to deliver on schedule, it is difficult to scale resources or budgets, so features must be traded out of the scope

2. Critical Chain shows it is necessary to add a project buffer based on uncertainties involved.

1. Features are grouped into Feature Sets 2. Features sets group to form Solution areas 3. Features build happens in batches known as

Chief Programmer Work Packages (CPWP), resulting in 4-5 iterations per feature set

4. Each chief programmer is given a buffer of waiting Features known as a "virtual inbox“

5. Performance Metrics 1. The project status as RYG 2. The cumulative flow diagram3. The total number of Features completed4. The current percentage of client-valued functionality

completed5. The number of issues open6. The trend in the number of open issues as a graph7. The number of Features blocked8. The trend in Features blocked as a graph

1. Feature set based on use case 2. Feature Set based on UI Containers3. Feature lifecycle used to derive throughput 4. Derive Feature relations through PERT5. Apply KM & Visual Control for monitoring

Vishwanath Ramdas

FDD is a 3-D software development and management method that uses process experience, analysis and modeling techniques, and,

psychology of computer programming

• Exploit Engineers [most Prized] without distractions & interruptions

• Maintain a virtual inbox of work at each station• Development manager should motivate team • FDD Team Psychology: teamwork, ownership,

peer pressure, peer recognition, shared learning experience, safety in numbers, group confessional opportunity, carrot & stick on Feature schedule

• Visualize progress – Feature metrics through time

• Just Enough Design Initially [JEDI] – ensure flow to the next stage,

– Keep modeling wide not deep– Keep design lean not big

• All features blocked should have a issue logged – action priority based on when it would hit Critical

Path• Address local safety problem through focus on

package level completeness metric and regular Production rate reports

• Avoid Heroic Effort that emerge from Scope Creep, J-Curve Effects

• Constraints removal strategies in FDD• Class/file ownership is critical & version control is a process

constraint.– Availability of a file for editing is a CCR and is exploited & all

other process subordinated• Virtual surgical teams to eliminate size – communication non-

linearity constraint– Developers can be part of multiple teams and balancing work is

their accountability• Eliminate waste of waiting

– Through batching feature sets, limited to a size completed within 2 Weeks

• Scope constraint eliminated through buffers – Features that customer would forego [nice to have]; Kano model

based scoring schema, tiered by time multiple surveys with different timelines

• Time constraint is handled through project buffer – An accurate estimate should be 50% of the time late! [TOC 97] ;

Create aggregate Buffers for each feed chain • Budget Constraint – through inventory cap

– Calculate the theoretical inventory [V = R * LT], and maintain below this limit

• Test Constraints - focusing on improved quality in front of test– Get right the first time, Unit Testing [35% improvement], Peer

reviews• Embracing change through – Advanced modeling

– Domain neutral component development through experience & expertise

– Higher quality, usage feedback, demand reduction • Communication – Teaming constraint >> Morning roll call

– < 30 min <20 people daily standup on progress, ideas, issues, challenges etc..

• Student Syndrome – Start tasks as late as possible – Don’t estimate individual features and focus on Production rate

& lead time metrics within team• Multitasking should be eliminated to avoid setup and re-immersion

wastes • Early finish wastes to be eliminated through regular reviews

23.

FD

D P

rocess E

lem

en

ts E

xp

lain

ed

qqqq

Vishwanath Ramdas

Development is hard! XP handles risk through small batches, Loss is limited to the small batch & therefore cost of change or

abandonment is also low.

25.

Pro

du

cti

on

Metr

ics in

Extr

em

e P

rog

ram

min

g

1. Inventory & Process is structured by release and iteration, these result in reports

2. Enterprise XP projects must run with measurement collection as a fundamental part of the process [not – proof of the pudding is in eating]

1. Requirements written as small chunks of stories on index cards, ideally by customers,

1. Larger Stories are known as Epics.2. In planning cycle [aka Planning Game]

1. Stories are assessed for size and risk [Mayford 2002]

2. Stories are analyzed and broken into Tasks

1. Visible metrics are called smells in XP 2. Every iteration based on 2-week budget,

stories and re-factoring are included

1. Fail early fail often – attempt the riskiest elements

2. There is no separate testing which is integrated; only CAT

3. Pipelining – Use CAT to start next iteration

1. Conservative businesses tend to be afraid of XP because of the lack of visibility into the development process

Vishwanath Ramdas

XP captures requirements through Stories written on index cards and delivers stories based on their risk and complexity [3-point

scale] using fixed schedule iterations of 2 weeks and 3 month release cycles

26.

XP

Pro

cess E

lem

en

ts E

xp

lain

ed

1. Assessing User Stories1. Risk & complexity measurement, anticipatory estimation & reactive feedback controllers | Lack of standard in Story types with

organization is handled through strong feedback

2. Prioritizing story through Business Value, Risk and Complexity1. Do the risky ones first [Will DSM Help?]

3. Option theory – Disruptions should be held off until as late as possible1. High change stories to be developed late; Helps reduce rework & waste | Fail early fail fast >> encourage build of high risk items

within an iteration

4. Planning Game – protects the scope constraint1. Customer priority based on value | Developer counter balance based on risk and complexity

5. Continuous Integration [ nightly builds] 1. Encourage failure to highlight issues [ Lean Principle stop of Quality failure] 2. Keep the team to 12 members or change config management tools

6. Integration testing – Automated 1. Testers do scripts for automation | Black box testing [ regression, performance, CAT] is acceptance testing

7. Pair programming – Quality gains over Quantity1. Coder + Reviewer teams | Substitution leads to more energy | Positive peer review | Skills Transfer & Discussions | how to form

pairs?

8. Stand-Up Meeting 1. Highlight issues | Request more Work | Share ideas | Recognition & Re-use

9. Unit Testing – TDD [Write tests before code | Automate e,g, JUnit]

10. Collective Ownership [ Queue time is greater than merge edit time]

11. Re-factoring is to be done continuously1. Boot-camps | No time pressure | No micro management

12. Maintain 40 hour reasonable work week

13. On-Site Customer [ empowered & have domain knowledge]

14. Generalist focus [ High talent, skilled resources]

15. XP is a paradigm shift in software development thinking

Vishwanath Ramdas

A management wrapper for other SDLC methods, defines software project control & not how software is written. An empirical process control,

foundations in Japanese manufacturing, lends itself to acquisition and processing of metrics

28.

Pro

du

cti

on

Metr

ics in

Scru

m 1. No explicit description analysis phase2. Single Product Backlog Requirements

defects, and other tasks [Schwaber 2003]. 3. No Sprint plan: tasks called off by developers

daily in a self-organizing, volunteer fashion4. Recognize that expediting increases Lead

Time, as other tasks are slowed to make way5. Steady 30-day heartbeat to control LT

1. incorporates a daily stand-up meeting to discuss issues interfering with productivity

2. organizes development work into three levels: Sprints [<4 weeks], Releases [6-9 sprints], and Products

3. Requirements as a list of client-valued functionality known as the Product Backlog

4. 3 inventory sources: Sprint Backlog, Release Backlog, and Product Backlog

5. overestimated, unfinished scope is added back to the Release or Product Backlog

1. Metrics include: anticipated LOE remaining for Release at the start of each Sprint; daily burn rate & daily state of Issue Log

1. Tracking issues ensures that Critical Path remains unaffected.

2. Sprint measures: size of Issue Log, and trend of issues, issue Lead Time.

3. integrated testing within sprint

1. Scrum has a single list, therefore inventory could be misleading and only a subset needs to be considered for throughput

2. There is uncertainty about cap accuracy1. Difficult to know LOE & tasks in

advance before analysis 3. Burn-down rate I not Production Rate (R),

limit to client-valued func. > Stories, Use Cases.

Vishwanath Ramdas

Scrum does not define any engineering practices, significant improvement in productivity can occur simply by reorganizing the people doing the work—without

interfering with the techniques used for working

29.

Scru

m P

rocess E

lem

en

ts E

xp

lain

ed

1. Scrum Master: compared to a sports coach1. Implement Scrum method and insure effective introduction and it continues properly. [a coach and a coordinator]

2. Product Backlog [the inventory stockpile waiting to be fed into the system of software production]1. includes tasks and activities, not just deliverables. Hence, is not such a clean indication of inventory

3. The 30-Day Sprint1. limits raw material in development and test, introduces certainty on requirements, eliminates expediting2. 1-2 days of backlog planning, feedback based on reports defines the amount of planning required in the context

4. Release [agreed set of Sprints, in 1-Mo multiples; Ideally, 3 months though longer periods are possible]1. Through the use of use of Sprints and Releases, SCRUM reflects basic RAD principles

5. Sprint Goal Commitment is to jointly as a team agree on backlog [self-organization]1. As the periods are 30 day cycles, commitments are maintained or highlighted and tail-ending is avoided

6. Scrum Daily Stand-Up Meeting [the first documented Agile method to use a daily meeting]1. Encourages support, recognition, quick reporting, sharing

7. Team size of 7 is recommended1. optimal because it maximizes the momentum that can be achieved whilst minimizing the communication overhead

8. Team Composition [each Sprint team have at least one highly experienced engineer] 1. Mentor the rest of the team; volunteer to assist on issues; avoiding downtime by solving problems quickly.

9. Work Environment [provide working space and tools needed to get the job done] 1. Salaries is largest component of OE; provide room space [100SFT / dev] , meeting room, or quiet reading room;

Self organizing teams [freedom to arrange their cubicles or desks to their need] 2. Provision of good tools leads to exploitation of the developer as a CCR | Risk is this may result in deviant behavior

>> defense is to have open operations review.

10. The Sprint Review [takes place at the end of each 30-day Sprint]1. Demonstrate functionality to customer | Release & Deployment > generates system Throughput | lessons learnt |

constraints solving

Vishwanath Ramdas

Agile project will have a lower sum sunk as Investment, and hence the effect of losing that Investment is lower than in a heavyweight,

high-inventory traditional Waterfall project.

• XP myth is its claimed cost of change. – Beck has suggested that the cost of

change performs more like an 1-log(n) type curve against experience that change cost is exponential

– Beck’s understates change cost ignoring regression effects, keeping modules isolated & using Overtime

• Shortly after publication of Beck's Extreme Programming Explained,– Alistair Cockburn pointed out that Beck's

change curve was probably incorrect [Cockburn 2000].

• Boehm curve over estimates change stating that cost could run to infinity

• Is cost of change an S-Curve?– Agile methods generally reduce the

exposure and risk involved in change.

Cost

Of

Ch

an

ge C

urv

eqqqq

Vishwanath Ramdas

principle that a date is set in the calendar and will not move, so with delivery date as the constraint, everything else is then

subordinated to it

30.

RA

D P

rocess E

lem

en

ts E

xp

lain

ed

1. RAD methods correctly identify the scope as the constraint with the greatest uncertainty and unpredictability

2. A wise RAD project manager will buffer the scope and leave some slack to absorb any uncertainty that might jeopardize the delivery date1. Date > Scope > Resources OR 2. Date > Resources > Scope

3. A steady heartbeat for development cycles1. effectively cap inventory | | costs to be carefully controlled | manpower level to be fixed 2. Defined lead time for development >> Honor promises, reduce waste, improve feedback

4. Operating Expense is at risk from uncertainty 1. In estimating process | failure to correctly analyze the complexity | risk in the proposed

functionality.

5. Limitations of RAD Methodology1. RAD does not recognize the psychological problem in software development, which is 80%

human activity. 2. RAD focus is speed and is a forerunner to agile not truly agile

Vishwanath Ramdas

Comparison of Methods

Measure the smallest thing you can measure. . . Because it gives you fast feedback."—Seth Godin

Vishwanath Ramdas

No one approach to management can be a panacea. It is unlikely that a single method will be acceptable for all situations. It is,

therefore, necessary to question the application of Agile methods

• It is always attractive to polarize a debate – DO NOT – E,g, In US politics ouy are either a donkey

or an elephant, or you opt out of politics.• Each methods has its own scope & scale,

with the best context to apply for • Capers Jones analysis on production rate

improvement – Data from 7,000 + IT projects over more

than 15 years [Constantine 2001]– Code reuse >> best way to improve the

rate of Function Points delivered– Teams with peer reviews by far

outperform those that don't– Teams with specialists outperform those

with generalists• This is against Agile Foundation principles• Scott Ambler has found ultimate solution

[2003]. He calls them generalist specialists

– Teams with a specialist maintenance and performance tuning function outperform teams that use mainline developers for this task.

• Fred Brooks argued that adding more people makes a late project later [Brooks 1995]. - J-Curve– How do we make a change?– Eli Goldratt's observation that all

improvements are changes, • but not all changes are improvements

•

31.

Devil's

Ad

vocacy

qqqq

Vishwanath Ramdas

For Scrum, Beedle and Schwaber argued that all software development is empirical and, therefore, cannot be planned [1/2]

• processes that can only be observed empirically aren’t necessarily chaotic [Cynefin]

• Shewhart states that a process is "in control" if it can be regularly measured within some bounds

• Don Wheeler later classified four states of control based on Shewhart's work, similar to cynefin

– Ideal: Stable over time | Traditional SDLC | SDLC Rare, bugs, changes, uncertainty

– Threshold: Variance outside control are rare | FDD, Six sigma | Due to Requirement language & DNC

– Edge of Chaos | Process out of control with conforming outcomes | suffers random, unpredictable, severe noise, which will force it out of the acceptable tolerances | XP, Scrum | fast feedback [Short LT], empirical knowledge, experience, self-organize

– Chaos | • 2 – Dimensional model on process & Analysis

– For e.g. physics and chemistry, analysis model is highly developed. Considered effect-cause-effect sciences.

– Improving Analysis Maturity in SDLC • Coad [1999] (Features, Archetypes, Domain Neutral Component),

Palmer [2000] (extending Archetypes and Domain Neutral Component), Mayfield and Nicola [2001] (Pattern Players and Collaboration Patterns), Fowler [1996] (Analysis Patterns), Hays [1996] (Data model patterns and the Universal Data model), Horrocks [1999] (Statecharts applied to user interface), and Constantine [1999] (Task Cases for user interface).

– Improving Process Maturity in SDLC • Agile model restricts itself to this Axis and ends up in Edge of Chaos • FDD Tries to improve analysis and modeling through “Right First

Time”32.

Sta

tes o

f C

on

trol an

d R

ed

ucin

g V

ari

ati

on

qqqq

Vishwanath Ramdas

Agile methods help organization potentially mature overtime, when maturity is high, use traditional methods that provide high

standards

34.

Ap

plicab

ilit

y o

f A

gile M

eth

od

s

• Lapre and Van Wassenhove diagram of conceptual and operational learning

• How to transfer learning?

• By dividing the domain based on eco-system & Maturity

• Large holistic projects are best suited for Rigorous software mgmt

• Most other areas Agile models are preferred

• AS business and technology space gets more complex and likely change, Agile is preferred

• Scrum is positioned lower as it shuns modeling

• Map on scale vs ability to expedite

• Uncertainty >> Low scale & Shorter Lead times >> Agile Methods

• How to reduce costs and deliver faster?

qqqq

Vishwanath Ramdas

Tools Summary

• relationship between the Theory of Constraints and Agile software development methods. • Feature Driven Development—especially, Jeff De Luca, Peter Coad, Stephen Palmer, Philip

Bradley and Paul Szego. • S-Curve Mac Felsing and how it could be anticipated by the development manager. • Mike Watson provided much of the insight that led to a formal explanation of the S-curve

effect. • Jason Marshall helped me to "discover" that Cumulative Flow Diagrams were the ideal

method to visually report the flow of value. • Ken Ritchie was a continual inspiration and provided many early review comments. His

knowledge of both FDD and TOC • Daniel Vacanti helped me understand daily stand-up meetings by running them with my team

every morning. • "generalist versus specialist" Vanishing Cloud diagram• Vahid Nabavizadeh and Chris Bock provided the project tracking evidence to show that FDD

Features converge on a mean with a low standard deviation. • Martin Geddes contributed much of the thinking behind the notion of "perishable

requirements" • Lean Programming – Mary Poppendieck• Lepore & Cohen merged the Theory of Constraints with Edwards Deming's Theory of

Profound Knowledge and devised a 10-point scheme they call "The Decalogue" [Lepore, 1999]. Stage 9 involves "bringing the constraint inside."

REFER

EN

CES

Vishwanath Ramdas

Tools Summary

• Jeff De Luca explains FDD in Getting Flexible with Planning, Feature Driven Development Newsletter, Jan 2003, [http://www.featuredrivendevelopment.com/node.php?id=508]

• Palmer and Felsing have a good example of expedition and its effects in A Practical Guide to Feature Driven Development [Palmer 2000].

• New definition of agile principle 1 : Philip Bradley on the FDD community website, http://www.featuredrivendevelopment.com/node.php?id=531

• Manual published by the International Function Point Users Group (IFPUG), which has around 100 pages of theory. Hence, Function Point analysis has a high barrier to entry and tends not to be widely used. The IFPUG reports that there are around 2,000 trained FP analysts in the world [Yourdon 2002].

• The Waterfall Method is attributed to Royce[2] in the late 1960s. Perhaps it seemed like the intuitive thing to do.

– Dr. Winston Royce is credited with publishing the first paper on the Waterfall model [Royce 1970]. However, several others enhanced the work throughout the 1970s. Brooks is often credited with popularizing the model through his essays later published as a chapter in The Mythical Man Month [Brooks 1995]

• most recent book on the topic, A Practical Guide to Feature Driven Development [Palmer 2002]. • FDD Dashboard courtesy of Stephen Palmer, Copyright 2002 Step-10 Limited, all rights reserved,

http://www.step-10.com/• The range of 1 through 5 was carefully chosen based on cognitive research on set sorting theory, which

suggests that humans are challenged to sort random elements into more than 6 categories [Bousfield 1955 & 1966].

• In XP Kent Beck is introducing the notion of 1 week as the canonical iteration in XP and 1-day iterations during an initial 2-week period.

• Reinertsen's "leading" versus "lagging" metrics. Processes controlled entirely by feedback do not react fast enough to be competitive against process control that is anticipatory.

REFER

EN

CES

Vishwanath Ramdas

References:

• Joan Magretta | book | "What Management Is" [2002, p.2]. • Tom DeMarco |book | "Slack,"[vi] • O'Connor, Joseph & McDermott, lan | book | The Art of Systems Thinking:

Essential Skills for Creativity and Problem Solving Thorsons, San Francisco, California 1997

REFER

EN

CES