• Like
Precis Book Agile mgmt software engineering david j andreson summary viramdas 200911 plain
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.

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


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

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

Published in Technology , Business
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads


Total Views
On SlideShare
From Embeds
Number of Embeds



Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

    No notes for slide


  • 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 browseVishwanath 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 Constraints 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. – Dont 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 usersVishwanath 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 isnt 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 customers 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. IssuesVishwanath Ramdas
  • 9. Agile Methods is not a Fad but a trend: Rightly understood, management is aliberal art, drawing freely from the disciplines that help us make sense of ourselves and our world. Thats 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 Senges 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 Goldratts 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 Amblers 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. – Websters 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 IVishwanath 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 TOCVishwanath 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 bufferingVishwanath 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 defectsVishwanath 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 paralysisVishwanath Ramdas
  • 25. qqqqThe 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 isolationVishwanath 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. Reinertsens 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 incentivesVishwanath 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? turnoverVishwanath 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 controlVishwanath 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 efficientVishwanath 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 customers 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 InvestmentVishwanath 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 IIVishwanath 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 flowVishwanath 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
  • 39. 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 volumetricsVishwanath Ramdas
  • 40. 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, IterationVishwanath Ramdas
  • 41. 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 projectVishwanath Ramdas
  • 42. 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 monitoringVishwanath Ramdas
  • 43. 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 reviewsVishwanath Ramdas
  • 44. 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 processVishwanath Ramdas
  • 45. 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 thinkingVishwanath Ramdas
  • 46. 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
  • 47. 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
  • 48. 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 Becks Extreme Programming Explained, – Alistair Cockburn pointed out that Becks 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
  • 49. 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 agileVishwanath Ramdas
  • 50. Comparison of Methods Measure the smallest thing you can measure. . . Because it gives you fast feedback." —Seth GodinVishwanath Ramdas
  • 51. 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 Goldratts observation that all 31. Devils 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 dont – 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
  • 52. 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 Shewharts 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
  • 53. 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
  • 54. 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 Demings 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
  • 55. 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. • Reinertsens "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
  • 56. References: • Joan Magretta | book | "What Management Is" [2002, p.2]. • Tom DeMarco |book | "Slack,"[vi] • OConnor, Joseph & McDermott, lan | book | The Art of Systems Thinking: Essential Skills for Creativity and Problem Solving Thorsons, San Francisco, California 1997 REFERENCESVishwanath Ramdas