Precis Book Agile mgmt software engineering david j andreson summary viramdas 200911 plain

Agile Management for Software Engineering

Applying theory of constraints for business results
David J Anderson

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

Vishwanath Ramdas

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

THERE IS NOTHING LIKE
READING THE BOOK..
READ IT..
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.
qqqq
• 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
FOREWORD

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

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.’
INTRODUCTION

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

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

• 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
qqqq
– The Cause
– The Technology Challenge
– The Money
– The Boss [ this is the focus of the book]

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
qqqq
INTRODUCTION

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

Vishwanath Ramdas

qqqq

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

12 Principles of Agile:

• Our highest priority is to satisfy the • Working software is the primary
customer through early and continuous measure of progress.
delivery of valuable software. • Agile processes promote sustainable
• Welcome changing requirements, even development. The sponsors,
late in development. Agile processes developers, and users should be able to
harness change for the customer's maintain a constant pace indefinitely.
INTRODUCTION

competitive advantage. • Continuous attention to technical
• Deliver working software frequently, excellence and good design enhances
from a couple of weeks to a couple of agility.
months, with a preference to the • Simplicity—the art of maximizing the
shorter timescale. amount of work not done—is essential.
• Business people and developers must • The best architectures, requirements,
work together daily throughout the and designs emerge from self-
project. organizing teams.
• Build projects around motivated • At regular intervals, the team reflects
individuals. Give them the environment on how to become more effective, then
and support they need, and trust them tunes and adjusts its behavior
to get the job done. accordingly.
• The most efficient and effective method
of conveying information to and within
a development team is face-to-face
conversation.
Vishwanath Ramdas

Chapter Summary

1. Objectives 1. Facts
2. Guidelines 2. Execution Apporaches
3. Principles
Chapter Name

1. Benefits, Outcomes 1. Best Practices
2. Value 2. Innovations

1. Risks, Danger, Fear Perceptions 1. Downside, Problems
2. Issues

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 1. Defines 4 basic roles that form a 2-tiered
improvement over its American mass management model along with set of
production competitor practices for each role.
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.
INTRODUCTION

1. Methods to report believable, familiar 1. Framework to scientifically measure and
statistics and have meaning to the business. assess Agile methods based on - Throughput
2. Demonstrate the economic advantages and Accounting from TOC
focus on real business benefits. 2. Agile Maturity Model: inside-out approach to
3. Argue a business case based on hard phase out capability as working practices ,
numbers indicating better profitability and traceability, metrics, learning, and eventually
higher return on investment. financial metrics and results.

1. Agile methods propose some unusual working 1. Agile brings its own jargon and vocabulary not
practices. E.g. Extreme Programming understood by management
2. The strange language and the strange 2. Agile is adopted not based on hard facts and
practices scare management benefits but more as a FAD
3. Agile methods introduce scary counter
intuitive working practices.

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
1. Theories for Agile Management

– 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].

Vishwanath Ramdas

Theories that support and enable agile software development

• The Theory of Constraints • Total Quality Management
– Underlying assumption: Production is as fast – Japanese realized that better quality was

as the slowest process in the chain. important
– Value chain is only as strong as the weakest – Quality Assurance - Edwards Deming through
link in the chain. Statistical Process Control (SPC) theory,
– Identify bottlenecks [capacity of the weakest – Interpret the control charts of Walter
link] = current system constraint. Shewhart [Wheeler 1992].
– Exploit constraint - rate of throughput in – Improved quality improves the throughput of
constraint is system throughput a system.
– Technique is known as Drum-Buffer-Rope. – TQM espoused the notion that manufacturing
– Thereby Reduce inventory of material could be more efficient (read "profitable") if
throughout the system. quality were improved.
• Just-in-Time Inventory – Quality could be improved through improved
traceability, which would provide audit trail
– Toyota Production System [Kanban Approach] information for verification and validation of
- Taiichi Ohno [Ohno 1988]. quality.
– Minimize inventory in the factory – TQM gave rise to ISO-9000, Tick-IT, and other
– Ohno had based the technique on methods quality-related initiatives.
used by American grocery store chains, ROI = – Upstream process was the "supplier" and the
{Throughput – Ops Expense}/ Value of System downstream process the "customer."
Inventory
– Everyone had an "internal customer" for their
– Throughput Accounting, reducing inventory work.
reduces the level of investment. Competitive
advantage of lower inventory levels is – Quality improves production because it
reduced the financing charges cost of storage qqqq reduces rework. = less waste, less OE, and a
space, thereby reduced Operating Expense higher Production Rate (R).
(OE) and increased profitability.

Vishwanath Ramdas

Theories that support and enable agile software development

• Lean Production • Comparison & Evaluation of the
Theories

– "Lean" was first coined by Womack and
colleagues in their book, The Machine – TOC originally focused on bottlenecks.
That Changed the World, – JIT originally focused on reduction of
– The Toyota Way," – The management inventory.
method can be used beyond just – TQM and SPC were focused on quality
production. and conformance to specification.
• Six Sigma – Lean is the effective combination of all
– Refers to a defect level of less than four of them.
per million [~represent perfection] – Six Sigma also focuses on quality and is
– Improved quality and focused complementary to Lean
investment to eliminate errors. – Theories produced an immense
– Associated with General Electric and economic improvement for society
Motorola. – e.g amazingly complex technical
– Two focus areas: quality assurance and products like DVD players < $20.
reduction of variance. • Has Improved Profitability Been the
– Better to have defects with a repeatable Only Benefit?
pattern - common cause can be found – 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].
Vishwanath Ramdas

qqqq

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.

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 • Emergence
– qqqq
Schwaber and Beedle published their book describing – Phenomena described as "emergent." -- Complex

the Scrum method. qqqq Adaptive Systems.
– Webster's dictionary defines empirical as "Depending – Simple rules govern the internal behavior of the
upon experience or observation alone, without due system, which results in the externally observed
regard to science and theory." adaptive behavior.
– Impacts how we measure measurements around – Understand what the simple rules are that produce
observation repetition often amazing results.
– Schwaber defined that empirical processes are – Simple rules are what inspire ants to build great
"chaordic," [lives on the edge of chaos] anthills and to work as a team to perform tasks that
– Used this to argue - that there is no point in planning ought not to be possible for such basic creatures.
• Convergent Versus Divergent Processes – software development is a complex adaptive system,
– This may be more critical to how we control and – Agile Manifesto principle, "The best architectures,
manage processes requirements, and designs emerge from self-
organizing teams."
– Convergent = under control process will converge
over time on a predictable solution. – The proper jobs of executives are to set the goal for
the adaptive behavior of the system and to select the
– Divergent = under control produce inconsistent method with which the goal is measured and the
results system feedback delivered.
• Chaos Theory and Uncertainty – In addition, they may need to create an environment
– Renee Descartes [1625] - suggested that everything within which the complex adaptive system of
could be gradually decomposed to scientifically software development can exist freely to self-
explain behavior and composition. organize at the appropriate level.
– Its corollary held that something that was not – What is important is that those setting the rules set
understood simply had not been sufficiently rules that reflect the nature of the system holistically,
decomposed. which leads to delivery of global optima rather than
– In contrast The principle of uncertainty [Hiesenberg] local efficiencies
is closer modeling of reality
– TOC helps manage the business systems to cope with
uncertainty
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.
Vishwanath Ramdas

Agile Management

Section I

Vishwanath Ramdas

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

Consider the stages of the transformation of an idea into tangible
working code.
2. Management Accounting for Systems

• 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 qqqq
– Investment = KnowledgeInput =
ValueInput
– Value Added = ValueOutput - ValueInput
– Throughput = KnowledgeOutput-
KnowledgeInput
• To Summarize [in order]
– Increase Throughput (T)
– Decrease Investment (I)
– Decrease Operating Expense (OE)

Vishwanath Ramdas

TOC is a method that helps Focus on the right problem within the value chain
qqqq
1. The Value chain is only as strong as the 1. Identify the System Constraint.
weakest link 2. Decide how best to exploit the System
2. The system is subordinate to the capacity Constraint.
constrained resource [CCR] – where inventory 3. Subordinate everything else to the decision in
pileup happens step 2.
3. TOC in software production

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 1. Exploiting the CCR is an area for innovative
system is eliminated, especially critical for problem solving, waste elimination [Lean]
perishable inventory 2. Subordination is driven through Drum-Buffer-
2. Assessment of incremental investment is Rope [Takt Time + Kanban]
done through throughput accounting 3. Balance the flow of product through the
system
4. Hire and develop Good people

1. Subordination to the CCR could / may result in 1. Systems can have multiple constraints that
stress elsewhere [ Road Runner behavior] impede the flow
2. Choosing and recognizing constraints
correctly is critical to successful TOC

Vishwanath Ramdas

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

1. There are 5 types of general constraints 1. People constraints are most critical
1. People, Resources, Budgets, 2. Time constraints could be externally driven as
qqqq
Functionality, Time in compliance and regulatory requirements
2. There are 4 types of Uncertainty 3. Manage Scope constraint through tier-ing by
1. Variability Foreseen, Unforeseen, need e.g. ―good to have‖ and by time
Chaos 4. Variation & foreseen uncertainties are
3. Uncertainty is handled through provision of a endemic and are called ―common cause‖
4. Dealing with uncertainty

buffer 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 1. Broken promises on scope and time are bad
that buffer for people are needed as people for business
are the most critical constraint 2. Revealing ―dark matter‖ is critical in the early
2. Good relationship /trust with users / business stages of software design and architecture
is critical to scoping
3. Creating too much local safety results in over
buffering

Vishwanath Ramdas

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

1. focus on simplicity and relevance to the 1. Throughput is the most important metric, shift
system goal. from effort driven metrics
2. Metrics should be self-generating 2. Non-functional requirement lead to measuring
3. Metrics should provide leading or predictive throughput, but one should follow minimalism
5. Software production Metrics

indication of the system performance rather 3. Tasks are not inventory – don’t represent
than lagging or reactive performance customer interest
4. Should relate to financial or economic goals

qqqq
1. Operational Expense [OE] 1. Littles Law >> inventory in the system is
1. Average Cost per Function[ACPF] directly proportional to the lead time given
2. Investment in the flow [I] throughput as a constant
1. Inventory levels in the flow [V] 2. Reinersteins advice – Metrics should be
3. Throughput of the flow [T] simple, relevant, self generating and lead
1. Production Quantity [Q] indicators
4. Finance >> T I OE
1. Production >> Q V ACPF

1. Clients don’t value tasks and other inputs 1. Measurements that are effort and input driven
2. What is inventory? In the flow? which don’t add much value to the customer
2. Measurements that are complex and manual
to maintain
3.

Vishwanath Ramdas

Manage Software based on the level of uncertainty. Time, Budget and Scope are
in increasing sequence of uncertainty.
1. Agile methods require a negotiable scope and 1. Feature driven delivery FDD extends the
an agreed scope buffer in order to be qqqq model to make both Scope and budget
successful flexible though tightly bound
2. This requires trust between customer & team 2. Effort / task based planning does not
represent systems thinking
3. PM needs to assist flow through maintaining
issues log that impede the flow
6. Agile Project Management

* Throughput Accounting

1. Koskela & Howell >> 3 dimensional Model of
Flow of Value through transformation
2. TA* depreciates incomplete code on time vs
1. Focus on better quality information for Cost accounting that appreciates code based
manage to enable decisions on effort
2. Focus on outcomes and throughput and how it 3. TA considers efforts as OE not value, no need
can be delivered on promised time to timesheet
3. Segregate costs from value that customer
perceives
4. Highlight issues and risks and deliver
throughput early

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]

Vishwanath Ramdas

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

1. Products are built from assembles that are 1. Develop CPM and PERT to plan
done in parallel [feed chains] 2. Non-Critical path items should be developed
2. Grouping is based on testing and release based on cost implications not AEAP
3. Move away from local safety to group safety, 3. Monitor the buffer usage of each feeding
reduces overall buffer in the system chain – constantly
7. Agile Project Planning

4. All inventory that are blocked should have
issues logged
5. Main constraint =Schedule/Time/Delivery date
6. PERT should factor in resource Constraint
1. Measure – Buffer Usage through progress

1. Goldratt asserted that everything eventually
hits the critical path qqqq
2. The resource constrained buffered plan is
called the Critical Chain

1. Hidden Assumption that all developer skills
are equal
1. How to buffer for parallel & serial tasks? 2.

Vishwanath Ramdas

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

• Development Manager • Product Manager
– Runs the system for software – Manages release or product mix,
production, maintain continuous flow defines what is the input to the flow
8. The agile Managers New Work

– Motivate the team and understand the – Manages the features to be released
development environment based on throughput and development
– De Lucas first law “Managing a team is capabilities
80% psychology & 20% technology” – Generates ideas and captures
– Increase productivity, remove requirements
constraints – Owns: NP, ROI, Investment [I], AIPF
– Owns:Production Rate[R], Lead time
[LT]
• Project Manager
• Program/ Release Manager – Manages a specific release through the
– Owns a Collection of project, what may code production flow
be called a platform, portfolio – Does project planning [Ch. 7]
• Mcgrath Defines this as product line
strategy – Issues, CCPM, PERT,CPM
– Manage release sequence, control the – Owns: Issues control, Buffer
Rope in DBR and feed the constraint
– Owns: Throughput[T], Inventory[V]

Vishwanath Ramdas

Smooth flow can be interrupted by three causes: a bottleneck, poor quality, and
an overly large batch size
1. Investigate reasons why stockpiling happens?
1. Inventory piles up at the point where 2. Use Visual control for awareness & decisions
9. Agile Development Management

production rate is minimal
2. Use the right batch size to optimize the flow
1. In Projects, inventory is a better lead indicator
1. Batch reduces setup but increases
than Lead time
Queue time, waiting, fatigue, LT..
2. Quality is more expensive, downstream in the
3. Intellectual efficiency is the avoidance of
flow as more areas would need rework,
waste in the flow
multiplying the impact
3. Capers Jones and Karl Wiegers [2002]
qqqq studies suggest 10% of effort in developer
peer review results in 45% defect reduction,
65% if unit tests are included and 80%if formal
1. Calculate true cost of bottleneck using TA, at inspections are done
bottlenecks, lost time cant be recovered 4. Small batches result in smooth flow
1. What is the loss of capacity in cost and 5. The less pronounced S the better the team
value terms
2. What is the true cost of Quality?
1. The capacity and prodctivity impact of
re-work

1. It is dangerous to assume that bugs stand in
isolation, when code fails regression testing,
there may be multiple units of production lost 1. In software development, bad management
through multiple stages of the system gets compensated by free overtime, abuse of
resulting in large loss of effort and outcomes engineers
2. Too small a batch size results in high setup 2. Large batches create execution fatigue
time [ context switching] resulting in defects

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.

1. Subordinate the MRP to the CCR [ TOC -3] 1. Use Drum-Buffer-Rope system for production
2. Do not swamp or starve the CCR subordination,
10. Software Resource Planning

3. Do not process the wrong or stale material 1. CCR is the drum | production rate the
4. Waste must be minimized. 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 1. Extreme Programming, is adept at coping with
delivery expediting. As it is "serial expediting."
2. Waste will increase if lead times are long. 1. As everything is an expedite request,
3. Reducing LT has a positive derivative affect 2. No additional cost for short order
on R and OE. requests
1. Increased LT >> More Waste >>
reduce R and increase OE.

1. Change requests can have an impact on the 1. Swamping could result in expedition of work
analysis, design, and coding of a software which has adverse effects.
project 2. Longer LT due to swamping results in time
risks
3. Too much defects results in analysis paralysis

Vishwanath Ramdas

qqqq

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

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

Tom DeMarco correctly observed, "You
11. An Agile Maturity Model

1. Implement system for capturing &
Stage 1 End-to-End Traceability cannot control, what you cannot measure"
monitoring measurements.
[Wiegers 1996]

1. Inventory; lead time; production rate;
Demonstrate that software development
2. Demonstrate basic statistical process
Stabilize System can be brought under control with
Stage 2 conformant quality. [ i.e. within some
control
Metrics 3. Show that system is stable against a
acceptable tolerance]
target and within a tolerance.

gradually tightening the screws on the 1. Focus on continuous improvement.
achieved metrics; look for the constraints, 2. New targets: lower inventory, shorter lead
System Thinking and a to determine how best to exploit them, to time, higher production rate.
Stage 3 subordinate the rest of the process to that 3. Identify constraints; exploit constraints;
Learning Organization
decision, and then to consider investment subordinate to decision; elevate
in order to elevate the constraint constraint.

Not afraid to push the boundaries or to
take on projects with high risk. 1. Encourage risk taking.
Anticipated ROI and the An environment in which line managers 2. Focus on Throughput ($), not production
Stage 4 Failure Tolerant are unafraid to take risks quantity.
Organization must be completely mature 3. Focus on market research/feedback (i.e.,
Organization along its entire value stream external constraints).
software system does not work in isolation

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.

1. Establish the simple rules governing the 1. process that allows tracking requirements
system of software production through the lifecycle must be introduced first
12. Setting the Governing Rules

2. Focus on behavior & adaption, and tweak 2. Introducing end-to-end traceability in the
when outcomes are not observed software development lifecycle is a nontrivial
3. Main goals for managers: first step. This first barrier to entry defeats
1. Skills Gap Education many organizations
2. End to End Traceability [V R LT] 3. Expected ROI metric, as the control of reward
3. Production Metrics 4. that team members understand what is being
4. Continuous Improvement measured and why
5. Fault tolerance Organization
4. Engineers must be encouraged to focus on 1. Reinertsen's Three Tiers of Control
exploiting themselves as a capacity 1. Executives : Select system & Define
constrained resource governing rules.
2. Managers: Set tolerances & rules for
variance
3. Staff: Adapt based on feedback from
1. Rules based on Maturity and ROI system metrics.
2. Incentive based on overall system, rather than 2.
local, production rate results in systems
thinking

1. [DeMarco and Lister] Process improvement is
primarily focused on quality, estimation scope
2. in CMMi, organization develop balanceing
1. Engineers can be afraid of measurement
loop at high maturity and stagnate [risk
schemes. They may rebel against them from
averse, not take up truly valuable projects]
fear of misuse
3. Production rate metrics fail to sustain
challenge over long term, through wrong
incentives
Vishwanath Ramdas

Taking Staffing Decisions

1. TA as the basis for costing value of employees 1. properly analyze the Throughput Accounting
lost implications of a decision to outsource and to
2. Adding Staff is OE, they don’t become understand its true contribution to Net Profit
productive immediately and ROI before any decision is made
13. Staffing Decisions

3. Outsource resources?
1. Costs, Resource Constraint
4. Ensure that a non-constraint is not elevated
5. Ensure that there is balanced maturity across
the flow before outsourcing

1. 1.

1. Outsourcing challenges 1. Bad management causes staff turnover.
1. Can org managing vendor relationship? 2. tendency to take staff turnover as "industry
2. How good at writing requirements? standard" or "normal."
3. What will be the lead time from the 3. Cognitive dissonance that turnover is
vendor? management induced and preventable.
4. Agility of offshore dev vendor? 4. Failure to understand the true costs of staff
5. CR Process and costs of CR? 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
1. Issues should be surfaced not concealed, 1. all business owners upstream and
disguised, or shrouded in a sea of downstream in the same value chain should
meaningless data. be invited
2. Should not intended as a control mechanism. 2. operations review should be held monthly—
14. Operations Review

3. Daily feedback based on production metrics not quarterly!
should be used for control. 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 1. Lead with Financial Information
learning organization 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. Agile Management in the IT Department

1. Effectiveness of a corporate IT department, it 1. The key metrics for a CIO are the level of
is necessary to show that it can add value to inventory of ideas (V), total sum of money
the business invested in IT (I), cycle time (LT).
2. Budget basis, value of deploying systems in 2. Throughput = Budget Basis– DDC*
comparison with system budgets 3. True Basis == also adds the improvements
3. True Basis for Financial metrics, value of post deployment, lifecycle ongoing = Value
operating & improving systems in comparison Add – [DDC – Ops costs]
to incremental usage benefit
4. Calculating Value add is critical * DDC = Direct deployment costs which involves all input materials like
licenses, hardware etc.. Not including people time

1. significantly reduce OE, 1. Monitoring the flow of inventory is the most
2. Net Profit increased and investment important action a CIO can take to improve
decreased, the performance of the IT business unit.
3. Significant improvement in ROI 2. Calculate both Budget and True Basis ROI
1. ROI = [T – OE] / Investments+ 3. Focus on how to improve ROI through T,
Investment, Lead time & OE
4. Manage by Objectives and outcome [OE]
5. Monitoring the flow of inventory is the most
+ includes all investments in ideation, requirements, design, analysis, important action a CIO can take
6. 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 1. Budget Basis which is derived from Biz Case
3. Bloated OE = manage by objectives, smaller is not agile, estimate effort accurately, scope
releases [reduce WIP] lock down,
2.

Vishwanath Ramdas

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

1. Cross-functional team work is essential to 1. Net Profit = SalesForecast – OEEngg -OEdownstream
success 2. ROI = [T(t)Engg – OE(t-1)Engg] / I(t-1)Req qqqq
16. Agile Product Management

2. Considering end of life in accounting during 3. Do not assign cost and value to individual
new releases provides clarity to accounting, features!! [ messy, inaccurate, need effort]
reporting and decision making [controversial] 4. Calculate the $$ / Hrs of time on the system
3. Holistic approach to feature config that CCR and ranking from highest to lowest to
qqqq attribute to sales, what’s sales worth? [Kano] derive product mix priorities
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. 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 replaced
3. Cluster features into groups for release
1. TA helps provide End of life decisions for management & product mix [DSM] qqqq
systems

1. Marketing forecasts are as big a black art as 1. Cost Accounting depends on the burden of
typical software engineering level-of-effort time-sheeting by developers
estimates 2. TA cannot provide strategy on when to stop
2. Measuring the effectiveness of engineering new investments and stagnate the product
depends on other areas of business being into a cash cow
efficient

Vishwanath Ramdas

Throughput Accounting approach to a service industry treats the whole service as
a system.
17. Financial Metrics for Software Services

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

Vishwanath Ramdas

qqqq

Revisit the 12 principles of Agile methods and examine what they really mean
from a business perspective [1/2]
18. The Business Benefit of Agile Methods

• Our highest priority is to satisfy the customer • Business people and developers must work
through early and continuous delivery of valuable together daily throughout the project.
software. – Waste is extremely costly and rework is undesirable.
– Agile methods believe in Throughput dollars – On-site client who can catch misunderstandings and
– Deliver client-valued functionality in a systematic, correct problems with analysis and design.
process-oriented fashion of continuous production. • Build projects around motivated individuals. Give
– Delivered at a steady pace them the environment and support they need, and
• Welcome changing requirements, even late in trust them to get the job done.
development. Agile processes harness change for – leadership and delegation.
the customer's competitive advantage. – TOC >> focus on identifying constraints and removing
– Accept that change is a fact of life. them through exploitation and elevation.
– Stale requirement is valueless, Throughput dollars are – Think Demings 14 principles .
0 for a useless, obviated req. • The most efficient and effective method of
– Cope with change, even late change. conveying information to & within a development
– Genetic fitness implies agility. team is face-to-face conversation.
• Deliver working software frequently, from a couple – minimizes setup time and eliminates by-products
of weeks to a couple of months, with a preference such as documentation.
to the shorter timescale. – It is not zero documentation, but on an optimal set of
– Short lead times & low inventory levels. minimal documentation,
– Reduce Investment & OE in producing software. – Improving communication, trust and understanding
– Generate greater ROI through focus on – Shorten lead times, which reduce OE, reduce
• Increased value added Inventory and Investment, resulting in increased
– More Net Profit through Throughput dollars Throughput
• Reduction of Operating Expenses.
• Reduced Investment

Vishwanath Ramdas

qqqq

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 • Simplicity - the art of maximizing the amount of
progress. work not done—is essential.
– Main metric: production quantity (Q)- code that – focus on simplicity of design
deliver client-valued function. • Reduce lead times through faster coding, less
• Completed Inventory or Throughput dollars testing, less likelihood of bugs, and overall higher
– Compatible with Throughput Accounting, they quality.
measure delivered value. – Simpler designs that can be built faster potentially
increase the overall production, leading to higher
• Agile processes promote sustainable development. Throughput dollars.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely. • The best architectures, requirements, and designs
– Cash flow & lead time are important. emerge from self-organizing teams.
– Sustainable systems of software development turn – This is perhaps the only principle of Agile methods
Investment into Net Profit faster that cannot be easily justified in business terms.
– Encourage flow and believe in slack (below maximum – The premise that self-organized teams, rather than
efficiency). teams commanded and controlled by a manager,
produce better designs leading to shorter lead times
– Slack allows for regeneration of staff and training to could be tested using the metrics described in this
improve their skills book.
• Continuous attention to technical excellence and • At regular intervals, the team reflects on how to
good design enhances agility. become more effective, then tunes and adjusts its
– Rework and waste are costly to production and behavior accordingly.
profitability.
– Principle of a learning organization [Senge 1990].
– Value high-quality craftsmanship.
– Culture where every member is encouraged to think
– Personal mastery discipline [Senge 1990] is a vital about how they work and devise mechanisms for
element in maturing a learning organization. improvement,
– Continuous learning: Most important business
benefit is the tendency toward a culture of
continuous improvement.

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.

Vishwanath Ramdas

A Survey of Methods

Section II

Vishwanath Ramdas

A survey of various software development methods
Both 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. Production Metrics for Traditional Methods

1. Waterfall method helps the cost accounting 1. Inventory in structured methods is measured
approach of tracking inventory, simplify and using the Function Point (FP) metric
push through together 2. Wrong mental model >> specification-budget-
2. Specification is fixed >> Variance measure schedule + cost accounting == mass
from initial requirements 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
1. key advantage of FPs as a metric is their than output.
repeatability, provides a benchmark
1. FPs are standardized and controlled by
an international body

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 uncertainty
1. Unwind the systemic problem - measure
3. Phase approach multiplies inventory and
complexity delivered value;
4. long wait time, large batch sizes mean high
inventory levels, Lack of flow tat creates long
lead times and waste. 1. Issue with structured methods is not structural
5. All estimation anlaysis methods, used to decomposition, use of FP or software analysis
better understand the product are Waste and design techniques involved.
6. Lack of slack – re-work not accounted into 2. The real issue is high levels of inventory, and
resource time focus on documentation to ensure flow
Vishwanath Ramdas

UDP, which can be defined as rigorous dev method;
1. UDP has two granularities, iterations and SDLC UDP
19. Production Metrics for Traditional Methods

phases. Raw ideas delivered as a UDP is an architecture-centric,
2. iteration is a a batch of inventory in a phase. Material functional specification

Inventory Function Point (FP) metric Business Use Case form inventory,
though Use cases don’t have
1. UDP is an architecture-
standards,
centric, Use Case driven
Investment cost of creating functional Inception phase creating Vision
method – Vision
specification and costs in Document and related material
document called performing the FP analysis
Marketing requirements
Lead Time time to take a single Function Time for Use Case to pass through
doc Point through the lifecycle of the Elaboration, Construction, and
2. Use Cases can be used analysis, design, coding and Transition phases
testing until delivery
to describe the business
activities Throughput dollar value added from the $$ value added of the software
delivered Function Points delivered into production at the end
of the Transition phase
1. key advantage of FPs as a metric is their
Production simply the number of number of Use Cases passing
repeatability, provides a benchmark Rate Function Points in any given through any phase
1. FPs are standardized and controlled by time period
an international body Process Iterative incremental method, with
iterations and phases
1. Business Use Cases lead to several Inventory Inventory Cap is reached, no No defined minimum
downstream tech use cases, which should not cap more requirements would be
be counted as inventory [double counting!] gathered
2. UDP adopts the PMI/ISO mental model for Documenta Business Use Cases, a Vision
project management, scope-budget-schedule. tion Document, supplementary
requirements, system Use Cases,
3. UDP does not recognize software phase plan, iteration plans etc..
development as an innately human activity. It
Structure Waterfall, phased linear Release, Phase, Iteration
does not recognize the engineer as a capacity batch approach
constrained resource.
4. UDP has Use Case as unit of inventory; not
very fine grained.
Vishwanath Ramdas

qqqq

Production Definitions in various Software Models
SDLC UDP FDD XP SCRUM
19,21,26,29, 33 Process Elements & Metrics

Raw Material ideas delivered as a UDP is an architecture-centric, Feature List I raw material of XP, taken to requirements statements
functional specification extreme, is the knowledge of defined in product backlog
the customers
Inventory Function Point (FP) metric Business Use Case form Stories are recognized as the does not track Inventory
inventory, though Use cases correct basis for Inventory— (client-valued func.), but
don’t have standards, they are units of client-valued instead a series of tasks
functionality
Investment cost of creating functional Inception phase creating cost of acquiring the Feature cost of acquiring inventory is Out of scope but for
specification and costs in Vision Document and related List very low in XP, usually 1 day. metrics: cost of acquiring
performing the FP analysis material Investment by results requirements + analysis to
maintain Product Backlog
Lead Time time to take a single Function Time for Use Case to pass Each iteration is fixed to 2
Point through the lifecycle of through the Elaboration, weeks; total lead time is a
analysis, design, coding and Construction, and Transition multiple of # of iterations
testing until delivery phases
Throughput dollar value added from the $$ value added of the software dollar value of a User Story value of a delivered
delivered Function Points delivered into production at the Release or a delivered
end of the Transition phase Sprint
Production simply the number of number of Use Cases passing number of Features delivered "velocity" of the team; rate of burn-down rate: rate of
Rate Function Points in any given through any phase in a given time period completion of Story Points tasks completed in Sprint
time period per 2-week dev iteration Backlog
Process Iterative incremental method, RAD approach to Lead
with iterations and phases Time: delivery date fixed,
scope, budget moderated
Inventory cap Inventory Cap is reached, no No defined minimum success of XP is the fact it number of tasks that can
more requirements would be caps inventory levels by strict be undertaken in a
gathered 2-week iterations and 3 mo Release or Sprint
Release
Documentati Business Use Cases, Vision No Requirements in
on Doc, supplementary reqs, document form
system Use Cases, phase
plan, iteration plans etc..
Structure Waterfall, phased linear batch Release, Phase, Iteration Products, Release, Sprint,
approach Tasks

Production FP Metrics Use Cases based metrics, with Features completed by time Time volumetrics on story Sprint review outcomes |
Metrics higher uncertainty across 6 stages of transform points | Feature volumetrics

Vishwanath Ramdas

qqqq

Financial Metrics in various Software Models
Traditional [SDLC/UDP] FDD XP
Inventory V Function points or Use Cases Total Features in the List Story points held in all story
including Not started, WIP, Not cards
20, 24, 27: Financial Metrics for Methods

deployed
Investment I Capital in Inventory of raw Capital in raw material, process Capital in raw material, process
material plus in system [ PCs, across lifecycle across iterations
servers, and software tools]
Operating including direct labor, for the All costs, including direct labor OE Iteration * # of Iterations
Expense OE design, coding, and various
testing stages
Throughput T value of the delivered Function value of the delivered Features value of the delivered Stories
Points less the direct costs using Throughput accounting
involved in deploying
Value Added T – OE calculating the Net Profit figure calculating the Net Profit figure
[T-OE] [T-OE]
ROI [T-OE] / I [T-OE] / I [T-OE] / I
Accounting for Change could increase or Change could increase or Change could increase or
Change decrease scope and this should decrease scope and this should decrease scope and this should
reflect in I reflect in I reflect in I
Accounting for Rework must be ignored in How is re-factoring handled?
rework accounting; Rework should not Continuous or as whole
be shown as new Features; iterations?
Mark features as unfinished
Double Differentiate between I & OE
counting
Structure Release, Phase, Iteration
Vishwanath Ramdas

FDD is essentially a software management method, rather than a software
engineering lifecycle development method
1. FDD genesis -- 1997 -1999 at United
Overseas Bank SNG by Jeff De Luca based 1. Step 1—Shape Modeling: UML Class
on earlier material by Peter Coad Diagram, non-functional requirements &
2. Feature is a small piece of client-valued architectural model
21. Production Metrics in FDD

functionality: a tangible result 2. Step 2—Feature List, Understand scope,
outline for a Functional Specification, prioritize
1. Level of effort is based on 5 point weghted 3. Step 3—Plan by Subject Area: Group Feature
scale Sets (FS) & Subject Areas (SA), schedule of
2. FDD claims that estimation is repeatable, delivery
unique claim as agile says this is unobtainable 4. Step 4—Design by Feature Set: in-depth UML
modeling, Class Diagram, Sequence Diagram
1. FDD defines four layers of architecture: UI— 5. Step 5—Build by Chief Programmer Work
User Interface, PD—Problem Domain Package: CUT, work window of < 2 weeks
(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

1. it is important to deliver on schedule, it is 1. Features are grouped into Feature Sets
difficult to scale resources or budgets, so 2. Features sets group to form Solution areas
22. Project Management with FDD

features must be traded out of the scope 3. Features build happens in batches known as
2. Critical Chain shows it is necessary to add a Chief Programmer Work Packages (CPWP),
project buffer based on uncertainties involved. 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 diagram
3. The total number of Features completed
4. The current percentage of client-valued functionality
completed
5. The number of issues open
6. The trend in the number of open issues as a graph
7. The number of Features blocked
8. The trend in Features blocked as a graph

1. Feature set based on use case
2. Feature Set based on UI Containers
3. Feature lifecycle used to derive throughput
4. Derive Feature relations through PERT
5. 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
qqqq programming
23. FDD Process Elements Explained

• Exploit Engineers [most Prized] without • Constraints removal strategies in FDD
distractions & interruptions • Class/file ownership is critical & version control is a process
constraint.
• Maintain a virtual inbox of work at each station – Availability of a file for editing is a CCR and is exploited & all
other process subordinated
• Development manager should motivate team • Virtual surgical teams to eliminate size – communication non-
• FDD Team Psychology: teamwork, ownership, linearity constraint
peer pressure, peer recognition, shared learning – Developers can be part of multiple teams and balancing work is
their accountability
experience, safety in numbers, group • Eliminate waste of waiting
confessional opportunity, carrot & stick on – Through batching feature sets, limited to a size completed
Feature schedule within 2 Weeks
• Visualize progress • Scope constraint eliminated through buffers
– Features that customer would forego [nice to have]; Kano model
– Feature metrics through time based scoring schema, tiered by time multiple surveys with
• Just Enough Design Initially [JEDI] – ensure flow different timelines
• Time constraint is handled through project buffer
to the next stage, – An accurate estimate should be 50% of the time late! [TOC 97] ;
– Keep modeling wide not deep Create aggregate Buffers for each feed chain
– Keep design lean not big • Budget Constraint – through inventory cap
• All features blocked should have a issue logged – Calculate the theoretical inventory [V = R * LT], and maintain
below this limit
– action priority based on when it would hit Critical • Test Constraints - focusing on improved quality in front of test
Path – Get right the first time, Unit Testing [35% improvement], Peer
• Address local safety problem through focus on reviews
package level completeness metric and regular • Embracing change through – Advanced modeling
– Domain neutral component development through experience &
Production rate reports expertise
• Avoid Heroic Effort that emerge from Scope – Higher quality, usage feedback, demand reduction
Creep, J-Curve Effects • 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
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. Production Metrics in Extreme Programming

1. Inventory & Process is structured by release 1. Requirements written as small chunks of
and iteration, these result in reports stories on index cards, ideally by customers,
2. Enterprise XP projects must run with 1. Larger Stories are known as Epics.
measurement collection as a fundamental part 2. In planning cycle [aka Planning Game]
of the process [not – proof of the pudding is in 1. Stories are assessed for size and risk
eating] [Mayford 2002]
2. Stories are analyzed and broken into
Tasks

1. Visible metrics are called smells in XP 1. Fail early fail often – attempt the riskiest
2. Every iteration based on 2-week budget, elements
stories and re-factoring are included 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
1. Assessing User Stories
iterations of 2 weeks and 3 month release cycles
1. Risk & complexity measurement, anticipatory estimation & reactive feedback controllers | Lack of standard in Story types with
organization is handled through strong feedback
26. XP Process Elements Explained

2. Prioritizing story through Business Value, Risk and Complexity
1. Do the risky ones first [Will DSM Help?]
3. Option theory – Disruptions should be held off until as late as possible
1. 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 constraint
1. 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 Quantity
1. 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 continuously
1. 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
1. No explicit description analysis phase 1. incorporates a daily stand-up meeting to discuss issues
2. Single Product Backlog Requirements interfering with productivity
defects, and other tasks [Schwaber 2003]. 2. organizes development work into three levels: Sprints
28. Production Metrics in Scrum

3. No Sprint plan: tasks called off by developers [<4 weeks], Releases [6-9 sprints], and Products
daily in a self-organizing, volunteer fashion 3. Requirements as a list of client-valued functionality
4. Recognize that expediting increases Lead known as the Product Backlog
Time, as other tasks are slowed to make way 4. 3 inventory sources: Sprint Backlog, Release Backlog,
5. Steady 30-day heartbeat to control LT 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 accuracy
1. 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
1. Scrum Master: compared to a sports coach
29. Scrum Process Elements Explained

1. 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 Sprint
1. limits raw material in development and test, introduces certainty on requirements, eliminates expediting
2. 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 recommended
1. 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 |
Vishwanath Ramdas constraints solving

qqqq

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 Of Change Curve

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.

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
1. RAD methods correctly identify the scope as the constraint with the greatest uncertainty
and unpredictability
30. RAD Process Elements Explained

2. A wise RAD project manager will buffer the scope and leave some slack to absorb any
uncertainty that might jeopardize the delivery date
1. Date > Scope > Resources OR
2. Date > Resources > Scope
3. A steady heartbeat for development cycles
1. 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 Methodology
1. 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 • Fred Brooks argued that adding more people
debate – DO NOT makes a late project later [Brooks 1995]. - J-
– E,g, In US politics ouy are either a donkey Curve
or an elephant, or you opt out of politics. – How do we make a change?
• Each methods has its own scope & scale, – Eli Goldratt's observation that all
31. Devil's Advocacy

with the best context to apply for improvements are changes,
• but not all changes are improvements
• Capers Jones analysis on production rate
improvement •
qqqq – 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.

Vishwanath Ramdas

For Scrum, Beedle and Schwaber argued that all software development is
empirical and, therefore, cannot be planned [1/2]
32. States of Control and Reducing Variation

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

Vishwanath Ramdas

qqqq

Agile methods help organization potentially mature overtime, when maturity is
high, use traditional methods that provide high standards
• AS business and technology space
gets more complex and likely
34. Applicability of Agile Methods

change, Agile is preferred
•Scrum is positioned lower as it
shuns modeling

•By dividing the domain based on •Map on scale vs ability to expedite
eco-system & Maturity •Uncertainty >> Low scale & Shorter
•Large holistic projects are best Lead times >> Agile Methods
suited for Rigorous software mgmt •How to reduce costs and deliver
•Most other areas Agile models are faster?
preferred

•Lapre and Van Wassenhove
diagram of conceptual and
operational learning
•How to transfer learning?

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

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

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
REFERENCES

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.

Vishwanath Ramdas

Precis Book Agile mgmt software engineering david j andreson summary viramdas 200911 plain

More Related Content

What's hot (18)

Similar to Precis Book Agile mgmt software engineering david j andreson summary viramdas 200911 plain (20)

More from Vishwanath Ramdas (20)

Recently uploaded (20)

Precis Book Agile mgmt software engineering david j andreson summary viramdas 200911 plain