my personal notes on Agile management Book By David Anderson.. used as a reference for projects and programs in lean agile for software and services organizations

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

2. http://www.amazon.co.uk/Agile-Management-Software-Engineering-
Constraints/dp/0131424602
THERE IS NOTHING LIKE
READING THE BOOK..
READ IT..
Vishwanath Ramdas

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

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

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

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

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

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

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

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

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

12. Theories that support and enable agile software development
• Lean Production • Comparison & Evaluation of the
Theories
1. Theories for Agile Management
– "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

13. qqqq
Three Phases of Scientific Development: Eli Goldratt suggested that the sciences
evolve in three distinct phases
• Phase 1—Classification
1. Theories for Agile Management
– 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

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

15. Agile Management
Section I
Vishwanath Ramdas

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

33. qqqq
Revisit the 12 principles of Agile methods and examine what they really mean
from a business perspective [2/2]
18. The Business Benefit of Agile Methods
• 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

34. More than Agility
18. The Business Benefit of Agile Methods
• 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

35. A Survey of Methods
Section II
Vishwanath Ramdas

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

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

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