PMI-ACP® Study Notes & Exam Cheat Sheet
360PMO Project Management Consulting, Inc. Agile Training and Consulting Email: contactus@360pmo.com Web:www.360pmo.com
Copyright © 2016 by 360PMO Project Management Consulting, Inc.
Version 1.2 B12062016
This study Notes and cheat sheet is exclusive for PMI-ACP exam preparation and training purpose only. All copyright references mention in this document retain with their respective author, web pages or publishers. All other brands or product names used in this document are the trade names or registered trademarks of their respective owners. No parts of this cheat sheet may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying, recording, or by an information storage and retrieval system, without permission in writing from the 360PMO.
The designer of this study notes and cheat sheet has taken care in the preparation of this course material, but makes no expressed or implied warranty of any kind and assumes no responsibility for errors or omissions. No liability is assumed for incidental or consequential damages in connection with or arising out of the use of the information or programs contained herein.
PMI-ACP® Study Notes & Exam Cheat Sheet By Aleem Khan, PMI-ACP, PMP, CSM, CSP
All registered and unregistered trademarks (web pages, publishers, service marks, brands, icons, copyright etc.) mentioned on in this document are the property of their respective owners. “PMI-ACP," “PMI-Agile Certified Practitioner (PMI-ACP),” “PMOBOK,” “PMI,” and “PMP” are either marks or registered marks of the Project Management Institute, Inc.
1. Agile Framework
What is Agile Agile Manifesto -Values and Principles Agile Practices / Techniques
Agile methodologies Complex Adaptive Systems
1.1 What is Agile? Agile is a Philosophy that uses organizational models based on people, collaboration and shared values. Agile uses rolling wave planning; iterative and incremental delivery; rapid and flexible response to change; and open communication between teams, stakeholders, and customers. 1.2 Agile Manifesto Agile Manifesto is a public declaration of the philosophy and principles of agile software development, created in February 2001 in Snowbird, Utah, USA. 1.3 Agile Values
INDIVIDUALS AND INTERACTIONS OVER PROCESSES AND TOOLS WORKING SOFTWARE OVER COMPREHENSIVE DOCUMENTATION CUSTOMER COLLABORATION OVER CONTRACT NEGOTIATION RESPONDING TO CHANGE OVER FOLLOWING A PLAN
1.4 Agile Principles 1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. 2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. 3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. 4. Business people and developers must work together daily throughout the project. 5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. 6. The most efficient and effective method of conveying information to and within a development team is faceto-face conversation. 7. Working software is the primary measure of progress. 8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. 9. Continuous attention to technical excellence and good design enhances agility. 10. Simplicity--the art of maximizing the amount of work not done--is essential. 11. The best architectures, requirements, and designs emerge from self-organizing teams. 12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Page 3
1.5 Agile Methodologies Agile is an umbrella term that describes several Agile methodologies. Examples include: Scrum, Extreme Programming (XP), Crystal, Dynamic Systems Development Method (DSDM Atern), Feature Driven Development (FDD). Lean practices have also emerged as a valuable Agile methodology.
The various Agile methodologies share much of the same philosophy, as well as many of the same characteristics and practices. But from an implementation standpoint, each has its own recipe of practices, terminology, and tactics. 1.6 Agile Practices / Techniques Activities that are the application of agile principles, some of them are: 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15.
Time-boxing Retrospective Spike Solution Planning Poker Backlog Prioritization Progress Elaboration Minimal Marketable Features Personas Quality Assurance Refactoring Relative Sizing Product Vision Pair Programming Story Mapping User Stories
16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30.
Product Backlog Visualize Workflow Wireframe Daily Stand-up Limit Work in Progress (WIP) Project Chartering Osmotic Communication Test Driven Development (TDD) Velocity Unit Testing Test First Development Technical Debt Avoid Waste Short Iterations Sprint Goals
31. 32. 33. 34. 35. 36. 37. 38. 39. 40.
Servant Leader Self -organization Team Agreements Release Goals Release Plan Task board Swarming Regression Test Minimum Viable Product Last Responsible Moment (LRM) 41. Team contracts/Rules of engagement 42. + Many more.
Page 4
Some pages are omitted from this preview
Page 5
2. Agile Teams
Agile Teams Team Brainstorming Techniques Five Dysfunctions of a Team Development Mastery Models Traditional vs. Agile Generalized Specialist
Caves and Common Osmotic Communication Information Radiator Swarming Six Thinking Hats Collaboration Games
The core of Agile is high performance teams. Agile teams are Cross-functional and have all competencies needed to accomplish the work without depending on others not part of the team.
Team organized around the work Empowered Self-organize / Self-managed Team pull s the task from queue /backlog Cross functional Intensely collaborative
An empowered team is one that is both self-organization and self-directing. In self-organizing, teams focus on how the work will be done; in self-directing, they focus on how team members will work together. Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team. Agile emphasizes the notion of generalizing specialist, as opposed to role specialist. In other words, anyone who is qualified for a role can undertake it. This practice helps optimize the use of resources, since people who can perform multiple jobs are able to switch from one role to another as the demand arises. The practice allows for more efficient sharing of information and helps eliminate circumstances where people in certain roles are idle or overstretched at any point in the project. 2.1 Team Brainstorming Techniques Agile teams use brainstorming to identify options, solve issues, and improve their processes. The three common brainstorming techniques are free for all, round robin, and quiet writing.
Free for all is an informal method in which participants spontaneously shout out their ideas and build on each other’s suggestions. In round robin, everyone takes a turn suggesting an idea, or building on another idea that has been raised. In quiet writing, team members are given quiet time to generate a list of ideas on their own before sharing them.
Page 6
2.2 Five Dysfunctions of a Team 1. 2. 3. 4.
Absence of Trust: The fear of being vulnerable with team members prevents the building of trust within the team. Fear of Conflict: The desire to preserve artificial harmony stifles the occurrence of productive ideological conflict. Lack of Commitment: The lack of clarity or buy-in prevents team members from making decisions they will stick to. Avoidance of Accountability: The need to avoid interpersonal discomfort prevents team members from holding one another accountable. 5. Inattention to Results: The pursuit of individual goals and personal status erodes the focus on collective success.
2.3 Five levels of conflict and resolution Level 5: World War (destroy the other, little or no language is changed) Level 4: Crusade (protecting one’s own group becomes the focus, language is ideological) Level 3: Contest (winning trumps resolving, language includes personal attacks) Level 2: Disagreement (personal protection, language is guarded and open to interpretation) Level 1: Problem to solve (information sharing and collaboration, language is open and fact based)
2.4 Developmental Mastery Model - Tuckman's Stages of Group Development According to Bruce Tuckman model, the typical stages team follow in their formation is: Forming, Storming, Norming and Performing.
Bruce Tuckman’s team development model provides a helpful explanation of how team develops and suggests the leadership appropriate at each stage. The model includes four basic stages that Tuckman refers to as forming, storming, norming, and performing.
Page 7
Some pages are omitted from this preview
Page 8
2.5 Developmental Mastery Model - Dreyfus Model The Dreyfus Model of Skill Acquisition has five levels:
The Dreyfus model of skill acquisition is suggested by brothers Stuart and Hubert Dreyfus in 1980. After examining highly skilled practitioners such as airline pilots and chess grand-masters, they identified five specific levels of understanding: Novice: A complete newbie. Novices want to get results fast, but have no experience to guide them in doing so. Advanced beginner: At this level, some experience has led to learning; you can break free from rules a little and try tasks on your own. But perception is still limited, and you’ll get stuck when things go wrong. Competent: This stage sees you with a mental model of the problem domain; you’ve mapped the knowledge base, have begun to associate its parts, and understand the relative importance of different aspects. This big picture view allows you to approach unknown problems and plan methodical routes into those problems, rather than diving in and hoping rules will get you to a solution. At this point, you actively seek out new rules to formulate a plan of attack, and begin to see the limitation of those rules. This is a good place to be. Proficient: Proficient people move beyond competency. They have a much better understanding of the big picture, and are frustrated with the simplifications that the novice needed. They can correct previous errors and reflect on their experiences to work better in the future. At this point you can also learn from other’s experiences and assimilate them into your body of understanding. Now it is easy to identify and focus only on the issues that really matter, confidently ignoring irrelevant details. Here we see the person has gained significant tacit knowledge—knowledge that’s hard to transfer by exposition, that is only gained by experience and deep understanding. Expert: This is the pinnacle of the learning tree. There are very few experts. They are authorities on a subject; they know it completely, and can use this skill interlinked with other skills. They can teach others (although they probably teach competent better than novices as there is less of a disconnect). Experts have intuition, so rather than needing rules, they naturally see an answer, even if they can’t articulate why it’s the best solution. Note that the Dreyfus model applies per skill. You may be an expert in a particular topic, and a complete notice in another.
Page 9
3. Agile Planning and Estimation
Planning onion Product Vision Agile Charter Product Road-map Story Mapping Release Planning
Cone of Uncertainty Level of Estimates Affinity Estimating Wideband Delphi Yesterday’s Weather
3.1 Planning Onion
Planning onion, coined by Mike Cohn, refers to the way planning is done in layers in Agile, with detail appropriate to the time horizon (the closer the release, the more detail that’s provided in planning; the further away the release, the higher the level of detail provided). Most Agile teams are concerned only with the three innermost levels of the planning. Release planning considers the user stories or themes that will be developed for a new release of a product or system. The goal of release planning is to determine the appropriate answer to the questions of scope, schedule, and resources for a project. Release planning occurs at the start of the project but is not an isolated effort. A good release plan is updated throughout the project (usually at the start of each iteration) so that it always reflects the current expectations about what will be included in the release. At the next level is iteration planning, which is conducted at the start of each iteration. Based on the work accomplished in the just-finished iteration, the product owner identifies high-priority work the team should address in the new iteration. Because we are looking at a closer horizon than with release planning, the components of the iteration plan can be smaller. During iteration planning, we talk about the tasks that will be needed to transform a feature request into working and tested software. Finally, there is daily planning. Most Agile teams use some form of daily stand-up meeting to coordinate work and synchronize daily efforts. Although it may seem excessive to consider this planning in the formal sense, teams definitely make, assess, and revise their plans during these meetings. During their daily meetings, teams constrain the planning horizon to be no further away than the next day, when they will meet again. Because of this, they focus on the planning of tasks and on coordinating the individual activities that lead up to the completion of a task. By planning across these three time horizons - release, iteration, and the day - Agile teams focus on what is visible and important to the plan they are creating.
Page 10
Some pages are omitted from this preview
Page 11
4. Scrum
Scrum Pillars Scrum Cycle Scrum Roles Scrum Artifacts
Product Backlog Grooming Definition of Done (DoD) Definition of Ready (DoR)
Scrum is a management framework for incremental product development using one or more cross-functional, selforganizing teams and provides a structure of roles, meeting, rules and artifacts.
The Scrum framework consists of Scrum teams and their associated roles, ceremonies, and artifacts. Each component within the framework serves a specific purpose and is essential to Scrum’s success and usage. 4.1 Scrum Pillars
Scrum is founded on empirical process control theory, or empiricism. Empiricism asserts that knowledge comes from experience and making decisions based on what is known. Scrum employs an iterative, incremental approach to optimize predictability and control risk. Three pillars uphold every implementation of empirical process control: TRANSPARENCY, INSPECTION and ADAPTATION.
Page 12
4.2 Scrum Cycle
Scrum Cycle
1. Product owner updates the requirements in the prioritized list, called product backlog 2. Team gets together for the sprint planning meeting and generate the sprint backlog. What will be done and how it will be done in this development cycle(Sprint) 3. The development team does the development work of the product increment that has been planned, aiming to meet the Sprint goals 4. Every day, the development team holds the daily scrum, a 15-minute meeting which aims to promote visibility and communication between team members. 5. At the end of the development cycle, the development team will have produced a product increment which is done, meaning value for the customer. 6. Then the development team meets the product owner and stakeholder for the sprint review and presents to them what was produced during the sprint 7. Right after the review meeting, the Scrum team holds the sprint retrospective, where it discusses what happened and what could be improved for future sprints. 8. And a new cycle starts until the final product is produced/project complete. 4.3 Scrum Roles
Page 13
Some pages are omitted from this preview
Page 14
5. Value Based Prioritization Techniques
ROI, NPV, & IRR Compliance Customer Value Relative Prioritization / Ranking
Minimum Viable Product (MVP) Minimal Marketable Feature (MMF) MoSCoW Kano Model
There are many opportunities to make decisions throughout a project’s lifecycle. Which are the best projects? What resources should we put on a project? Which task should I work on next? Value-based decisions need to be made throughout the life-cycle of a project, by everybody involved.
5.1 ROI, NPV and IRR ROI (Return on Investment) indicates financial return. A positive ROI means the project is profitable, higher the ROI, the better
ROI = (Projected Savings (benefits) - Costs) / Costs
NPV (Net Present Value): The net future cash flow (profit – expenditure) in terms of today’s value (adjusted for future inflation, etc.) A positive NPV means the project is profitable IRR (Internal Rate of Return) is a rate of return used in capital budgeting to measure and compare the profitability of investments. IRR consider interest rate of the investment; the higher IRR, the more profitable the project 5.2 Compliance Considering value prioritization, sometime project work is undertaken to conforming a rule, such as a specification, policy, standard or law (e.g. regulatory compliance) Compliance requirement can be internal or external to the organization:
Internal compliance example includes CMMI compliance and ISO 900X level compliance External compliance example includes Sarbanes Oxley Act, Basel II (Financial regulation), HIPAA (Information and health regulation) and ISO 27002 (Security practices)
5.3 Customer Value Deliver the highest value to the customers as early as possible. The backlog should be customer-valued prioritized while taking into accounts technical feasibilities, risks, dependencies, etc. 5.4 Relative Prioritization/Ranking Relative weighting is a prioritization approach that considers both the positive benefit of the presence of a feature and the negative impact of its absence Each theme or epic being considered for the next release is assessed in terms of the benefits it will bring if implemented and the penalty that will be incurred if it is not implemented.
Page 15
5.7 Scrum and XP Differences SCRUM
XP
DEFINITION
Sprint
Iteration
Fixed-length period of time (time-box)
Release
Small Release
Release to production
Sprint/Release Planning
Planning Game
Agile planning meetings
Product Owner
Customer
Business representative to project
Retrospective
Reflection
“Lessons learned�-style meeting
Scrum Master
Coach
Agile project manager
Development Team
Team
Empowered Cross-Functional team
Daily Scrum
Daily Stand-up
Brief daily status meeting
5.8 Test Driven Development
Test -> Code -> Refactor In Test Driven Development (TDD), a programmer writes a test before they write any code. The test fails and the programmer writes just enough code to make it pass. This cycle is repeated on timelines of every few minutes. 5.9 Acceptance Test Driven Development (ATDD)
Acceptance Test Driven Development (ATDD) is a practice in which the whole team collaboratively discusses acceptance criteria, with examples, and then distills them into a set of concrete acceptance tests before start the development.
Page 16
Some pages are omitted from this preview
Page 17
8. Kanban
Kanban Principles Class of Service
Scrum vs. Kanban
Kanban is a Japanese word that means "visual card" or "signboard." At Toyota, Kanban is the term used for the visual & physical signaling system that ties together the whole Lean production system. Kanban as used in Lean production is over a half-century old. It is being newly adapted to some disciplines such as software.
8.1 Kanban Principles Anderson identified five core properties that are part of each successful implementation of the Kanban method. 1. 2. 3. 4. 5.
Visualize the Workflow Work-in-Process Limit Manage Flow Make Process Policies Explicit Improve Collaboratively
Page 18
8.2 Class of Service
Classes of service are a powerful way to make your policies explicit around the service level for certain type of work. Assigning a class of service to a work item can influence the work item: visualization, prioritization, impact on WIP, and workflow. Classes of service help the team to self-organize around (Work selection and scheduling, Work distribution and Making sure the work capacity is distributed as decided) Common classes include
Urgent (or Expedite) - Prioritized over other work
Fixed Delivery Date - Needs to be completed on or before a certain date
Regular - Normal items, increasingly urgent, pulled FIFO-style
Defects - Rework produced by bad quality (you want as few of these as possible)
Intangible - No tangible business value now, but later: paying off technical debt
8.3 Scrum vs. Kanban SCRUM
KANBAN
Fixed time-boxes
No time-boxes
Tasks are Estimated
No Tasks Estimates (optional)
Track velocity
Track flow (Queues, WIP, Cycle time)
Scrum Master own the process
Team own the process
Cross-functional teams prescribed
Cross-functional teams optional. Specialist teams allowed
Cannot add items to ongoing Sprint
Can add new items whenever capacity is available
Prescribes roles (PO, SM, Team)
Doesn’t prescribe any roles
A Scrum board is reset between each sprint
A Kanban board is persistent
Page 19
9. Lean Software Development
What is Lean Lean Software Development Principles Just in Time (JIT)
Value Stream Mapping (VSM) Theory of Constraints (TOC) Kaizen
9.1 What is Lean “A production practice that considers the expenditure of resources for any goal other than the creation of value for the end customer to be wasteful, and thus a target for elimination.” Source: Wikipedia
Lean focuses on the elimination of waste in a process
9.2 Lean Software Development Principles Lean development is a translation of well-know and accepted lean manufacturing practices to the software development domain. Mary and Tom Poppendieck identify seven fundamental Lean principles: 1. 2. 3. 4. 5. 6. 7.
Eliminate Waste Optimize as whole Delivery fast Amplify learning Build Quality In Empower Team Defer decision
Lean focuses on the elimination of waste in a process. It is a production practice that considers the expenditure of resources for any goal other than the creation of value for the end customer to be wasteful, and thus a target for elimination.
Page 20
Some pages are omitted from this preview
Page 21
Some pages are omitted from this preview
Page 22
10. References 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59.
Manifesto for Agile Software Development Principles behind the Agile Manifesto from www.agilemanifesto.org PMI-ACP® Practitioner FAQs http://www.pmi.org/~/media/Files/PDF/Certification/PMI-ACP_Practitioner_FAQ_March2012.ashx An introduction to the Cynefin Framework by Dave Snowden http://cognitive-edge.com/ Cynefin Framework. https://en.wikipedia.org/wiki/Cynefin_Framework Essential Scrum: A Practical Guide to the Most Popular Agile Process, by: Kenneth S. Rubin Publisher: Addison-Wesley Professional. Integrating Agile Development in the Real World, by Peter Schuh, Published December 2nd 2004 by Cengage Learning. Adaptive Engineering of Large Software Projects with Distributed/Outsourced Teams by Jeff Sutherland, Anton Viktorov & Jack Blount, http://www.necsi.edu/events/iccs6/papers/ee6637fd0a1f958002d8f242162b.pdf Agile Principles and Values, by Jeff Sutherland, http://msdn.microsoft.com/en-us/library/dd997578(v=vs.100).aspx, accessed on May 02, 2013. Source: “The Agile Impact Report” http://media.rallydev.com/events/pdf/Agile-Impact-Report.pdf, accessed on July 11, 2013. “Hohe Mut Restaurant” Photo by Nicholas Durin, http://www.snow-forecast.com/resorts/Obergurgl/photos/11805, accessed on May 05, 2013. "Manifesto for Agile Software Development", http://www.agilemanifesto.org/ access on April 20, 2013. "Principles behind the Agile Manifesto", accessed on April 20, 2013, http://www.agilemanifesto.org/principles.html. Adaptive Engineering of Large Software Projects with Distributed/Outsourced Teams by Jeff Sutherland, Anton Viktorov & Jack Blount. Source: Agile Project Management: Creating Innovative Products, Second Edition By: Jim Highsmith Publisher: Addison-Wesley Professional Agile Estimating and planning, by: Mike Cohn, publisher: Prentice Hall Pub. Date: November 01, 2005 Moore, Geoffrey A. Crossing the Chasm: Marketing and Selling High-Tech Products to Mainstream Customers. New York: HarperBusiness, 1991. “How To Make Your Project Not Suck by Using an Agile Project Charter” by Michael Lant, http://michaellant.com/2010/05/18/how-to-make-your-project-not-suck/ Story Maps, Jeff Patton, http://www.AgileProductDesign.com. "The Scrum Guide, the definitive guide to scrum: The rules of the game" by Ken Schwaber and Jeff Sutherland Extreme Programming Explained, Kent Beck (Addison Wesley 2000). The Art of Agile Development, James Shore and Shane Warden, 2008 O’Reilly Media, Inc. Extreme Programming Explained: Embrace Change, Second Edition by Kent Beck, Addison-Wesley Professional. Extreme Programming Explained 1st Edition by Kent Beck, 1999 Jeffries, Ron. “Essential XP: Card, Conversation, and Confirmation.” XP Magazine (August 30, 2001). User Stories Applied: For Agile Software Development, by Mike Cohn, Publisher: Addison-Wesley Professional. INVEST in Good Stories, and SMART Tasks, Bill Wake http://xp123.com/articles/invest-in-good-stories-and-smart-tasks. "The Scrum Guide, the definitive guide to scrum: The rules of the game" by Ken Schwaber and Jeff Sutherland User Stories, Epics and Themes by Mike Cohn, accessed on July 10, 2013, http://www.mountaingoatsoftware.com/blog/stories-epics-and-themes. Essential Scrum: A Practical Guide to the Most Popular Agile Process, by: Kenneth S. Rubin Publisher: Addison-Wesley Professional. Lean-Agile Software Development: Achieving Enterprise Agility By: Alan Shallowly; Guy Beaver; James R. Trott, Publisher: Addison-Wesley Professional, 2009 Essential Scrum: A Practical Guide to the Most Popular Agile Process, by: Kenneth S. Rubin Publisher: Addison-Wesley Professional. Problem detection and resolution, PMI-ACP exam prep by Mike Griffiths Kanban vs Scrum, A practical Guide by Henrik Kniberg, accessed on December 09, 2014, http://www.slideshare.net/ RossC0/kanban-vs-scrum In 1981, Barry Boehm drew the first version of what Steve McConnell (1998) later called the “cone of uncertainty.” Agile Estimating and Planning by Mike Cohn, Prentice Hall, 2005. Source: http://www.gettingagile.com/2008/07/04/affinity-estimating-a-how-to/, accessed on June 22, 2013. Agile modeling, Scott Ambler, Source: http://www.agilemodeling.com. Photo Source: http://www.xconomy.com/national/2013/03/08/what-makes-an-app-awesome-a-case-study-with-mokriya-craigslist. Agile Testing: A Practical Guide for Testers and Agile Teams, by: Lisa Crispin; Janet Gregory Publisher: Addison-Wesley Professional Agile testing, Google tech talks, http://youtu.be/bqrOnIECCSg, accessed on May 3, 2013 Agile testing, nine principles and six concrete practices for Testing on Agile Teams, Elisabeth Hendrickson Test-driven development concepts, taxonomy, and future direction, Janzen, D. and Saiedian, H., 2005. Derby, E., & Diana, L. (2006). Agile retrospective: Making good team great. Dallas, Texas: The Pragmatic Bookself. The Power of Retrospectives, accessed on July 12, 2013 http://www.kruchten.org/agilevancouver/presentation_slides/Retrospective.pdf Ries, Eric (August 3, 2009). "Minimum Viable Product: a guide". 2. Wikipedia PM network magazine December, 2012 by Matt Alderton. Earned value and Agile reporting by Anthony Cabri, Mike Griffiths, Quadrus development Inc. What is risk management, PMBOK 5th Edition and Managing Successful projects with PRINCE2 "The Software Project Manager’s Bridge to Agility" by Michele Sliger, Stacia Broderick Osmotic communication, Alistair Cockburn, source: http://alistair.cockburn.us/Osmotic+communication Value stream mapping: Lean-Agile Software Development: Achieving Enterprise Agility By: Alan Shalloway; Guy Beaver; James R. Trott Shu H Ri, Martin Fowler http://martinfowler.com/bliki/ShuHaRi.html Evaluation of Agile triangle, Agile Project Management: Creating Innovative Products, Second Edition By: Jim Highsmith Publisher: Addison-Wesley Professional Agile modeling, Scott Ambler, Source: http://www.agilemodeling.com/ Wireframe photo Source: http://www.xconomy.com/national/2013/03/08/what-makes-an-app-awesome-a-case-study-with-mokriya-craigslist/ Adaptive leadership: 1. Heifetz, Grashow & Linsky (2009). The practice of adaptive leadership: Tools and tactics for changing your organization and the world. USA: Harvard Business Review Press. Adaptive leadership: 2. Heifetz& Laurie (2003). The leader as teacher: creating the learning organization. Ivey Business Journal: Improving the practice of management, p. 1-9. Adaptive leadership: 3. Obolensky (2009). Complex adaptive leadership: embracing paradox and uncertainty. Gower Publication Company Yesterday’s weather, Martin Fowler, http://martinfowler.com/bliki/YesterdaysWeather.html Innovation Games: Creating Breakthrough Products Through Collaborative Play by Luke Hohmann Published by Addison-Wesley Professional, 2006
Page 23