Craig Larman's Certified Less Practitioner

Total Page:16

File Type:pdf, Size:1020Kb

Craig Larman's Certified Less Practitioner LeSS Practitioner More with LeSS Craig Larman craiglarman.com & less.works Please... Do not copy or share this material, or re-use for other education. Exceptions require prior written consent of the author. Copyright © 2016 Craig Larman, All rights reserved. May not be reproduced without written consent of the author. v.44 1 1 2 Opening Topics Scaling? 3 3 4 first, a caution... One of the directors of SAGE was discussing why the programming had gotten out of hand. He was then asked, “If you had it to do all over again, what would you do differently?” … 5 6 5 6 His answer: after years working in “Find the ten best large people and write multisite the entire thing offshore themselves.” development, [Horowitz74] our key advice? … 7 8 7 8 but groups still ‘scale’, large - don’t for reasons… multisite - don’t compelling (“create LTE”) offshore - don’t questionable (“low-cost sites”) 9 10 9 10 Descaling & so is LeSS for scaling? Simplifying 11 11 12 “How can we apply is this the right agile at scale in our big question? … complex organization?” 13 14 13 14 This is an Important Question… traditional large groups are complicated — though not “How can we simplify because they need to be, but the unnecessarily big and because their organizational complex organizational designs create an illusion of unnecessary complexity design, and be agile rather than do agile?” 15 16 15 16 LeSS descales organizational complexity, dissolving unnecessary complex organizational solutions, and solving in More with LeSS simpler ways. 17 18 17 18 Some Big Keeping it Simple Ideas 19 19 20 not here just to explore own “LeSS system”, rather: vs how to think about systems in general rent 21 22 21 22 The IKEA Effect why 23 24 23 24 don’t believe “It is difficult to get a man to anything i say understand something when his job depends on not fads & gurus -> insight understanding it.” rent -> own — Upton Sinclair 25 26 25 26 Guide: Job Safety, but not Role Safety Practicalities 27 27 28 Course PDF & Room Photos at less.works 29 30 29 30 9:00 18:00 31 32 31 32 #LeSSWorks @less_works 33 34 33 34 local meetups Your this week? Backgrounds 35 35 36 (optional) team re-organization Introductions > diversity at each table 37 38 37 38 coach background? course overview? team: standing: round-robin > briefly (30 seconds each), we’ll defer these warm-up introduce each other topics until later today > when team done, please sit why? so day-1 morning is more focused on learning 39 40 39 40 Where are We? 1. Opening Topics System Optimization 2. System Optimization, not Local not Optimization Local Optimization 3. Organizational Structure 4. LeSS Overview 5. <Your Priorities> 41 42 41 42 what are we Local about to learn? Optimization 43 43 44 in traditional large- scale organizational individual: design, the overarching > write a definition of what you and repeating theme is think is local optimization coach: review local optimization 45 46 45 46 focus on moving the ball? examples of local optimization… or on player job title? 47 48 47 48 focus on delivering dishes? Local Optimization Cognitive Bias “Everyone is busy and doing their best, efficiently on their task, yet the system is delivering slow and not delighting the user.” or on chopping onions? 50 49 50 Local Optimization Cognitive Bias Local Optimization Cognitive Bias > (incorrect) belief: optimizing a part optimizes “It’s more efficient or the whole system > locally optimize, for a person or sub-group: productive when a >local efficiency person/group does >local performance >local output one specialization.” >local activity 51 52 51 52 Local Optimizations… Local Optimizations… are justified as “good/best/efficient” … are not thought of as sloppy quick-fixes or hacks … but their consequence is system- level sub optimization of (e.g.) they are justified as customer value, customer cycle time, customer delight, company “good/best/efficient” robustness, company adaptiveness 53 54 53 54 Local Optimization Cognitive Bias individual > think of 1 example of local Q: “Why are you doing that?” optimization you’ve seen A: “Because it’s best & efficient.” coach: review and yet, the system-level consequence is a sub-optimization > compare & contrast “quick fixes” with local optimization 55 56 55 56 local optimization is a Why Local cognitive bias Optimization? list of cognitive biases? 57 58 57 58 Reinforcing Loop Local Optimization is related to… > sub- > measurement & optimization metrics belief in local org support for > > optimization local optimization management by performance objectives management > resource > appraisals management 59 60 59 60 group > examples of metrics or System objectives or “resource management” that led to local Optimization optimization? 61 61 62 Systems Optimization “watch the ball, not the players” the One True system optimizing goal? “deliver the dish, not the onions” 63 64 63 64 Systems Optimization > there are no ‘good’ or ‘bad’ organizational systems coach > counter-intuitive example of a > but if the observed behavior is inconsistent with its espoused local optimization inconsistent optimizing goal, it is unskillful with system optimization goal? 65 66 65 66 Local vs Systems Optimization the LeSS System Goals > local optimization is a local “best” or > company-level system “efficient” that… optimization for > sub-optimizes system optimization goal > deliver highest customer > often generates the “lean wastes” value (first) > overproduction, inventory, handoff, waiting, not using people’s full > agility (“turn on a dime, for a potential, hidden defects, … dime”) 67 68 67 68 Systems Thinking 70 69 70 What is the SYSTEM? Scaling Lean & Agile Development Thinking and Organizational Tools > at least… for Large-Scale Scrum Craig Larman Bas Vodde > the entire company + > customers/markets + > supply chain > (it isn’t a group within a company) 71 72 71 72 Systems Thinking Systems Thinking > understand there is a > optimize the whole > see the whole SYSTEM > beware local-optimization > optimize the whole > learn to reason about cognitive bias ‘any’ system, not 1 system > focus on > think & talk about system > see the whole, over space dynamics by drawing interaction and time systems model diagrams effects, not on in groups separate parts > see how things influence one another and the interaction effects 73 74 73 74 pairs: standing individual: > with your graphics (but without > draw a graphic for each looking at course notes), one systems thinking idea person explain to partner the > when done, please stand systems thinking ideas > please sit when done 75 76 75 76 Systems Thinking Sketch a System Model learn to reason about ‘any’ system not just 1 system how? … AKA causal loop diagram 77 78 77 78 we model to have a conversation own vs the output is shared understanding, not a model rent 79 80 79 80 Common Elements coach: > sketch a system model 81 82 81 82 team > sketch a system model, given this: > “We don’t have time to create clean code, because we are too busy going slow because of dirty code.” > start with these variables; write them verbatim 1.% clean code 2.# defects coach: debrief 3.time available to craft clean code 4.time dealing with defects 5.time living with dirty code & its consequences 6.velocity 7.pressure to “go faster” 83 84 83 84 we model to have a conversation own vs the output is shared understanding, not a model rent 85 86 85 86 group Local > in LeSS, when do systems modeling? Optimization > in what contexts or in Backlogs meetings can it help? 87 87 88 team > sketch a system model, given this: let’s start to apply > 1 product, many teams, each team has a Team “Product Backlog” prioritized by a Team “Product Owner” > start with these variables verbatim; do NOT try to link this to old variables in system modeling to prior exercises… until you have finished linking these first 1.# backlogs (e.g. 1 backlog per team, 1 backlog for 2 teams, 1 backlog for all teams) “scaling agile” 2.quality of overview at product level 3.% of total (product) items a team knows well (requirements & design) organizational design 4.agility of teams to change direction at the company level 5.% of items worked on each Sprint that are highest value from a company view choices… 6.likelihood that a single team will see they may be working on low-value items, from a company view 7.local team identity 89 90 89 90 coach > if system optimizing goals are “local > highest value & agility, at optimization company level > … how many backlogs? in backlogs” > … is the answer “good” or “bad”? 91 92 91 92 LeSS Rule(s) therefore… 1 Product Backlog 93 94 93 94 1 Product Backlog … and no “redefining” by calling a set of team educate: why backlogs “part of 1 Product Backlog” 95 96 95 96 supporting secondary own goals or constraints vs (e.g. “team local identity”) rent without sub-optimizing the system goal 97 98 97 98 1 Product Backlog Scrum Guide: “[Multiple Teams] often work and therefore… together on the same product. One Product Backlog is used to describe the upcoming work on the product.” 99 100 99 100 LeSS Rule(s) 1 (and only 1) biased by Product Owner choice of variables? 101 102 101 102 team “driving variables” > update your system model with the “good enough” model refined during the debrief 103 104 103 104 1 Product Backlog team > update your system model with but still these variables; replace # backlogs with: implicit > # explicit backlogs team queues > (note: a backlog is a queue) > # implicit queues 105 106 105 106 coach team > if system optimizing goals are > update your system model: > highest value & agility, at > % time teams spend on company level broader learning of more items > … in general, how many items should a team learn about? 107 108 107 108 LeSS Rule(s) Do multi-team PBR and/or overall PBR to therefore… increase shared understanding and broader learning.
Recommended publications
  • Writing and Reviewing Use-Case Descriptions
    Bittner/Spence_06.fm Page 145 Tuesday, July 30, 2002 12:04 PM PART II WRITING AND REVIEWING USE-CASE DESCRIPTIONS Part I, Getting Started with Use-Case Modeling, introduced the basic con- cepts of use-case modeling, including defining the basic concepts and understanding how to use these concepts to define the vision, find actors and use cases, and to define the basic concepts the system will use. If we go no further, we have an overview of what the system will do, an under- standing of the stakeholders of the system, and an understanding of the ways the system provides value to those stakeholders. What we do not have, if we stop at this point, is an understanding of exactly what the system does. In short, we lack the details needed to actually develop and test the system. Some people, having only come this far, wonder what use-case model- ing is all about and question its value. If one only comes this far with use- case modeling, we are forced to agree; the real value of use-case modeling comes from the descriptions of the interactions of the actors and the system, and from the descriptions of what the system does in response to the actions of the actors. Surprisingly, and disappointingly, many teams stop after developing little more than simple outlines for their use cases and consider themselves done. These same teams encounter problems because their use cases are vague and lack detail, so they blame the use-case approach for having let them down. The failing in these cases is not with the approach, but with its application.
    [Show full text]
  • Agile Software Development: the Cooperative Game Free
    FREE AGILE SOFTWARE DEVELOPMENT: THE COOPERATIVE GAME PDF Alistair Cockburn | 504 pages | 19 Oct 2006 | Pearson Education (US) | 9780321482754 | English | New Jersey, United States Cockburn, Agile Software Development: The Cooperative Game, 2nd Edition | Pearson View larger. Preview this title online. Request a copy. Additional order info. Buy this product. The author has a deep background and gives us a tour de force of the emerging agile methods. The agile model of software development has taken the world by storm. Cockburn also explains how the cooperative game is played in business and on engineering projects, not just software development. Next, he systematically illuminates the agile model, shows how it has evolved, and answers the Agile Software Development: The Cooperative Game developers and project managers ask most often, including. Cockburn takes on crucial misconceptions that cause agile projects to fail. Cockburn turns to the practical Agile Software Development: The Cooperative Game of constructing agile methodologies for your own teams. This edition contains important new contributions on these and other topics:. This product is part of the following series. Click on a series title to see the full list of products in the series. Chapter 1. Chapter 5. Chapter 6. Appendix A. Pearson offers special pricing when you package your text with other student resources. If you're interested in creating a cost-saving package for your students, contact your Pearson rep. Alistair Cockburn is an internationally renowned expert on all aspects of software development, from object-oriented modeling and architecture, to methodology design, to project management and organizational alignment. Sincehe has led projects and taught in places from Oslo to Cape Town, from Vancouver to Beijing.
    [Show full text]
  • GRASP Patterns
    GRASP Patterns David Duncan November 16, 2012 Introduction • GRASP (General Responsibility Assignment Software Patterns) is an acronym created by Craig Larman to encompass nine object‐oriented design principles related to creating responsibilities for classes • These principles can also be viewed as design patterns and offer benefits similar to the classic “Gang of Four” patterns • GRASP is an attempt to document what expert designers probably know intuitively • All nine GRASP patterns will be presented and briefly discussed What is GRASP? • GRASP = General Responsibility Assignment Software Patterns (or Principles) • A collection of general objected‐oriented design patterns related to assigning defining objects • Originally described as a collection by Craig Larman in Applying UML and Patterns: An Introduction to Object‐Oriented Analysis and Design, 1st edition, in 1997. Context (1 of 2) • The third edition of Applying UML and Patterns is the most current edition, published in 2005, and is by far the source most drawn upon for this material • Larman assumes the development of some type of analysis artifacts prior to the use of GRASP – Of particular note, a domain model is used • A domain model describes the subject domain without describing the software implementation • It may look similar to a UML class diagram, but there is a major difference between domain objects and software objects Context (2 of 2) • Otherwise, assumptions are broad: primarily, the practitioner is using some type of sensible and iterative process – Larman chooses
    [Show full text]
  • Model-Driven Development of Complex Software: a Research Roadmap Robert France, Bernhard Rumpe
    Model-driven Development of Complex Software: A Research Roadmap Robert France, Bernhard Rumpe Robert France is a Professor in the Department of Computer Science at Colorado State University. His research focuses on the problems associated with the development of complex software systems. He is involved in research on rigorous software modeling, on providing rigorous support for using design patterns, and on separating concerns using aspect-oriented modeling techniques. He was involved in the Revision Task Forces for UML 1.3 and UML 1.4. He is currently a Co-Editor-In-Chief for the Springer international journal on Software and System Modeling, a Software Area Editor for IEEE Computer and an Associate Editor for the Journal on Software Testing, Verification and Reliability. Bernhard Rumpe is chair of the Institute for Software Systems Engineering at the Braunschweig University of Technology, Germany. His main interests are software development methods and techniques that benefit form both rigorous and practical approaches. This includes the impact of new technologies such as model-engineering based on UML-like notations and domain specific languages and evolutionary, test-based methods, software architecture as well as the methodical and technical implications of their use in industry. He has furthermore contributed to the communities of formal methods and UML. He is author and editor of eight books and Co-Editor-in-Chief of the Springer International Journal on Software and Systems Modeling (www.sosym.org). Future of Software Engineering(FOSE'07)
    [Show full text]
  • Agile and Iterative Development : a Managers Guide Pdf, Epub, Ebook
    AGILE AND ITERATIVE DEVELOPMENT : A MANAGERS GUIDE PDF, EPUB, EBOOK Craig Larman | 368 pages | 11 Aug 2003 | Pearson Education (US) | 9780131111554 | English | Boston, United States Agile and Iterative Development : A Managers Guide PDF Book Rum Haunt. The Agile Manifesto and Principles. Download pdf. Investors poured billions into unproven concepts. Problems with the Waterfall. Agile is the ability to create and respond to change. Distinct preferred subjects that distribute on our catalog are trending books, solution key, test test question and answer, manual example, exercise guideline, test sample, customer handbook, owner's guideline, assistance instructions, restoration guide, and so forth. It is a way of dealing with, and ultimately succeeding in, an uncertain and turbulent environment. Evolutionary and Adaptive Development. We will identify the effective date of the revision in the posting. Each sprint has a fixed length, typically weeks, and the team has a predefined list of work items to work through in each sprint. Learn more. Timeboxed Iterative Development. The added benefit of having the definitions and practices of the individual methods in one book is also great. The Facts of Change on Software Projects. Agile Software Development Series. A lot of people peg the start of Agile software development, and to some extent Agile in general, to a meeting that occurred in when the term Agile software development was coined. They then determine how to pursue that strategy and its related goals and objectives by prioritizing different initiatives, many of which they identify by using quantitative and qualitative research tactics. Orders delivered to U. New Paperback Quantity available: 1.
    [Show full text]
  • Iterative, Evolutionary, and Agile
    UML and Patterns.book Page 17 Thursday, September 16, 2004 9:48 PM Chapter 2 2 ITERATIVE, EVOLUTIONARY, AND AGILE You should use iterative development only on projects that you want to succeed. —Martin Fowler Objectives G Provide motivation for the content and order of the book. G Define an iterative and agile process. G Define fundamental concepts in the Unified Process. Introduction Iterative development lies at the heart of how OOA/D is best practiced and is presented in this book. Agile practices such as Agile Modeling are key to apply- ing the UML in an effective way. This chapter introduces these subjects, and the Unified Process as a relatively popular sample iterative method. What’s Next? Having introduced OOA/D, this chapter explores iterative development. The next introduces the case studies that are evolved throughout the book, across three iterations. Iterative, OOA/D Case Evolutionary Inception Introduction & Agile Studies 17 UML and Patterns.book Page 18 Thursday, September 16, 2004 9:48 PM 2 – ITERATIVE, EVOLUTIONARY, AND AGILE Iterative and evolutionary development—contrasted with a sequential or “waterfall” lifecycle—involves early programming and testing of a partial sys- tem, in repeating cycles. It also normally assumes development starts before all the requirements are defined in detail; feedback is used to clarify and improve the evolving specifications. We rely on short quick development steps, feedback, and adaptation to clarify the requirements and design. To contrast, waterfall values promoted big up- front speculative requirements and design steps before programming. Consis- tently, success/failure studies show that the waterfall is strongly associated with the highest failure rates for software projects and was historically promoted due to belief or hearsay rather than statistically significant evidence.
    [Show full text]
  • Protected Variation: the Importance of Being Closed Craig Larman
    design Editor: Martin Fowler, Thought Works ■ [email protected] Protected Variation: The Importance of Being Closed Craig Larman he Pattern Almanac 2000 (Addison- OCP and PV formalize and generalize a Wesley, 2000) lists around 500 soft- common and fundamental design principle ware-related patterns—and given this described in many guises. OCP and PV are reading list, the curious developer has two expressions of the same principle— Tno time to program! Of course, there protection against change to the existing are underlying, simplifying themes and code and design at variation and evolution principles to this pattern plethora that de- points—with minor differences in emphasis. velopers have long considered and dis- I am nominating the term protected varia- cussed. One example is Larry Constantine’s tion for general use, as it is short and clear. coupling and cohesion guidelines In OCP, the term module includes all dis- (see “Structured Design,” IBM crete software elements, including methods, Systems J., vol. 13, no. 2, 1974). classes, subsystems, applications, and so forth. Yet, these principles must contin- Also, the phrase “closed with respect to X” ually resurface to help each new means that clients are not affected if X generation of developers and ar- changes. For example, “The class is closed chitects cut through the apparent with respect to instance field definitions.” PV disparity in myriad design ideas uses the term interface in the broad sense of an and help them see the underlying access view—not exactly a Java or COM in- and unifying forces. terface, for example. One such principle, which Bertrand Meyer describes in Ob- Information hiding is PV, ject-Oriented Software Construction (IEEE not data encapsulation Press, 1988), is the Open–Closed Principle: “On the Criteria To Be Used in Decom- Modules should be both open (for extension posing Systems Into Modules” is a classic and adaptation) and closed (to avoid modifi- that is often cited but seldom read.
    [Show full text]
  • Object-Oriented Analysis and Design (OOA/D)
    Chapter 1 OBJECT-ORIENTED ANALYSIS AND DESIGN The shift of focus (to patterns) will have a profound and enduring effect on the way we write programs. —Ward Cunningham and Ralph Johnson Objectives • Compare and contrast analysis and design. • Define object-oriented analysis and design (OOA/D). • Illustrate a brief example. 1.1 Applying UML and Patterns in OOA/D What does it mean to have a good object design? This book is a tool to help devel- opers and students learn core skills in object-oriented analysis and design (OOA/D). These skills are essential for the creation of well-designed, robust, and maintainable software using object technologies and languages such as Java, C++, Smalltalk, and C#. The proverb "owning a hammer doesn't make one an architect" is especially true with respect to object technology. Knowing an object-oriented language (such as Java) is a necessary but insufficient first step to create object systems. Knowing how to "think in objects" is also critical. This is an This is an introduction to OOA/D while applying the Unified Modeling Lan- introduction guage (UML), patterns, and the Unified Process. It is not meant as an advanced text; it emphasizes mastery of the fundamentals, such as how to assign respon- sibilities to objects, frequently used UML notation, and common design pat- 1 - OBJECT-ORIENTED ANALYSIS AND DESIGN terns. At the same time, primarily in later chapters, the material progresses to a few intermediate-level topics, such as framework design. Applying UML The book is not just about the UML. The UML is a standard diagramming nota- tion.
    [Show full text]
  • Business Modelling: UML Vs. IDEF
    Griffith University School of Computing and Information Technology Domain: Advanced Object Oriented Concepts Business Modelling: UML vs. IDEF available electronically at: http://www.cit.gu.edu.au/~noran © Ovidiu S. Noran Table of Contents. 1 Introduction....................................................................................................1 1.1 The objectives of this paper..............................................................................1 1.2 Motivation.........................................................................................................1 1.3 Some Important Terms.....................................................................................2 1.3.1 Models. .............................................................................................................. 2 1.3.2 Business Process Models.................................................................................. 2 1.3.3 Information Systems Support. ........................................................................... 3 1.3.3.1 The Business Model as a Base for Information Systems.......................... 3 1.3.3.2 'Legacy' Systems....................................................................................... 4 1.3.4 Business Improvement vs. Innovation............................................................... 4 1.4 Business Concepts...........................................................................................4 1.4.1 Business Architecture. ......................................................................................
    [Show full text]
  • Complexity & Verification: the History of Programming As Problem Solving
    COMPLEXITY & VERIFICATION: THE HISTORY OF PROGRAMMING AS PROBLEM SOLVING A DISSERTATION SUBMITTED TO THE FACULTY OF THE GRADUATE SCHOOL OF THE UNIVERSITY OF MINNESOTA BY Joline Zepcevski IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF DOCTOR OF PHILOSOPHY Arthur L. Norberg February 2012 © Copyright by Joline Zepcevski 2012 All Rights Reserved Acknowledgments It takes the work of so many people to help a student finish a dissertation. I wish to thank Professor Arthur L. Norberg for postponing his retirement to be my advisor and my friend over the course of this project. Thank you to my committee, Professor Jennifer Alexander, Professor Susan Jones, Dr. Jeffery Yost, and Professor Michel Janssen, all of whom individually guided this dissertation at different times and in specific ways. Thank you also to Professor Thomas Misa for his guidance and assistance over many years. I had a great faculty and a great cohort of graduate students without whom this dissertation would never have been completed. I particularly want to thank Sara Cammeresi, whose unending support and friendship were invaluable to the completion of this project. I wish to thank my family, Jovan Zepcevski, Geraldine French, Nicole Zepcevski, and Brian Poff, who supported me and loved me throughout it all. I also want to thank my friends: Tara Jenson, Holly and Aaron Adkins, Liz Brophey, Jennifer Nunnelee, Jen Parkos, Vonny and Justin Kleinman, Zsuzsi Bork, AJ Letournou, Jamie Stallman, Pete Daniels, and Megan Longo who kept me sane. I need to thank Lisa Needham for all her assistance. Without your help, I wouldn’t sound nearly as smart.
    [Show full text]
  • For Managing Large U.S. Gov't Cloud Computing Projects
    Lean & Agile Enterprise Frameworks For Managing Large U.S. Gov’t Cloud Computing Projects Dr. David F. Rico, PMP, CSEP, ACP, CSM, SAFe Twitter: @dr_david_f_rico Website: http://www.davidfrico.com LinkedIn: http://www.linkedin.com/in/davidfrico Facebook: http://www.facebook.com/david.f.rico.9 Agile Capabilities: http://davidfrico.com/rico-capability-agile.pdf Agile Resources: http://www.davidfrico.com/daves-agile-resources.htm Agile Cheat Sheet: http://davidfrico.com/key-agile-theories-ideas-and-principles.pdf Author Background Gov’t contractor with 32+ years of IT experience B.S. Comp. Sci., M.S. Soft. Eng., & D.M. Info. Sys. Large gov’t projects in U.S., Far/Mid-East, & Europe Career systems & software engineering methodologist Lean-Agile, Six Sigma, CMMI, ISO 9001, DoD 5000 NASA, USAF, Navy, Army, DISA, & DARPA projects Published seven books & numerous journal articles Intn’l keynote speaker, 100+ talks to 11,000 people Adjunct at GWU, UMBC, UMUC, Argosy, & NDMU Specializes in metrics, models, & cost engineering Cloud Computing, SOA, Web Services, FOSS, etc. 2 Today’s Whirlwind Environment Global Reduced Competition IT Budgets Work Life Obsolete Imbalance Technology & Skills Demanding 81 Month Customers Cycle Times Overruns Inefficiency Vague Attrition High O&M Overburdening Requirements Escalation Lower DoQ Legacy Systems Runaways Vulnerable Cancellation N-M Breach Organization Redundant Downsizing Data Centers Technology Poor Change System Lack of IT Security Complexity Interoperability Pine, B. J. (1993). Mass customization: The new frontier in business competition. Boston, MA: Harvard Business School Press. Pontius, R. W. (2012). Acquisition of IT: Improving efficiency and effectiveness in IT acquisition in the DoD.
    [Show full text]
  • Download Presentation Slides
    Lean & Agile Enterprise Frameworks For Managing Large U.S. Gov’t Cloud Computing Projects Dr. David F. Rico, PMP, CSEP, ACP, CSM, SAFe Twitter: @dr_david_f_rico Website: http://www.davidfrico.com LinkedIn: http://www.linkedin.com/in/davidfrico Agile Capabilities: http://davidfrico.com/rico-capability-agile.pdf Agile Resources: http://www.davidfrico.com/daves-agile-resources.htm Agile Cheat Sheet: http://davidfrico.com/key-agile-theories-ideas-and-principles.pdf Author BACKGROUND Gov’t contractor with 32+ years of IT experience B.S. Comp. Sci., M.S. Soft. Eng., & D.M. Info. Sys. Large gov’t projects in U.S., Far/Mid-East, & Europe Career systems & software engineering methodologist Lean-Agile, Six Sigma, CMMI, ISO 9001, DoD 5000 NASA, USAF, Navy, Army, DISA, & DARPA projects Published seven books & numerous journal articles Intn’l keynote speaker, 125+ talks to 12,000 people Specializes in metrics, models, & cost engineering Cloud Computing, SOA, Web Services, FOSS, etc. Adjunct at five Washington, DC-area universities 2 Lean & Agile FRAMEWORK? Frame-work (frām'wûrk') A support structure, skeletal enclosure, or scaffolding platform; Hypothetical model A multi-tiered framework for using lean & agile methods at the enterprise, portfolio, program, & project levels An approach embracing values and principles of lean thinking, product development flow, & agile methods Adaptable framework for collaboration, prioritizing work, iterative development, & responding to change Tools for agile scaling, rigorous and disciplined planning & architecture, and a sharp focus on product quality Maximizes BUSINESS VALUE of organizations, programs, & projects with lean-agile values, principles, & practices Leffingwell, D. (2011). Agile software requirements: Lean requirements practices for teams, programs, and the enterprise.
    [Show full text]