lookingglassdev.com · table of contents pmi—acp exam preparation student guide v10.2 ©2020...

Table of Contents

PMI—ACP Exam Preparation Student Guide v10.2 ©2020 Looking Glass Development

i

PMI-ACP® Examination Preparation Part Number: LGdACP10.2 Course Edition: 10.2 PMI ID: 1384-ACP01 ISBN: 978-0-9837564-3-9

Notices Disclaimer: While Looking Glass Development takes care to ensure the accuracy and quality of these materials, we cannot guarantee their accuracy, and all materials are provided without any warranty whatsoever, including, but not limited to, the implied warranties of merchantability or fitness for a particular purpose. The names used in the exercises are fictitious. Any resemblance to current people or organizations is purely coincidental. LGd is an independent provider of integrated training and consulting solutions for individuals, businesses, educational institutions, and government agencies. Use of screenshots, photographs, or other representations of another entity’s product or service in this book is for editorial purposes only. No such use should be construed to imply sponsorship or endorsement of the book by, nor any affiliation of such entity with Looking Glass Development. This courseware may contain links to sites on the Internet that are owned and operated by third parties (the “External Sites”). Looking Glass Development is not responsible for the availability of, or the content located on or through, any External Site.

Trademark Notices: Looking Glass Development, LGd and the LGd logo are trademarks of Looking Glass Development.

Copyright © 2018 Looking Glass Development, LLC. All rights reserved. Screenshots, photographs and other representations used for illustrative purposes are the property of the software proprietor. This publication, or any part thereof, may not be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording, storage in an information retrieval system, or otherwise, without express written permission of Looking Glass Development, LLC 685 Briar Dale Dr. Castle Pines, CO. 80108 (303) 883-3917.

This book conveys no rights in the software or other products about which it was written; all use or licensing of such software or other products is the responsibility of the user according to terms and conditions of the owner. Do not make illegal copies of books or software. If you believe that this book, related materials, or any other Looking Glass Development materials are being reproduced or transmitted without permission, please call 1-303-883-3917.

Contact Information: Looking Glass Development, LLC

685 Briar Dale Dr. Castle Pines, CO 80108 Telephone:(303) 883-3917

Printed in the United States of America

Table of Contents


ii

Table of Contents 1. Introduction …………………………………………………………….……………………..1 Student Guide Overview ……………………………………………...………….………1

Course Expectations………………………………………..……………………………..2 2. The Process ..….………………………………...………...………………………..………….5

The Application Process …………………………………………………..………...…...5 The PMI-ACP Qualifications ……………………………………………………..……..7 PMI-ACP Application Audits …………………………………..……………………….8 Scheduling / Rescheduling Your Exam …………………………………….…………...9 Exam Fees …………………………………………………………………….………..10 Exercise 1—Introduction & Process Quiz ……………………….……………...……..11

3. The Exam …………………………………………………………….………………………14 Exam Overview ………………………………………………………………………..14 Exam Results …………………………………………………………………………..14 Exam Design …………………………………………………………………………..14 Arriving At The Testing Center ……………………………………………………….15 Exam Breakdown ……………………………………………………………………...16 Key Reading …………………………………………………………………………...18 Domain Breakdown ……………………………………………………………………20 Test Taking Strategies ………………………………………………………………....21 Exercise 2—The Exam Quiz ………………………...…………………………………23

4. Agile Principles & Mindset Part I ……………………………..……………………………26 Principles & Mindset Overview …………………………...…………………………..26 Domain Tasks ………………………………………...………………………………..26 PMBOK Guide® vs. Agile ……………………………...……………………………...27 General Agile Concepts ……………………………...………………………………...34 Agile History …………………………………………..…………………………….…36 The Heartbeat of Agility ………………….……………..……………………………..42 Musts, Wants, & Needs ………….……………………….……………………………42 Key Terms ……………………………………………………………………………..43

Agile Methodologies ……………………………………………………………….…..44 Scrum …………………………………………………………………………………..44 Scrum Roles ……………………………………………………………………………46 Scrum Artifacts ………………………………………………………………….……. 48 Scrum Process ……………………………………………………………..………….. 51 Extreme Programming …………………………………………………………………55 Feature-Driven Development ……………………………………………………….….61 Exercise 3—Agile Principles & Mindset Part I Quiz …………….…………………….67

5. Agile Principles & Mindset Part II …………………………………………………………92 Dynamic Systems Development Method ……………………………………………...92 Crystal Development ……………………………………………………………...… 107 Lean Software Development …………………………………...…………………….110 Kanban ………………………………………………………………………………..116 Test Your Assumptions ……………………………………………………………….119 Scaling Agile ………………………………………………………………...………. 121 SAFe ……………………………………………………………………………….….121 Nexus ………………………………………………………………………………….126 LeSS …………………………………………………………………………………..129 Disciplined Agile Delivery (DAD) ……………………………………………….…. 130 Scrum of Scrums ……………………………………………………………….……. 134 The PMO ………………………………………………………………………..…….134 What is the Perfect Structure? ………………………………………………….……..135 Organic or Simple Organizations ……………………………………………...…….. 137 Functional Organizations …………………………………………………………….. 137 Projectized Organizations ……………...…………………………………………….. 140

Table of Contents


iii

Matrix Organizations ……………………………….………………………………...142 A Weak Matrix Organization ……………………………………………………….. 142 A Balanced Matrix Organization ……………………………………………………. 143 A Strong Matrix Organization ………………………………………………………..144 Matrix Organization Advantages ……………………………………………………. 144 Matrix Organization Issues …………………………………………………..……….145 Virtual / Hybrids / PMOs ………………………………………………...…………. 146 Exercise 4—Agile Principles & Mindset Part II Quiz …………..….…………….…..148

6. Value Driven Delivery ……………………………………………………………………...168 Value Driven Delivery Overview …………………………………………………….168 Assessing Business Value …………………….………………………………………169 The Charter & Value …………………….……………………………………………171 Value Stream Mapping ……………………….………………………………………172 Prioritization ……………………….…………………………………………………174 Story Maps ………………………….………………………………………………...177 Risk ……………………………….…………………………………………………..178 PDCA ……………………….………………………………………………………...181 Expected Monetary Value & Decision Trees …………..……………………………..182 Exercise 5—Expected Monetary Value & Decision Trees Quiz ………….…..……….185 Agile Contracting …………..………………………………………………………….189 Odds & Ends of Value Driven Delivery …..…………………………………………..190 Earned Value Management …………………..………………………………………..191 Earned Value Forecasting ……………………..………………………………………195 Exercise 6—Earned Value Quiz ………………...……………………………………..199 Other Agile Tracking Tools …………………...……………………………………….202 Exercise 7—Value Driven Delivery Quiz ………………………………………………205

7. Stakeholder Engagement …………………………………………………………………..215 Stakeholder Engagement Overview …………………………………………………215 Stakeholder Engagement Domain Tasks …………………………………………….215 Defining Stakeholders ……………………………………………………………….216 Wireframes …………………………………………………………………………..217 Personas …………………………………………….………………………………..217 User Stories ………………………………………………………………………….219 Definition of Done …………………………………………………………………..221 F2F …………………………………………………………………………………..223 Information Radiators ……………………………………………………………….223 Agile Modeling ……………………………………………………………………...223 Use Cases ……………………………………………………………………………225 Other Tools ………………………………………………………………………….228 Conflict Resolution ………………………………………………………………….230 Participatory Decision Models ……………………………………………………...231 Management vs. Leadership ………………………………………………………...232 Servant Leadership ………………………………………………………………….233 12 Principles for Leading Agile Projects ……………………………………………233 Exercise 8—Stakeholder Engagement Quiz ………………………………………...236

8. Boosting Team Performance ………………………………………………………………248 Team Performance Overview ……………………………………………………….248 COCOMO ………………….………………………………………………………..249 Adaptive Leadership …………….…………………………………………………..251 Purpose Alignment Model …….…………………………………………………….252 The Short-Horizon Model …….……………………………………………………..253 The OODA Loop Model …….………………………………………………………253 Satir Change Model …………………………………………………………………253 Tuckman Model ……………………………………………………….…………….254 Leadership & Interpersonal Skills ………………………….……………………….256 Sources of Power …………………………………………………………………....257 Emotional Intelligence ………….…………………………………………………...258

Table of Contents


iv

Empowered Teams …………….…………………………………………………….263 High Performance Teams ……….…………………………………………………...264 The Five Dysfunctions of a Team ………..…………………………………………..264 The Daily Scrum …………………………..…………………………………………267 One-on-One Coaching & Mentoring …….….……………………………………….269 Brainstorming Techniques …………….…………………………………………….270 Additional Terms ……………….……….…………………………………………...271 Exercise 9—Team Performance Quiz ………..………………………………………274

9. Adaptive Planning ………………………………………………………………………….288 Adaptive Planning Overview ………..……………………………………………….288 Adaptive Planning Core Concepts …..……………………………………………….289 The Agile Pyramids …………………..……………………………………………...290 Value-Based Analysis ……………..………………………….……………………...292 Agile Games ………………..……………………………………….………………..293 Agile Estimation ……..………………………….……………………………………295 Project Delays …………...……………………………………………………………298 Planning Differences ………..………………………………………………………..301 Exercise 10—Adaptive Planning Quiz ……...………………………………………...302

10. Problem Detection & Resolution …………………………………………………………..310 Problem Detection & Resolution Overview……………..….………………………...310 Key Concepts ………………………………………...……………………………….310 Failure Modes & Alternatives …………………...……………………………………312 Control Charts ………………………………...………………………………………313 Continuous Integration ……………………...………………………………………...314 Risk-Based Spike ……………………...……………………………………………...315 Test Driven Development ……………...……………………………………………..315 Refactoring ……………………….…..……………………………………………….318 The Design Stamina Hypothesis ……………...………………………………………320 Problem Solving ………….………...…………………………………………………322 Exercise 11—Problem Detection & Resolution Quiz ……...…..……………………...329

11. Continuous Improvement ………………………………………………………………….341 Continuous Improvement Overview ……………...…………………….…………….341 Retrospectives Are Key ………………………...…………………………………….341 Retrospectives Steps ……………………………...…………………………………..342 Pre-Mortem ………………………………..…….…………………………………...344 Exercise 12—Continuous Improvement Quiz ………...….…………………………...346

12. Presentation…………………………………………………………………………………351

Chapter 1 — Introduction


Page 1

Slide 2

Page 1

Course Introduction Student Guide Overview This student guide is designed as the primary written manual for the 2018 edition of the PMI-ACP Exam Preparation Course. Throughout the guide, we will call out major points in the sidebar to improve learning. We have created several indicators to highlight exactly what type of information the comment provides. These indicators include the following:

TIPS — Key Agile tips to help ensure that your preparation for the PMI-ACP® Exam stays on track.

WARNINGS — Major pitfalls that often cause candidates to fail the exam.

FORMULAS—Major formulas or calculations used in the practice of Agile Development.

EXERCISES — Course exercises to be completed by the candidate. These exercises serve two purposes: First, they reinforce learning found in the chapter. Second, they simulate exam questions.

INFORMATION — Quick points of general information about Agile Development. These are often practice tips.

COURSE REFERENCE — Denotes the page of corresponding material in either the live course presentation or the online videos.

This course is divided into nine chapters when taught live and ten chapters when taught virtually. The live course is designed to last three days. However, a student should expect to take significantly longer when completing the course virtually. The live, instructor-led course is registered with PMI as a 21 Contact Hour or Professional Development Unit (PDU) Course. To determine how many Contact Hours your course provides please contact your provider. The chapters are designed to take participants through all the information. This manual combines what appears as two chapters in the online course. The course chapters include: Chapter 1 The Process — This chapter examines the process of applying and

scheduling the exam.

Chapter 2 The Exam — This chapter reviews how the test is put together, the required passing score, and other specifics of the test itself.

Chapter 3 The Agile Principles & Mindset — This is the largest and most difficult of the chapters. In the online course it is broken into two separate chapters because it is so large. It introduces the foundations of Agile Development along with each of the major Agile methodologies or frameworks.



Page 2

Chapter 4 Value Driven Delivery — This chapter focuses on how a team ensures they are delivering the “right” functionality for the business.

Chapter 5 Stakeholder Engagement — Many traditional methodologies struggle because they fail to fully and consistently engage stakeholders. Agile addresses this with a heavy focus on full stakeholder engagement, and chapter 5 explores how to achieve this in detail.

Chapter 6 Boosting Team Performance — This chapter focuses on how to get the most out of the team to deliver business results.

Chapter 7 Adaptive Planning — In Agile Development, planning is a constant process. Learning how to structure that process and do it with forethought is key and this chapter explores how this is done in detail.

Chapter 8 Problem Detection and Resolution — This chapter focuses on determining what is going right and wrong in a project. Agile Development pays special attention to this area since it is key to the success of any project.

Chapter 9 Continuous Improvement — No matter which set of practices are used to execute a project, it will never be perfect. That is why the team and organization must constantly work to get better. This chapter focuses on how this is done in detail.

Course Expectations Welcome to the world of Agile Development! Today, Agile is one of the hottest topics of discussion throughout the world of project management. However, many believe it is just something for Information Technology. Let’s be clear. It is NOT. The skills, tools, and techniques found in Agile Development should be used by almost every team in every organization. The course is specifically designed to prepare candidates for the Project Management Institute’s Agile Certified Professional (PMI-ACP®) exam. If you are looking for a course to teach you the basics of Agile, Scrum, XP or any other specific Agile framework or methodology this is not the course for you. Within the Agile space, there are a number of certifications you can obtain. Organizations such as Scrum.org or the Scrum Alliance represent the best known Agile specific groups. These, and several others offer a wide range of certifications you can obtain. Probably the best known of these is the Certified Scrum Master or CSM, offered by the Scrum Alliance. This exam requires candidates to take a two-day fundamental Scrum course and then complete an online exam. The Alliance’s Certified Scrum Professional, or CSP, represents a more robust certification completed at a testing center, and Scrum.org offers a similar model. Their junior credential is the Professional Scrum Master I. Scrum.org’s level II exam is different in that it is a timed essay exam graded by one of the founders of Scrum. It represents a more advanced credential.



Page 3

The best source of information on the PMI-ACP Exam is

PMI’s website

Make sure you are scoring at least 90% on all

practice exams before you attempt the real test.

The other Agile certifications available are different from the PMI-ACP® exam in a number of ways. First and most importantly, all the other Agile certifications focus on a single framework or methodology. In contrast, the ACP requires candidates to know a number of frameworks or methodologies including Scrum, Extreme Programming, Crystal, Lean, Kanban, Feature Driven Development, Dynamic Systems Development and a few others. Although most of these methodologies share common elements, there are differences that must be learned. The second difference between this and other certifications is that the ACP requires candidates to prove experience in the field by both working on projects and working in the field of Agile. The third difference is that the test is constructed very differently. In most of the other Agile certification courses the test surveys the writings of major thought leaders and the test is written by subject matter experts. PMI® on the other hand, constructs their exams by first conducting a Role Delineation Study and then makes use of PhD experts in exam design. The Role Delineation Study is a social science survey tool given to thousands of practitioners to find out what is most commonly being done in the field, and then combining that knowledge with the latest writing from thought leaders. This model provides a much more systematic approach and is considered an industry best practice. To get more information concerning the exam directly from PMI® visit: http://www.pmi.org/certification/agile-management-acp.aspx. We highly recommended that you take the time to visit PMI’s website, download the multiple PDFs you will find there for the ACP, and take the 30-minutes to an hour it requires to review them. The best way for you to learn what the ACP is all about is to learn it directly from PMI®. Once you have done that, continue with your course and you will feel a lot more comfortable with the topics discussed. This brings us to the next issue. How should you proceed through this course? This manual was written hand-in-hand with both the live course presentation and the online videos used for that delivery channel. This means two things to you. First, you will receive the same instruction regardless of the channel you have chosen to use in preparation for the PMI-ACP Exam. Second, just listening to the lectures is not enough, regardless of channel. So be careful! It is important that you also read the manual and take the practice exams — but it is not enough to just take the exams. To ensure you are ready for the real test, you must pass each exam with a score of at least 90%. Why 90%? It is simple, really. When it’s time for the real exam most people feel a lot of stress and pressure. It is pretty easy to understand if you stop and think about it. After all, you have spent a lot of time and money preparing for the exam. The last thing you want is for that money to go to waste — which is exactly what happens if you fail the exam. The actual passing score for the test is much lower than 90%, but you need room for the additional errors that will naturally come from the extra stress you experience at the time of taking the exam. To ensure you have that margin of error, take and retake the chapter quizzes until you achieve the 90% minimum target score on each.



Page 4

The best way to succeed through this course is to listen to the lecture in whatever form it is delivered, read the chapter, and then — and only then — attempt the quizzes. This process works very well, especially in the self-paced modality of online learning. However, the live environment limits this somewhat because we want students who have the live instructor to be able to ask questions about the quizzes. This means you must read the manual on your own after the course. Finally, let’s discuss the structure of the quizzes and their content since there is often a lot of confusion about this. No PMI-ACP® exam preparation course has access to the real test. This means that every exam preparation course has the same problem: How do we simulate a test we do not have access to? The answer is the same for all test prep providers. We are not allowed to ask past test takers for questions, but we are allowed to ask students how well our course prepared them for the exam. This helps as we revise a course, but does not help in the initial writing. In the initial stages therefore, we review the exam specification documents provided to all Registered Education Providers or REPs along with the suggested readings. We combine this test-specific information with knowledge of how PMI® writes these exams and with our experience in standardized testing. At the end of the day, it is this knowledge — along with our knowledge of Agile —that you are really paying for. As always, should you have questions feel free to contact your course provider and we will do our best to assist you in any way we can.

Chapter 2 — The Process


Page 5

Slide 4

Page 5

The Process The Application Process Like many standardized exams, there is a requirement that you apply for the PMI-ACP® certification before you can sit for the test. This process takes time and often confuses candidates. The best thing you can do to avoid confusion is to read through the PMI-ACP® Candidate Handbook from PMI’s website. It also a good idea to at least review the other documents provided since it is best to obtain information about the course directly from PMI®. Once you have reviewed those documents you are ready to begin the application process.

The first thing you must do is decide the best way for you to apply. You can complete the application the old fashioned way, by writing everything out using the provided forms in the Handbook. Or you can complete the application online. We recommend completing the application online for the vast majority of candidates because it is easier, more convenient, and will provide faster results. Additionally, you are not required to complete the application in one sitting. You can start and save your work for up to 90-days from the date you begin the application.

If you choose to mail in your application, send it to PMI’s Global Operations Center at 14 Campus Blvd. Newtown Square, PA. 19073-3299. If you have questions about your application you can contact Customer Care at 1-855-746-4849.

To apply online, being by visiting PMI’s website and going to the PMI-ACP® Certification page at http://www.pmi.org/certification/agile-management-acp.aspx. Once there, select the Apply Now button that appears at the top of the page. If you are already a PMI® member you can enter your username and password. Otherwise create a new account using the Create Account button. This will take you to the certification program root page where you can apply for all PMI’s credentials. Scroll down the list until you locate the link to Apply for PMI-ACP® credential and click on the title. The next screen will ask you for your address. If you already have a work and home address in the system, they will automatically appear. If not, provide both addresses. You can also quickly make any required changes to this information as needed before selecting the Save and Continue button on the bottom right.

The next screen covers your contact information. This includes email address(es), fax numbers, and pertinent phone numbers. Once complete, again select the Save and Continue. This will take you to the education screen. Unlike the PMP® Certification, the PMI-ACP® does not create differing candidate requirements based on the highest degree a candidate has obtained. However, PMI does still collect this information. As always, make sure you do not exaggerate your educational qualifications. You can then again hit the Save and Continue button which will place you on the PMI-ACP® requirements overview page. This page highlights two key requirements necessary to sit for the exam: Agile project experience, and Agile specific project education. This page is simply



Page 6

Make sure to describe your experience

using the language of PMI®.

informational and does not require you to complete anything before selecting Save and Continue.

The next screen is called the eligibility worksheet. This is the most important part of the application. It is divided into two sections, Agile Project Experience and Agile Education. The initial screen for this section provides an overview of the two categories including a summary of your combined qualifications. Between the summary table on the top and the two orange buttons on the bottom are text links for the Agile Project Experience and Agile Education. Begin completing the Eligibility Worksheet by selecting and completing your Agile Project Experience. This area contains several screens that are used to ensure that PMI® understands what you did during the project that would allow you to claim it towards your PMI-ACP® requirements. A few of the screens appear redundant but be careful, they are not. Pay special attention to the large text area box on the last screen for each project. Make sure you provide enough detail USING PMI’S AGILE TERMINOLOGY when describing your role for the specific project.

A key to successfully getting through this application process is making sure you are documenting your experience in a way that the reviewer understands. Doing that requires that you understand who the reviewers are. These people are NOT agilists or project managers. Most are temporary employees of PMI® who have received a couple of weeks of training for the job of reviewing these applications. Every day they are tasked with reviewing dozens of these applications. To say it is not a glamourous job is an understatement. You want to make it as easy as possible for them to approve your application. Do this by providing as complete of a picture as you can of your experience, but make sure to also use language they will understand and not the language your organization uses to describe the work. Remember, they do not work at your firm.

Once you have completed the requirements section and have selected the Save and Continue button you will see two optional questions concerning why you are taking the exam and whether or not a PMI® chapter has helped you prepare. These are completely optional, but answering them helps PMI improve its certification and educational programming. After the optional information, you will be asked how you want your name to appear on your certificate. This can be very important for those who use a name other than their legal name in their professional life. Make sure to take a quick second to double check that it is exactly how you want it to appear. In the end, if the name on the certificate looks different that you wanted or expected, there will be no one to blame but yourself — especially since the next page provides a secondary confirmation of the name.

When you select the Save and Continue button on the second certificate page you will be brought to PMI’s Agreement. You knew the lawyers had to get involved somewhere, right? Well, this is it. I know it looks like a bunch of dry, boring legalese, but please take the time to read it. At the bottom, on the left, is a checkbox stating you agree to all the conditions and rules set forth in the agreement. Hopefully it makes a lot of sense to you that you should read every legal document requiring your agreement.



Page 7

Slide 5

Finally, after checking the I Agree box and clicking Save and Continue one last time, you are brought to the final application screen. This is the review and submit page. It shows the status of each of the subsections of the application. If you have done it correctly, it will show “Completed” with a green checkmark on the left side in the Status column for each. If it doesn’t, click on the incomplete section and either correct it or add the necessary information before returning to this page. If it shows all green, go ahead and check the box at the bottom where you attest that “All information that I have provided is accurate and complete.” before selecting the Submit Application button in the lower right-hand column. This last click will cause a popup to appear telling you that “All application information is final.” and asking if you want to continue. Simply click the OK button. If you do not see this screen make sure you do not have popups blocked because this will prevent you from successfully completing the application process. If everything works as designed, you will see a screen that confirms that the application has been submitted successfully and lets you know that PMI® will review the application and notify you by email or post of the results. That’s it. You have successfully completed PMI’s Agile Certified Professional Application process. Now you just have to complete your preparation.

In PMI’s documentation, they state that the application completeness review can take up to ten business days when completed online and 30-days when completed manually and mailed. This is yet another major reason to complete the application through the website instead of mailing a paper copy.

Many candidates want to continue with the process after they complete their application. They do this by attempting to schedule the exam immediately. PMI® does not allow this. You cannot complete the applicant payment process for the exam until the completeness review is finished, and you cannot sit for the exam until it has been paid for. If you submitted your application using the online process, PMI® will normally get back to you within five to ten days. If you are approved you can immediately pay the exam fee at that point and schedule your exam.

Before we go further in our discussion of the process, let’s step back for a moment and ensure you are familiar with the Qualifications required to become a PMI-ACP® certificate holder.

The PMI-ACP® Qualifications PMI® breaks down the qualifications for the Agile Certified Professional designation into four categories. First, is general education. PMI requires applicants for the PMI-ACP certificate to hold a high school diploma and an associates degree or an equivalent. There is no advantage for those candidates who hold higher degrees such as a bachelor’s, master’s or a doctorate degree. The second category of qualification is a candidate’s general project experience. For the PMI-ACP certificate, candidates are required to have 2,000 hours (12 months) of experience working on projects in the last five years. These hours must be non-overlapping. This means a candidate cannot list hours for multiple projects over the same time period. Many consultants find this requirement initially difficult as



Page 8

they are often assigned to multiple clients at the same time. In those situations, I recommend compressing the start and end dates to prevent overlap. Make sure that you do not exaggerate the hours you worked, but it is not the end of the world if you shave a month or two of beginning and ending dates to prevent confusion. If you already hold a PMP® or PgMP® designation, you are not required to prove your general project management experience since both those designations have significantly larger and more robust project management experience requirements. The third category of qualification is that you must prove 1,500 hours, or eight (8) months, of Agile project experience. This means you must be able to show that you have almost a full year of experience using agile methodologies in the last three (3) years and this must be separate from your 2,000 hours of general project management experience. Be careful with this requirement because it does NOT say you must be a ScrumMaster, Agile Coach or any other title. It only requires that you have spent almost a full year beyond the hours you have spent on other projects as a member of an Agile team. The fourth category of qualification is that you must be able to show 21 hours of training in Agile practices. PMI® refers to these hours as Contact Hours and they differentiate between Contact Hours and Professional Development Units or PDUs.

Contact Hours represent hours of face-time in front of an instructor where you are taught about a particular topic, in this case Agile Development. Generally, most training organizations use a six to eight hour training day. This means that in most instances a single day course will count for between six and eight Contact Hours. We use the mid-point for most training, so our courses typically count for seven Contact Hours per day. A Professional Development Unit represents a measure towards PMI’s continuing education requirements mandated for those who are already certified. These PDUs can be claimed for a number of activities beyond just education, and here is where it gets confusing. All Contact Hours translate to PDUs but not all activities used for PDUs count as Contact Hours. Just remember that before you are certified you need Contact Hours and after you are certified you care about PDUs to maintain your certification. The number of PDUs required over the renewal period varies by certification.

PMI-ACP Application Audits Not every qualified applicant is approved by PMI® upon submitting their documentation. Some candidates are required to take a few extra steps as part of PMI’s application audit process. Like many best-in-class certification processes, PMI® establishes random checks throughout their process. PMI’s goal is to establish a verification process that gives every confidence that only qualified candidates are allowed to sit for the exam. Part of that audit process is collecting more detailed examination about some candidate’s qualifications. The first way candidates find themselves in the audit pool is by misstating their qualifications in a way that raises suspicions about its accuracy. Another way to find yourself in the audit pool is by providing a description of your work that uses a large amount of industry or organization-specific terminology that is not understood by the reviewer. Remember, these people are not professional project managers, they are reviewers. Part of their job is getting through as many applications in a day they



Page 9

Slide 6

can. Taking a significant amount of time to research the terminology found on a single application isn’t likely to happen when there are 20 other applications to review. When that occurs, it is much easier to simply throw the application in the audit pile and let a more experienced reviewer look it over once the candidate provides more extensive documentation. As a candidate, the phrase “more extensive documentation” should make you nervous. It means a lot of work because you will need to go back and get physical evidence for everything you claimed in your application. For example, you may have to go to your university or college’s registrar’s office for official proof of graduation because simply photocopying your diploma will not be enough. Or, the reviewer may call every person you listed on the experience portion of the application for verification. There are several other examples I could mention but won’t. The key is to not give the initial reviewer any excuse to put your application in the audit pile. Make it easy for them to approve you by providing accurate, truthful, information about your experience, and be sure to use terminology they understand.

However, even if you do everything right there is still a chance that your application could end up in the audit pile. This happens because PMI’s process requires a certain percentage of applications to be audited. It would be great if all the audits were for candidates who provided inaccurate or questionable information, but that usually doesn’t happen. As a general rule, you can assume that two candidates out of 30 will be required to provide additional information. If you find yourself in the audit process you will be given 90-days to collect the requested information and submit it to PMI. Once the information is received, PMI® will respond back to you in five (5) to seven (7) days.

Scheduling / Rescheduling Your Exam PMI® does not administer the ACP® or any other of its exams directly. Instead, it contracts out this task to organizations who specialize in it. In the United States and many other countries PearsonVue holds the contract to administer PMI® tests. Begin by going to the PearsonVue’s website at https://home.pearsonvue.com/pmi. Once there, you can schedule your exam, reschedule or cancel a test or just locate the nearest testing center. It is a good idea to make sure you know where the nearest testing center is located before you ever attempt to schedule the exam so you can prepare for driving or scheduling issues. The site also has links to a number of exam preparation tools such as the candidate handbooks. Should you have any issues scheduling your exam, you can contact PearsonVue directly at 866-241-5527. It is important to note however, that you will not be allowed to schedule your exam and pay your examination fee until you receive the formal acceptance from PMI® regarding your application. The process of scheduling the exam requires you to provide what is called a PMI Eligibility ID and confirm your email address is in the Prometric system. Without these two items you will not be allowed to sit for or schedule the exam.

Should you find you find yourself in a situation where you must reschedule or cancel your exam, there are some important facts that you need to know. It is possible to reschedule or cancel your exam within 30-days of your scheduled



Page 10

Slide 7

Slide 8

appointment, however you will incur a $70 charge. If you cancel your exam within two-days of your appointment, you will forfeit your entire exam fee. Should you need to reschedule a cancelled exam you will be required to submit a re-exam fee. There are some “extenuating circumstances,” however, which will not incur these fees. They include:

Medical emergency Military deployment Death in immediate

family Illness in immediate

family Natural disaster

Please note that work-related emergencies are not considered to be “extenuating circumstances.” Additionally, the date that you sit for the exam must still be within the allowed one-year eligibility period. This date can be found in your acceptance email or letter. You are required to sit for your exam within one-year of the date on the communique.

Exam Fees PMI makes every effort to get people to join the organization. To that end, the fees are significantly lower for PMI members than they are for non-members. Each candidate is eligible to take the exam up to three (3) times within their one year eligibility window. Should a candidate not receive a passing score within those three attempts, they are required to suspend attempts for a year before trying to complete the exam again. Additionally, PMI charges differing amounts for first attempts and all others. The exam fees are as follows:

1st Take Fees PMI Members: $435 Non-PMI Members $495

Retakes PMI Members: $335 Non-PMI Members: 395

If a candidate pays their exam fee but never schedules or takes the exam within the one year period a candidate can receive a $200 refund.



Page 11

Exercise 1—Introduction

Introduction & Process Quiz 1. How much time do you have to complete your application once started?

A. 30 Days B. 45 Days C. 60 Days D. 90 Days

2. How much time (on average) will PMI® take to review your application once submitted?

A. 5 Days B. 10 Days C. 15 Days D. 20 Days

3. How many days do you have to provide requested additional information if you are audited?

A. As much time as needed B. 45 Days C. 90 Days D. 120 Days

4. Once certified, how long do you have to obtain the required 30 PDUs for renewal?

A. One Year B. Two Years C. Three Years D. Unlimited Time

5. How many hours of general project management experience do non-PMP or non-PgMPs need to sit for the PMI-ACP® exam?

A. 1,000 B. 2,000 C. 3,000 D. 4,000

6. How many separate, Agile-specific hours of experience do you need in order to sit for the PMI-ACP® exam?

A. 500 B. 1,000 C. 1,250 D. 1,500

7. How many contact hours are required in order to sit for the PMI-ACP® exam? A. 14 B. 21 C. 28 D. 35



Page 12

8. What is the PMI-ACP® fee for a 1st time taker who is also a PMI member? A. $435 B. $495 C. $535 D. $595

9. What refund can you expect if do not take or schedule the exam? A. $0.00 B. $100.00 C. $200.00 D. All of the fee

10. What is the fee charged for canceling the PMI-ACP® Exam within 30-days? A. $40 B. $50 C. $60 D. $70



Page 13

Introduction & Process Quiz Answers 1. Answer D. LGd Course Manual p.5 — Once you create a login on PMI’s certification you

have 90-days to complete your application.

2. Answer B. LGd Course Manual p.7 — How long it takes for PMI® to review your application is somewhat dependent on the volume of applications PMI® However, PMI® commits on their website to a 10-day window.

3. Answer C. LGd Course Manual p.9 — If you are unfortunate enough to be audited you have 90-days from the date of your notification letter to provide PMI® the required documentation.

4. Answer C. LGd Course Manual p.8 — Continuing professional development is very important to PMI®. For that reason, PMI® requires certificate holders to obtain Professional Development Units or PDUs over a three year period. The number of PDUs required varies by certification. For the ACP, PMI® requires 30 PDUs.

5. Answer B. LGd Course Manual p.7 — One of the differences between the ACP® and other Agile certifications is the ACP® requires practical experience not only working in Agile projects, but also traditional projects. PMI® requires applicants to have 2,000 hours of basic project experience. If you hold a PMP® or PgMP® certification this requirement is waved.

6. Answer D. LGd Course Manual p.8 — One of the differences between the ACP® and other Agile certifications is the ACP® requires practical experience not only working in Agile projects, but also traditional projects. PMI® requires applicants to have 1,500 hours of Agile experience.

7. Answer B. LGd Course Manual p.8 — Contact Hours represent hours of face-time with an instructor. Most provides claim their courses are worth between six and eight Contact Hours per day. LGd generally splits the difference and says our courses are seven Contact Hours per training day.

8. Answer A. LGd Course Manual p.10 — If you are a PMI member and are a 1st time test taker your fee is $435. If you are not a PMI® member you pay $495.

9. Answer C. LGd Course Manual p.10 — If you go through the process of completing the ACP application, getting approved, and paying the testing fee but you never actually schedule the exam you can obtain at $200 refund.

10. Answer D. LGd Course Manual p.10 — If you go through the process of completing the ACP application, getting approved, pay the testing fee, and the schedule the exam but have to cancel your test date within 30-days but more than 2-days you are charged a $70 fee.

Chapter 3 — The Exam


Page 14

Slide 10

Slide 11

Page 14

The Exam Exam Overview This section is all about understanding the exam constructed. It explores how the exam is put together and how you are expected to interact with it. These issues are key, but are often overlooked by authors of ACP® Examination Preparation books and courses. They spend all their time on the content. The content of the exam is critical, but many students fail because they are unprepared for the unique test experience. This book will spend a short chapter looking at the exam itself, so you do not have to take a chance of that happening to you. The examination covers everything from how the test is scored, to how the questions are constructed, to how the test is scored, and to what is covered.

Exam Results The PMI-ACP® Exam is a simple binary pass/fail exam. You either get enough questions correct to pass or you don’t. No one cares about how well you do beyond passing. When the test is scored, a candidate receives one of three levels of proficiency, or scores for each grouping of questions. These are not numeric scores, per se. Both “proficient” and “moderately proficient” represent passing scores. The score you don’t want is “below proficient.” The problem many candidates have with this scoring method is that it is often difficult to place much value in a section score because many of the sections are relatively small. Imagine a section of only three questions where you got two of the questions correct. That is a score of only 66% which is “below proficient.” This fact makes interpreting the result sometimes difficult. The key is to not get very caught up in any small area, but to focus on the big picture.

PMI® does not disclose the exact number of questions a candidate must correctly answer because the PMI-ACP® Exam uses “sound psychometric analysis.” This is a modern method of designing and scoring an exam. However, a majority of the trainers and consultants who prepare candidates for the PMI-ACP® Exam, estimate that the passing score is approximately 70%. This score is slightly higher than the 68% required to pass the PMP® exam. Most believe this is because the PMI-ACP® Exam is a bit easier than the PMP® Exam.

Exam Design Each candidate receives a uniquely constructed exam from a test-bank of thousands of potential questions that is build when the candidate first enters their personal information. You could be sitting in a large room full of PMI-ACP® candidates and no two of them would have the same exam-even though you each would have exams broken into the same groups and similar question percentages. Every candidate’s exam includes 120 questions. Each question is multiple choice with four (4) potential answers, and only one correct answer. A majority of these questions are situational in nature, meaning that they describe a specific situation and then ask what you would do in those circumstance. Unfortunately, rarely are any of the four options offered optimal. You will not be choosing from textbook



Page 15

answers. Instead, you are required to learn from sub-optimal answers.

Of the 120 questions only 100 count towards a passing score. The other 20 questions are being evaluated for potential addition to the exam test-bank. This is considered an industry best-practice by those who are experts on standardized testing. Before a question is officially placed in the test-bank, it is given to a pool of candidates. The test designers look at the number of candidates who pick each of the four potential answers. They look for an even distribution of the selection of answers. A poor question is one in which most of the candidates select one particular answer, regardless of whether the answer selected is correct or not. Designers want questions where most, if not all the answers, appear at least reasonable. Many candidates immediately want to know which questions are therefore real and which ones are not, so they can just skip or ignore the unscored items. Unfortunately, PMI® does not provide that information. You cannot tell which questions count toward your score and which ones do not.

Candidates are given three hours to complete the exam plus an additional 15-minute period to run through an interface learning program that allows the candidate to become familiar with the interface and computer system. Many candidates choose to skip this brief tutorial and still successfully complete the test. However, if you are unsure or uncomfortable with the interface, take the time to go through the tutorial. At the end of the exam candidates are asked to complete an optional survey before the test is graded. This survey does not impact your score in any way and is truly optional. However, we ask that you complete the survey because it helps PMI® to improve their programming, certification and educational offerings. The survey takes less than five minutes and asks questions about how you prepared for the exam. Did you take an exam preparation course? Are you involved with a local PMI® chapter? The survey also asks a few additional questions.

Candidates are not provided any scheduled breaks, but most testing centers will allow one bio-break. You are not allowed to take anything into the restroom with you during that break. This brings up an important area of discussion.

Arriving At The Testing Center The exam places a huge amount of stress on most candidates. The hours spent studying for the exam combined with the hundreds or even thousands of dollars spent on preparation courses and materials can bring out the worst in people. This all comes to a head on the day of the exam. No matter how many times I advise candidates against it, I have seen dozens of candidates stay up to all hours of the night and into the morning just before the exam. As a result, they are totally exhausted on test day and bomb a test they would otherwise have passed easily. I have also heard that a lot of candidates sit in their car just before their exam, trying to do a last little bit of cramming before their test time. News flash: It doesn’t work. Many studies have repeatedly shown that cramming doesn’t work, especially when the cramming is being done by a tired, overworked, mind.



Page 16

Slide 12-14

Therefore, the first rule you must follow to successfully navigate the exam is to arrive at the testing center fresh and rested. If you follow the plan outlined in this course you will be more than prepared for the exam, so don’t waste your time sitting in your car attempting to do any last minute cramming. You WILL know your stuff!

Arrive at the testing center 20 to 30 minutes prior to your scheduled test time. This will give you enough time to check in and get situated. When you arrive at the testing center, leave all your personal items in the car. Some testing centers provide cubbies to store your personal things, but those centers do not accept any responsibility for them. You are better off leaving your belongings in your car. This is especially true of your tablet, cellphone, or any other electronic device that might be used to answer questions on the test or provide information to future test takers. The only thing you need to bring with you into the testing center are two forms of identification and the exam confirmation letter that contains your test ID. One of your identification forms must be a government issued picture ID, such as a driver’s license or passport. The second ID can be almost anything such as credit card, military ID, social security card, etc.

Exam Breakdown The exam is broken several different ways. The first is a 50/50 split between Agile Tools and Technique and Agile Knowledge & Skills. The Tools and Techniques half of the exam is broken into a number of subsections including:

Communications — Including but not limited to: information radiator, team space, agile tooling, osmotic communications for co-located and/or distributed teams, and daily stand-ups.

Planning, Monitoring & Adapting — Including but not limited to: retrospectives, Scrum/Kanban boards, timeboxing, iteration and release planning, WIP limits, burn down/up charts, cumulative flow diagrams, and process tailoring.

Agile Estimating — Including but not limited to: relative sizing/story points, wide band Delphi/planning poker, affinity estimating, and ideal time.

Agile Analysis & Design — Including but not limited to: product roadmap, user stories/backlog, story maps, progressive elaboration, wireframes, chartering, personas, and agile modeling.

Product Quality — Including but not limited to: frequent verification and validation, test-driven development/test first development, acceptance test-driven development, definition of done, and continuous integration.

Soft Skills Negotiation — Including but not limited to: emotional intelligence, collaboration, adaptive leadership, negotiation, conflict resolution, and servant leadership.

Value-Based Prioritization — Including but not limited to: return on investment (ROI)/net present value (NPV)/internal rate of return (IRR),



Page 17

Slide 15

Slide 16

compliance, customer-valued prioritization, minimally marketable feature (MMF), and relative prioritization/ranking.

Risk Management — Including but not limited to: risk-adjusted backlog, risk burn down graphs, and risk-based spike.

Metrics — Including but not limited to: velocity, cycle time, earned value management (EVM) for agile projects, and escaped defects.

Value Stream Analysis — Including but not limited to: value stream mapping.

The knowledge and skills half of the exam is broken into three levels.

Level I — This level accounts for 65% of the section and 33% of the overall exam.

Level II — This level accounts for 25% of the section and 12% of the overall exam.

Level III — This level accounts for 10% of the section and 5% of the overall exam.

These three levels are further broken into a large number of specific topics:

Active listening Incremental delivery

Agile Manifesto values & principles Knowledge sharing

Assessing & incorporating community & stakeholder values

Leadership tools & techniques

Brainstorming techniques Prioritization

Building empowered teams Problem-solving strategies, tools, & techniques

Coaching & mentoring within teams Project & quality standards for Agile projects

Communications management Stakeholder management

Feedback techniques for product (e.g. protoyping, simulation,

demonstrations, evaluations)

Team motivation Time, budget, & cost estimation Value-based decomposition & prioritization

Level I



Page 18

Slide 17

Slide 18

Key Reading

With the exam breakdown defined, one of the last thing to discuss is where all the detailed knowledge within the exam comes from. Although the structure and basic outline for the PMI-ACP® Exam comes from a periodic Role Delineation Study, the detailed facts and concepts do not. There are a lot of books out there written about Agile. Those books offer a wide range of ideas about Agile Development, and not all of them agree with each other. PMI® does not expect you to read everything there is out there on Agile Development. They expect you to combine your practical experience from being part of both traditional projects and Agile ones together with knowledge from 11 different resources to form a well rounded general knowledge-base in the field. This manual will cover most of this information, and therefore many students successfully pass the exam without reading the source material. However, if you find yourself unsure of any topic area, you should immediately get your hands on the original source. As you

Level II Agile frameworks & terminology Facilitation methods

Building high-performance teams Participatory decision models (e.g. input-based, shared collaboration, command)

Business case development PMI’s code of Ethics & Professional Conduct

Colocation (geographic proximity) / distributed teams

Process analysis techniques

Continuous improvement processes Self assessment

Elements of a project charter for an Agile project

Value-based analysis

Level III Agile contracting methods Regulatory compliance

Agile project accounting principles Variance & trend analysis

Applying new Agile practices Variations in Agile methods & approaches

Compliance (organization) Vendor management

Control limits for Agile projects Principles of systems thinking (e.g. complex adaptive, chaos)

Globalization, culture, & team diversity

Agile games



Page 19

Slide 19 examine the list, pay special attention to the number of resources that focus on the soft skills involved in leading people.

Agile Retrospectives: Making Good Teams Great, Esther Derby, Diana Larsen, Ken Schwaber.

Agile Software Development: The Cooperative Game – 2nd Edition, Alistair Cockburn.

The Software Project Manager’s Bridge to Agility, Michele Sliger & Stacia Broderick.

Coaching Agile Teams, Lyssa Adkins.

Agile Project Management: Creating Innovative Products – 2nd Edition, Jim Highsmith.

Becoming Agile: …in an Imperfect World, Greg Smith & Ahmed Sidky.

Agile Estimating and Planning, Mike Cohn.

The Art of Agile Development, James Shore.

User Stories Applied: For Agile Software Development, Mike Cohn.

Agile Project Management with Scrum, Ken Schwaber.

Lean-Agile Software Development: Achieving Enterprise Agility, Alan Shalloway, Guy Beaver, James R. Trott.

Effective Project Management: Traditional, Agile, Extreme, Robert Wysocki.

Exploring Scrum: The Fundamentals, Dan Rawsthorne with Doug Shimp.

Kanban In Action, Marcus Hammarberg, Joakim Sunden.

Kanban: Successful Evolutionary Change for Your Technology Business, David J. Anderson.

All of these books should be on your bookshelf if you are a practicing agilest. They represent the key thoughts from the world’s leading agilists. If you are a PMP® or coming from a background leading traditional, linear projects I highly recommend the Sliger and Broderick book because of its ability to connect the PMBOK® Guide to Agile concepts. The best Agile coaching and soft skills concepts come from Lyssa Adkins. Anything you can ever read from Mike Cohn is well worth it. If you are especially interested in Scrum you should begin with Ken Schwaber’s Agile Project Management with Scrum. Finally, Alistair Cockburn offers some powerful insights on the field in his Agile Software Development: The Cooperative Game.



Page 20

Slide 20

Domain Breakdown After this chapter, the rest of this course is spent looking at the specific, detailed knowledge you need to pass the exam. We break the information down the same way PMI® does in their the PMI-ACP® documentation provided on the PMI® website. PMI® refers to these sections as domains. Each domain represents a set of core knowledge you must possess to successfully pass the exam. There is quiz is at the end of each chapter to ensure you understand each domain. Take the quizzes seriously. They are powerful learning tools designed to work in conjunction with the lectures and written components of this manual. They will help you succeed. You will know that you are ready for the real exam when you score at least 90% on ALL your practice exams. Take and retake the quizzes until you are getting the requisite score. Also, reread and/or listen again to any lectures if your scores are not where they need to be. Finally, pay special attention to the questions that are situational in nature. We use several different types of questions in the practice quizzes to help you learn the material. They are all important, but the situational questions most closely resemble the questions you will see on the real exam. Now, if you are ready to get started, complete the brief quiz that follows before we introduce the first of the seven domain areas. The areas include:

Agile Principles & Mindset 16% of Items on Exam

Value-Driven Delivery 20% of Items on Exam

Stakeholder Engagement 17% of Items on Exam

Team Performance 16% of Items on Exam

Adaptive Planning 12% of Items on Exam

Problem Detection & Resolution 10% of Items on Exam

Continuous Improvement (Product, Process, People) 9% of Items on Exam



Page 21

Test Taking Strategies

The PMI-ACP® exam is similar to a lot of other standardized exams, and as such you can apply a number of commonly used test-taking strategies to improve your results. These strategies will not replace knowing the subject matter, but they can provide a significant lift to your score when you are nervous or struggle with specific questions. These strategies include:

Predict the answer: If you have studied hard and truly know the material, a great technique is to predict the correct answer to a question before you read the choices. This technique is especially effective on questions that test your factual knowledge or ask you to fill in the blank or complete a sentence. By first predicting the answer you can avoid being distracted by choices that don’t agree with your knowledge. Once you make your prediction make sure to read all of the choices so you can be sure to select the answer that most closely meets your expectations.

Your first instinct: Often, test-takers struggle because they overthink the questions. If you have done your homework, you will know the information and must have confidence in that knowledge. It is critical that you trust your first instinct. That little voice you hear is right more often than not. Research has shown that your intuition often works faster than your reasoned mind. If you have studied, your subconscious will often retrieve information before you have a chance to work out the associations that support it.

Read the whole question: Predicting the right answer and trusting your instincts does NOT justify failing to read the entire question. Adding or deleting one word can significantly alter the meaning of a question. Far too often, test takers scan a multiple-choice question and recognize a few familiar words. They then quickly progress to the answers where they find exactly what they believe to be the correct choice. Unfortunately for them, test designers also know about this tendency and regularly design questions taking it into account. The only way you can avoid this pitfall is to read each question carefully and then read it again before continuing to the potential answers. PMI® allows up to three hours for the exam. This is more than enough time to complete the exam. There is absolutely no reason to rush through the exam. Take the time to carefully read each question and all the potential answers before attempting to select the appropriate answer.

Look for wrong answers: Once you have read the question carefully twice it is time to examine the potential answers. One of the best way to simplify a multiple-choice exam is to limit the number of potential choices. Focus on removing the obviously wrong answers from the list before you consider the potential right ones. Sometimes identifying an incorrect answer can help you find the correct one as often the right answer is the exact opposite of one of the wrong answers. This is not always the case, but it is a quick enough tactic to help in many cases.



Page 22

Don’t overanalyze: It is very common for test takers to be nervous. When you are nervous the brain often runs wild with a hundred different thoughts and scenarios for each question. To succeed, you must take a deep breath and SLOW DOWN! You have plenty of time to complete the exam. Focus on the actual words in front of you. Do NOT create complex interpretations or try to get into the mind of the test designers. Answer the question in front of you and limit your thoughts to the information presented.

Key words: Do you struggle with poor reading comprehension skills? If so, you are like 60% of the people who take the PMI-ACP® exam. You can dramatically improve your understanding by using the provided scratch paper to jot down a few key words or phrases. This practice helps you to concentrate on the process of reading by forcing the mind to weight the relative importance of the question parts. This process will help you think more deeply and carefully about the question.

Confusing answer choices: The PMI-ACP® exam is full of long winded questions and answers. Many candidates are confused by such wordy content. As a result, they tend to focus on the answers that are shorter and often easier to understand. Don’t make this mistake. The length of an answer or its confusing diction has nothing to do with its validity. When you see a long winded question or answer pay extra attention and try rephrasing it to ensure your understanding.

True statements: Often PMI® uses information within the four potential answers that is completely factual. That’s right, the information is true, but just because the information provided in the answer is true it does NOT make the answer necessarily correct. It is critical that you learn to tell the difference between a factual answer and a correct one.

No pattern: Many students believe they can decipher a pattern in the answers on the test, or that they should always select a specific letter like “C”. This is one of the worst ideas you can possibly take into the testing room. Remember, your exam is generated from thousands of potential questions. The criteria for being included in your test is whether or not the question gives us the correct number of questions for a specific area. Additionally, the system randomizes the answers so that two candidates could be sitting next to each other and get the same question, but find the correct answer is a different letter.



Page 23

Exercise 2 — The Exam

The Exam Quiz 1. Which of the following best describes how the PMI-ACP® Exam is graded?

A. A, B, C, D, F B. Pass / Fail C. Subjectively D. Using a regionalized curve

2. Each topic area on the exam is graded with a measure of your knowledge. Which of the following is NOT one of those potential scores?

A. Above proficient B. Proficient C. Moderately proficient D. Below proficient

3. How many questions are on the PMI-ACP® Exam? A. 100 B. 120 C. 150 D. 200

4. How many questions on the PMI-ACP® Exam count towards your score? A. 100 B. 120 C. 150 D. 200

5. How much time is provided to complete the PMI-ACP® Exam? A. 1 Hour B. 2 Hours C. 3 Hours D. 4 Hours

6. How many scheduled breaks are provided during the PMI-ACP® Exam? A. 3 B. 2 C. 1 D. 0

7. Generally, how many bio-breaks will MOST testing centers allow? A. 3 B. 2 C. 1 D. 0



Page 24

8. What score do you need to achieve on all practice exams in this course before attempting the real PMI-ACP® Exam?

A. 75% B. 80% C. 90% D. 100%

9. What percentage of the PMI-ACP® Exam will cover Agile tools and techniques?

A. 25% B. 50% C. 75% D. 100%

10. Which of the following is NOT a critical book to read in preparing for the PMI-ACP® Exam?

A. Coaching Agile Teams, by Lyssa Adkins B. Agile Estimating & Planning, by Mike Cohn C. The Software Project Manager's Bridge to Agility, by Sliger &

Broderick D. Being Agile, by Nastia Lukin



Page 25

The Exam Quiz Answers 1. Answer B. LGd Course Manual p.14 — Like all of PMI’s certification exams, the ACP® is a

pass/fail test with a target score of somewhere around 70%.

2. Answer A. LGd Course Manual p.14 — The PMI-ACP exam breaks the 120 questions into smaller groups that are scored as proficient, moderately proficient, or below proficient. These groupings are often difficult to understand due to the fact that there may only be two or three questions in a group.

3. Answer B. LGd Course Manual p.14 — The PMI-ACP exam has 120 questions on it. Each exam is uniquely generated from a test bank of thousands of questions, and of the 120 question only 100 actually count towards your score.

4. Answer A. LGd Course Manual p.15 — The PMI-ACP exam has 120 questions on it. Each exam is uniquely generated from a test bank of thousands of questions, and of the 120 question only 100 actually count towards your score.

5. Answer C. LGd Course Manual p.15 — Candidates are given three hours to complete the exam plus an additional 15-minute period to run through an interface learning program that allows the candidate to become familiar with the interface and computer system.

6. Answer D. LGd Course Manual p.15 — Candidates are not provided any scheduled breaks, but most testing centers will allow one bio-break. You are not allowed to take anything into the restroom with you during that break.

7. Answer C. LGd Course Manual p.15 — Candidates are not provided any scheduled breaks, but most testing centers will allow one bio-break. You are not allowed to take anything into the restroom with you during that break.

8. Answer C. LGd Course Manual p.15 — You will know that you are ready for the real exam when you score at least 90% on ALL your practice exams. Take and retake the quizzes until you are getting the requisite score. Also, reread and/or listen again to any lectures if your scores are not where they need to be.

9. Answer B. LGd Course Manual p.16 — The exam is broken several different ways. The first is a 50/50 split between Agile Tools and Technique and Agile Knowledge & Skills.

10. Answer D. LGd Course Manual p.19— Nastia Lukin was a gold medal winning gymnast and not an Agile author. The listing of core books for the PMI-ACP exam is found on page 19 of this manual.

Chapter 4 — Agile Principles & Mindset


Page 26

Slide 22

Page 26

Agile Principles & Mindset Part I Principles & Mindset Overview This chapter is far and away the largest both in the manual and the course. Not only is it big, it also includes the largest diversity of concepts. The diversity comes from the fact that this section introduces all the Agile foundations, as well as the various specific Agile methodologies or frameworks. That is a lot of ground to cover — so much ground, in fact, that we break the chapter into two separate sections. This first section introduces the basic foundational principles of Agile development along with the most common Agile methods. The second section introduces several additional Agile methods along with techniques to scale the various methods to large organizations and/or programs.

Domain Tasks In this chapter we will introduce a new practice that will appear at the beginning of each successive chapter. It is the inclusion of a section on domain tasks. A domain is the area under discussion, in this case Agile principles and mindset. Within each domain, PMI® defines a set of specific tasks it expects to be performed. You are responsible for knowing these tasks, understanding how they work together, and understanding how they fit with all the other Agile concepts. Here are the tasks for the Agile principles and mindset domain:

1. Advocate for Agile principles by modeling those principles and discuss Agile values in order to develop a shared mindset across the team as well as between the customer and the team.

2. In order to work effectively, help ensure that everyone has a common understanding of the values and principles of Agile as well as a common knowledge of the Agile practices and terminology.

3. In order to make the organization more effective and efficient, support change at the system or organization level by educating people about the organization and influencing processes, behaviors, and people.

4. Practice visualization. Maintain highly visible information radiators that show real progress and real team performance in order to enhance transparency and trust.

5. Contribute to a safe and trusting team environment by allowing everyone to experiment and make mistakes so that each person can learn and continuously improve the way he or she works.

6. Enhance creativity by experimenting with new techniques and process ideas in order to discover more efficient and effectives ways of working.

7. Encourage team members to share knowledge by collaborating and working together in order to lower risks around knowledge silos and to reduce bottlenecks.



Page 27

Slide 23

8. Encourage emergent leadership within the team by establishing a safe and respectful environment in which new approaches can be tried in order to make improvements and foster self-organization and empowerment.

9. Practice servant leadership by supporting and encouraging others in their endeavors so that they can perform at their highest level and continue to improve.

PMBOK® Guide vs. Agile Over the years, a lot of misinformation has developed about how Agile relates to traditional project management. To traditional project managers, Agilists seem haphazard and prone to lead projects that never end and never deliver. Agilists think the same thing of traditional project managers. It is a little funny if you stop and think about it. Rather than propagate any more misinformation, let’s focus on the facts and clear up much of the misinformation.

Let’s begin with the PMBOK® Guide. PMBOK® is an acronym that stands for the Project Management Body of Knowledge. The PMBOK® represents everything that has ever been written about the field of project management. That means every book, article, white paper, manual, video, YouTube video, TED Talk, or any other material available through any other channel of delivery. That is a huge amount of information, and much of it conflicts. So how do you know what represents the “RIGHT” way? The simple answer is that trying to read all the PMBOK® is nearly impossible and there are so many conflicting ideas that such an endeavor will lead to nothing but confusion. However, there is an answer.

Founded in 1969 in Newtown Square, Pennsylvania, the Project Management Institute (PMI®) is the world’s largest association dedicated to the advancement of project management as both a field and as a profession. At the forefront of thought leadership for the profession, PMI® has published the PMBOK® Guide every four years since 1996. The PMBOK® Guide is a much more practical resource for practitioners. The Guide does NOT represent best practice. In fact, according to PMI® there is no such thing because “best” is such a relative term. It is dependent on the industry, product, the team that created the book, and 20 other potential factors. Therefore, PMI® makes no effort to define a single best practice. Instead, PMI® uses tools like role delineation studies that survey thousands of project managers, Agilists, business analysts, and program or portfolio managers to find trends that lead to “generally accepted practices.” This is a way of saying the most commonly used practices that lead to positive outcomes.

When you talk to many leaders of organizations who base their project management practices on traditional practice they like to state that they are following the PMBOK® Guide. This statement is nearly meaningless. It is impossible to manage a project following the PMBOK® Guide because the PMBOK® Guide does not provide step-by-step instructions on how to manage a project. Instead, the Guide represents a framework or umbrella of commonly accepted ideas which may be used to manage a project. So what does this have to do with Agile development? Believe it or not, Agile development does NOT



Page 28

Slide 24

contradict the ideas found in the PMBOK® Guide. Not even a little. For many reading this manual, this statement comes as a shock. You might even have some misgivings about it. But it is the truth. For years those in the Agile movement and those in who are more traditionally trained project leaders have fought a battle of ideas that is based on a lie. Blame for this came be placed on all sides, but mostly it comes down to the use, or misuse, of a few terms. To better understand, let us define these terms.

In the 6th edition of the PMBOK® Guide changed how PMI® represented this model in hopes of reducing confusion between the defined framework and various methodologies or lifecycles (See image below). The new representation begins at the top with the project lifecycle which represents the actual process used for your specific project. In general terms, each lifecycle goes through a similar series of steps where the project is first started. Once the organization recognizes it has a project on its hands and decides to manage it as such, the effort must be organized and preparatory work completed. The team then uses its defined processes to complete the project work, and eventually the project ends.

Beneath the project’s specific lifecycle sits the five PMI® process groups: initiating; planning; executing; monitoring and controlling; and closing. These five containers represent placeholders for the 49 specific processes defined in the ten knowledge areas of the PMBOK® Guide. It is at this point that examining PMI’s previous model holds value for understanding the project management framework.

The model begins with a project sponsor or initiator defining a business or organizational need. The need is further defined until someone recognizes that it should be a project. At that point the initiating process group begins.

The initiating process group has two key goals: to develop a project charter and to identify stakeholders. The charter authorizes the project, empowers the project

Project Lifecycle



Page 29

Slide 25

leader, defines success criteria, the business need and justification, constraints and assumptions, and prioritizes the project. Once the charter is created and stakeholders have been identified, the project progresses into the planning process group.

The planning process group is the largest of the five project management process groups. It also has the potential for a looping relationship with the executing process group. This relationship is the point of the confusion for students of project management. If both the planning process group and executing process group are done just once it creates a linear lifecycle such as in waterfall or SDLC. But the model also allows for the planning and executing process groups to be completed many, many, times in a back-and-forth relationship. This us an incremental or Agile approach.

Deciding when planning is complete, and when it is time to execute the project is the monitoring and controlling process group. This process group acts as the project’s eyes and ears. The monitoring and controlling process group might also decide that a project requires more planning after execution has begun, or that all the project work is complete.

Lastly, there is the closing process group. Whereas the executing process group produces deliverables, only the closing process group produces the final product, service, or result. Additionally, the closing process group produces project records which then become assets to the organization because they allow it to engage in continuous process improvement, which is very important to PMI®.

Understanding the various lifecycles that fit into this model is a very important aspect of your studies. PMI® describes lifecycles using a number of groupings. In the simplest terms, these groupings are represented at the extremes by constantly evolving planning where the project is broken into small components over a less determined timeline versus project planning that is done in a linear fashion with a specific development plan, structured specific scope, and schedule and cost estimates. However, all of these lifecycles are broken into phases specifically associated with the development of products, services and results. The discussion of lifecycles or methodologies has a variety of options beyond the basic predictive and adaptive. These include:

Predictive lifecycles — In a predictive lifecycle the team spends significant time in the early phase of the project determining project schedule, scope, and cost estimates, often referred to as the project’s triple constraints. Throughout the rest of the project, the team then works to tightly manage any scope changes. A predictive lifecycles include the Software Development Lifecycle (SDLC) and the waterfall methodology. This model works well when it is reasonable to expect that all the requirements are knowable at the beginning of the project and it is critical to maintain stable scope, schedule and cost targets. However, this model does not typically respond well to missed or changing requirements.

Iterative lifecycles — Iterative development generates a cyclical process that often has a single general roadmap. However, it uses a series of steps where each step learns from the previous ones to produce the overall product, service or result.



Page 30

An iterative process embraces the fact that many projects struggle with knowing at the beginning what the final product should look like and responds by building in as many learning opportunities as possible. An often used tool in iterative development is prototyping.

Incremental lifecycles — In incremental lifecycles the product, service, or result of the project is produced using a series of chunks. The most common implementation of incremental delivery has the team delivering business value in a series of releases rather than one large chunk. The big difference between this model and an iterative cycle is that those using an incremental lifecycle will work to maintain the original road map, and few opportunities exist for feedback from the customer until the final product, service or result is released.

Adaptive or Agile lifecycles — Adaptive lifecycles may be iterative, incremental, or agile. In an adaptive model, project scope is defined at the beginning of each iteration and only generally at the beginning. These lifecycles are also called agile or change-driven. Agile methodologies are all the current rage. Scrum, Extreme Programming, DSDM, Feature Driven Development, and Crystal are all examples. These models typically have smaller collocated teams and offer critical advantages when the team is dealing with poorly defined or changing requirements.

Hybrid lifecycles — A hybrid lifecycle is a combination of the adaptive and predictive lifecycles. In this model, the team uses a predictive model for those requirements that are either well known or fixed and uses an adaptive model for requirements that are unknown, incomplete, or evolving. This is not an undefined process where the team is allowed to do whatever it wants. In most cases, the team follows a process defined by the larger organization to ensure consistency of process.

It is up to the team to decide the best lifecycle for the particular project in their specific organization. However, the information provided above, which largely aligns with the limited information found in the PMBOK® Guide, is definitely not enough to make a real-world decision on the best methodology to use. It also isn’t enough to get you through the exam. You need to study the different methodologies especially in terms of a compare and contrast exercise. The table on the next page will help. It specifically outlines how each lifecycle addresses requirements, activities, delivery and the project goal.

When this book uses the term traditional project management, it is referencing the use of methodologies derived from the engineering world. These approaches have been used for hundreds and even thousands of years. They tend to be linear in nature, and often place an emphasis on defining requirements in greater detail early in a project lifecycle. In information technology (IT), this was best codified by Dr. Winston W. Royce in the late 1970s in what he called the Waterfall Methodology. Often these linear or predictive approaches have four or five steps including things like: analysis, design, coding, testing, and deployment.

A predictive lifecycle is best applied when the requirements are stable and well understood. This is because a predictive model wants to complete all its planning at the beginning of the project as a single exercise with a goal of managing overall



Page 31

Slide 26

project costs. Each of the other major families of methodologies allow for the dynamic evolution of project requirements and do not assume they are completely known at the beginning of the project. The next two types of lifecycles are iterative and incremental. Famed Agilist Alistair Cockburn defines these terms as follows:

Incremental development is a staging and scheduling strategy in which the various parts of the system are developed at different times, or rated and integrated as they are completed. This means that the features or requirements do not have to be completed as part of a single release. When a team uses incremental delivery, they are able to deliver features or requirement in a wide range of orders defined by the team. This fundamentally changes how projects are executed. This notion is somewhat similar to the ideas surrounding Object Oriented Programming, where features and requirements are delivered as discrete objects independent of others.

Iterative development is a rework scheduling strategy in which time is set aside to revise and improve parts of the system. The concepts of Incremental and Iterative Development create loops in the process of executing a project. That allows the team to change their process to improve execution and delivery. In a single-looped, linear process, the team is stuck with the process with which they start the project. This is a key advantage to seasoned, experienced teams. Such teams have completed multiple projects together and hopefully those experiences provide insights on the current effort. Agile projects get lots and lots of chances to deliver because they use lots of short iterations. Each one requires a short cycle of reflection to determine the best way to improve the process and deliver better results.

The next image allows you to visually compare predictive, iterative, and adaptive or incremental delivery. Notice that the adaptive lifecycle shows the same five process groups inside each iteration. This is considered a major anti-pattern by most Agilists, and we will discuss why later in the course.

Characteristics

Approach Requirements Activities Delivery Goal

Predictive Fixed Performed once for

the entire project Single delivery Manage costs

Iterative Dynamic Repeated until

correct Single delivery Correctness of

solution

Incremental Dynamic Performed once for a given increment

Frequent smaller deliveries Speed

Agile Dynamic Repeated until

correct Frequent smaller

deliveries

Customer value via frequent delivery

and feedback



Page 32

Slide 27

Slide 28

So how are you to determine which lifecycle is best for your project, team and organization? There really are just a couple of factors you must consider. The most important of which is the degree of scope change the team expects to see. Additionally, you must consider the frequency of delivery. Will your team

delivery all of the scope at one time at the end of the project or is it better to offer frequent delivery of features so the customer can review them and make any desired changes? If the team just wants frequent delivery an incremental lifecycle makes the most sense. If they feel they must deal with a high degree of scope change then an iterative approach is likely best. If they expect a low degree of scope change and can deliver the entire product or service of the project then a predictive model will work. However, if the team is struggling with both a high degree of scope change AND need to deliver frequently then an Agile lifecycle is best.

Regardless of the methodology you choose, the approach is typically the same. The



Page 33

team must first adopt the formal lifecycle and the spend a period of time becoming familiar with it. It is very important that they take the time to learn the basic process without any customization to ensure they understand what the framework is after. Only then can they begin the process of tailoring the lifecycle to best fit the team, the organization and the project.

When this book generically makes use of the term Agile development, it is referencing a series of project management practices largely created in the software development industry in the last 20 years. These practices draw significantly on the work done by thought leaders such as Edward Deming and others who examined the production techniques of Toyota and other Japanese organizations in the 1950s through the 1970s. Concepts such as Lean, TQM and PDCA are perfect examples. Although there are over 16 different defined sets of practices found in Agile development, the most common are Scrum, Extreme Programming (XP) and Kanban. In most cases, we will focus on the practices of Scrum and XP as they are most often used.

These diverse concepts conflict in two ways. First, many agile writers (See Jim Highsmith for an excellent example) justify the need for Agile development using the term “traditional project management” when what they really mean is very badly run waterfall projects. Let’s be perfectly clear. Just because a team uses a waterfall methodology — or any other — does not inherently make it a poorly run project. Tens of thousands of projects have delivered fantastic results over the decades using a waterfall methodology. However, a badly run project is just that: badly run. No methodology, or set of practices will save it. It is also true that most projects are significantly impacted by the methodology used to execute them. There is almost always an optimal methodology for every team, organization, and project. I have never seen a great team fail because of their methodology, but many have had to fight through practices that fail to align with what they are trying to do. Alignment is key. Don’t ever just assume a project is poorly managed because of the methodology it uses.

Secondly, some of the earliest writing in Agile development comes from the creators of Scrum. Ken Schwaber and Jeff Sutherland offer incredible insights and powerful concepts for any development team. They also have confused the hell out of a lot of people. Both authors commonly refer to Scrum as a “framework,” arguing that it is like a scaffolding used by bricklayers to surround a building as it rises from the ground. It is loose and provides the team a lot of latitude in its execution of the project. Yet, as you will see in our discussion of Scrum, it requires a specific set of roles, artifacts, and meetings which must be adhered to. Many Agile coaches have made an excellent living helping teams move away from a concept called “ScrumButt” where the team is doing Scrum but for one or two things. A knowledgeable Scrum practitioner immediately knows that isn’t Scrum. Doing Scrum requires you follow the rules.

What does this have to do with anything? It’s simple. Remember earlier when I described the PMBOK® Guide as the framework or umbrella under which many different project management methodologies fit? Now, the authors of Scrum also claim they represent a framework, and many people will try to argue that it is a direct contradiction to the PMBOK® Guide. But it just doesn’t work when you



Page 34

examine the facts carefully. The truth is there is only one set of generally accepted practices and principles in project management. That is the PMBOK® Guide. It is the umbrella under which all commonly used ideas fit. Agile development and all its tools and techniques are powerful and incredibly important. These Agile ideas fit into the Guide in two areas: general concepts every leader should know and have at their disposal and specific methodologies such as Scrum or XP that outline specific steps or a process the team should follow in the execution of a project. So, don’t get confused. If you can get this straight, you do not have to live in one camp or the other. Suddenly, you will be free to pick the best tools and techniques to execute the project you are currently on. Furthermore, those tools will constantly change and evolve as you become a better leader, regardless of your title.

General Agile Concepts There are lots of different Agile methodologies out there and for the exam you do not need to know them all. However, you do need to be familiar with the several we will examine in this course. Additionally, you must be capable of understanding several broad generalizations. All Agile lifecycles work to fulfill the principles defined in the Agile Manifesto. Additionally, most Agile methods fall into one of two classes. They are either what is called iteration-based or flow-based.

Iteration-based Agile methods require the team to work in iterations to deliver features. This work focuses on the most important features first and continues working toward the least important ones. However, the team never works in the analysis, design, build, test and deliver model described in predictive models even in a single increment. This often requires the team to replace stories or features back on the backlog for completion in a future iteration when they cannot be completed.

Flow-based Agile represents a more constant process as the team continuously pulls features from the backlog based on its capacity to start work rather than on an iteration-based schedule that defines when certain features are expected. In a flow-based model the team defines its workflow with columns on a team or task board and manage the work in progress for each column.

Both the iteration-based and flow-based Agile lifecycles share a number of characteristics such as very short feedback loops, a frequent adaptation of process, constant reprioritization of requirements, regular plan updates and frequent delivery of business results.

With the PMBOK® Guide firmly in place as the umbrella under which all tools and techniques used to execute projects reside, we can now turn our attention to the critical concepts that form the foundation of Agile development, beginning with an effort to define the differences between Agile development and linear approaches such as predictive development.

Most people familiar with linear approaches to projects like waterfall believe they are lock-step, straight-line approaches to execution. It is true that Waterfall

Slide 29-30



Page 35

Slide 35

development defines five steps analysis, design, execution, testing and deployment. However, if one refers back to Dr. Royce’s original paper he also argues at the paper’s end that this sequence must be repeated multiple times to successfully deliver business results. This notion highlights a key aspect of Agile development. Agile development is both iterative and incremental. Agile processes change the way work is completed by team members. It makes extensive use of WIP or Work In Progress. Although there is no rule or requirement to do so, most traditionally managed projects use a concept called Best Resourcing. In Best Resourcing, tasks are assigned to whichever resource possesses the highest skill-level. WIP represents a very different way to task project work. To better understand WIP, let’s exam a simple example.

Imagine that you are part of a project team that has three deliverables to complete, and three resources on the team. Each resource is the perfect resource to complete one of the three tasks. Additionally, the team is constrained by only being allowed six time/cost units to complete its work. How do you decide who does what? One option would be to use best resourcing. Option 1 represents this choice. In this option, the person who is the most skilled at the work does each task. As a result, Deliverable X is worked on by Resource A, Deliverable Y is worked on by Resource B, Deliverable Z is worked on by Resource C. Notice that the statement says each deliverable is “worked on” by the specified resource and NOT “completed by.” That is because, like many real-world projects, our example struggles with schedule and budget limitations. At the end of six time/cost units the team runs out of time and/or money. Unfortunately, the team is only 2/3rds complete with each deliverable. This puts the project’s sponsor in an incredible bind. They have spent all the time and money the planned for the project, but have nothing of tangible value to show for it. The only logical choice is to spend 50% more than planned to complete the deliverables to avoid walking away from the initiative with nothing to show for the effort.

Now let’s look at Option 2. In this option, we do not assign the best, most skilled resource to complete the task. Instead we assign a capable resource to the first two deliverables. For Deliverables X and Y nothing changes between the two models. However, with Deliverable Z we see a change. Instead of assigning Resource C to begin working on Deliverable Z (where they are the most capable resource), we instead ask them to help Resource A with Deliverable X. We do this because of the principles of managing WIP. This principle argues that we want to limit the

Deliverable X

Option 1 A A

Option 2 A C A

Deliverable Y

Option 1 B B

Option 2 B B C

Deliverable Z

Option 1 C C

Option 2



Page 36

amount of Work In Progress occurring at any single point. The principle can be thought of like a water main. The objective of the Water Department is to ensure the maximum amount of water is constantly available to the end users when they turn on their faucets. Contrary to what you might think, the best way to ensure high water pressure is to ensure the mains are less than 100% full. Remember, the mission is to get each drop to the customer as quickly as possible. If you ask your friendly neighborhood civil engineer, they will confirm that the water will travel the fastest when the pipe is less than 100% full. We do the same thing with our project tasks when using WIP. We need to have all hands focus on getting one deliverable through the process, then another, and another, and so on until the project is complete. The team’s focus is on throughput, not starting as many things as possible.

Now let’s go back to our time/cost limitation. Remember, we still only have six time/cost units to spend on our project. In Option 2, both Resources A and C start working on Deliverable X. At the same time Resource B begins working on Deliverable Y. Once Deliverable X is complete, Resource C shifts over and helps Resource B complete Deliverable Y. At the end of the same six time/cost units, both Deliverables X and Y are complete. Immediately you might have just thought, “Yeah, but you have nothing done with Deliverable Z.” And, you would be correct. However, advocates of WIP would argue this is a positive not a negative. In addition to maximizing throughput (remember we now have two deliverables completed), the team has eliminated all waste. Waste in this case is defined as any partially completed work product when the team runs out of time or money. In this case, we are talking about Deliverable Z. Nothing was done on it, so there is no waste. This puts our Project Sponsor in a powerful position because now they truly have a choice. Should they spend the extra 50% time/cost to complete Deliverable Z or not? If the team has correctly applied another common Agile principle of completing the most important work first, then Deliverables X and Y were the two most important, and Z is less important. The key question for our Sponsor centers on whether or not Z is worth the added 50%. If she walks away now, she has gotten her two most important deliverables and stayed within budget. WIP gives the power back to business and removes the common complaint that they were forced to complete a project because they had already invested so much. Good money no longer needs to follow bad.

Agile History Agile Development began to reach critical mass in the late 1990s with multiple competing methodologies appearing at conferences, in whitepapers and on bulletin boards (remember CompuServe?). Then in February of 2001, nearly 20 thought leaders within the Agile Movement got together in Snowbird, Utah in an effort to find common ground. On the next page is a list of the leaders present at this initial meeting.

Most of these leaders are still highly involved in the Agile community today and are very supportive of each other, but that was not always the case. Stories abound throughout the community of this early meeting. Most of those stories depict a group of leaders struggling to find common ground as each believed they



Page 37

Slide 37

Slide 38

possessed some knowledge or process that was critical to the future of information technology. That is, until they found common ground in a set of four value statements. These value statements are still at the core of Agile development as part of something called the Manifesto for Agile Software Development. The Manifesto is still available at http://wwwagilemanifesto.org, where it has lived since 2001. The Manifesto states:

“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 and interactions OVER processes and tools.

Customer collaboration OVER contract negotiations.

Responding to change OVER following a plan.

Working software OVER comprehensive documentation.

That is, while there is value in the items on the right, we value the items on the left more.”

Let’s take a brief moment to examine these four value statements. As we look at them, ask yourself what you think about them as a general rule, rather than trying to learn them as key concepts of Agile.

Begin with valuing individuals and interactions over processes and tools. This is perhaps the most important value, and it highlights a common complaint about many Project Managers. According to many involved in Agile Development, traditional Project Managers often lack technical skills dealing with the product or service of the project. This causes them to rely far too much on process and tools to fix problems when they arise. The key is to always remember that projects are about creating business value. The processes, tools and techniques we choose to use to create that value are simply means to an end. Without the end they have no value.

The second value statement is that we value customer collaboration over contract negotiations. This value statement highlights the importance of the Development Team working directly, and daily, with the business stakeholders to

Kent Beck Mike Beedle

Arie van Bennekum Alistair Cockburn

Ward Cunningham Martin Fowler

James Grenning Jim Highsmith

Andrew Hunt Ron Jeffries

Jon Kern Brian Marick

Robert C. Martin Steve Mellor

Ken Schwaber Jeff Sutherland

Dave Thomas



Page 38

deliver value to the business. Rarely does the Development Team understand the business need as well as the customer. Furthermore, the customer is the final arbiter of whether or not the team has delivered the right product or service. Therefore, to succeed the team must constantly talk to the stakeholders. In most cases, this means DAILY! Contracts are important, and many projects require them. However, when the team gets caught up in the legalese of what a contract says, they loose site of truly meeting the customer’s needs. At the end of the day, the important thing is to meet the customer’s needs.

The third value statement is we value responding to change over following a plan. This statement often causes an immediately negative knee-jerk reaction from traditionally trained project managers. “Ah ha!” They exclaim. “Here it is. Agile Development leads to chaos because it doesn’t allow for planning or plans. We can’t live this way! We must be able to tell people what’s coming next.” Unfortunately, this is a complete misunderstanding of what the statement says or how most Agile methodologies work. Agile projects absolutely have plans and processes. However, these processes and plans are set up in such a way that they can quickly evolve and change as the team learns new information. It is this ability that significantly differentiates Agile development from other methods for managing projects. Do not misread this value. It is not a license for a no planning free-for-all. Agile requires plans and processes. In many cases, activities are planned to the daily level—a much smaller unit than many traditional projects use.

The final value statement is that the Agilist values working software over comprehensive documentation. This statement takes us back to the importance of delivering real value to the organization as opposed to simply producing a lot of paper to show that people worked hard. The fact that people working hard does nothing for the business. It is all about providing value.

As you examined these four values how many of them did you find yourself agreeing with? I hope all of them. These statements provide common ground for all Agilists, but should be agreed upon by all project leaders, regardless of methodology.

The Agile Manifesto follows these four value statements with 12 principles. These principles provide practical implementation guidance to teams attempting to execute projects using Agile. They also provide the basic ground-rules by which the team agrees to live. As you go through these rules, again try to ask yourself, “Do I agree with this at a foundational level?”

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. This statement says it all. The highest priority, the most important thing is delivering value to the customer. In the early days, the Agile community was almost entirely software developers, so naturally the product was software. Today, Agile has extended to many different industries, so it often makes sense to replace “valuable software” with “valuable product, service or result.”

Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. We

Slide 39



Page 39

made it all the way to the second principle before things blew up! I hear project managers constantly complain about scope change. It’s almost a daily occurrence. “We would have succeeded if it wasn’t for the customer making all those last minute scope changes.” This statement ignores the fact that it is the customer’s right to demand scope changes so long as they accept the impacts. The problem is that too many teams use processes that make change difficult at best. This is a real key to Agile development’s success. It make change easy — or at least easier — even late in the process.

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. Remember, Agile development is focused on being iterative. This means loops of repeated processes. The large number of loops affords the team the opportunity to learn from the past. As the team executes more and more loops, they are able alter their processes to better deliver business value. However, the key is that at the end of each iteration the team MUST deliver a potentially shippable increment. With a timescale of only a few weeks to a few months, the team is limited in how much functionality they can produce. This means the team must produce a small amount of functionality that has value to the customer, present it to them, and allow the customer to comment on that functionality. The team then adapts to the feedback, makes changes, and moves to the next iteration. A common phase used to highlight this process is “fail fast.”

Business people and developers must work together daily throughout the project. When it comes to the real world of implementing Agile development, no principle creates as a great a hurdle as this one. It means that every single day for the length of the project the business is required to provide one or more resources to work closely with the Development Team. For many organizations this is the polar opposite of how they normally work. In most cases, business stakeholders are accustomed to throwing their requirements over the metaphoric privacy fence and then walking away from the project. This is done for a few reasons. First, there is a belief that to do otherwise would step on the feet of the Development Team. Second, they are too busy with the business of the business to spend time with the project team. The result of these attitudes are projects that fail to meet customer expectations. As we discussed above, a key advantage of Agile development is that it is iterative. This means the team gets to show the product to the customer over and over again during the duration of the project to receive feedback and improve what they are creating. However, that is not enough to ensure efficiency. So Agile extends the practice by integrating the customer into the team. In Agile development, the customer sees what the team is doing every single day. There should rarely, if ever, be any surprises at the end. Each day the customer has the opportunity to see the direction the team is going and make adjustments as needed. This prevents a lot of miss-steps and rework, but it is not free. The requirement is the customer must dedicate resources to the project just like the team—and in many organizations this is incredibly difficult to do.

Build projects around motivated individuals. Give them the environment



Page 40

and support they need, and trust them to get the job done. Are you feeling warm and fuzzy yet? This principle should not just be an Agile principle. It is a principle to which every project team should subscribe. Organizations succeed or fail because of people and not because of processes or tools. Great organizations and leaders understand the importance of finding great people and then trusting them to figure out the best way to get work accomplished. Agile development draws special attention to this concept by setting up systems where the customer owns the defining of requirements, while the Development Team owns the power to define how they will complete the work. This means that no executive or project manager assigns specific resources to specific tasks.

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. Here is a news flash. E-mail is a terrible vehicle for most communication needs! Since its inception, Agile development has understood this and pushed for better ways of sharing information. Broadcasting status reports via email, or attempting to collect requirements electronically are examples of using e-mail poorly, but there are many more. Agile development pushes teams to work closely and be co-located. If you are not familiar with the term CO-LOCATED it is important that you learn it. It means all the members of the group are physically sitting in the same location. This is why you can often quickly pick out an organization that is using Agile development: the Development Team is all physically located in a single conference room or central area. Being co-located affords the team a number of advantages. First, team members can quickly turn and talk to compatriots when they have issues. Second, information quickly gets dispersed using OSMOTIC COMMUNICATION. This is where information is absorbed by team members simply by being in the room when it is shared. Finally, information moves between parties much more quickly through the use of INFORMATION RADIATORS when the team is in a single location. We will discuss this last term in a later section of the course.

Working software is the primary measure of progress. Many stakeholders and not just Agilists would argue that far too often projects fail to deliver tangible results that benefit the business. This is not necessarily a problem with a linear methodology. Instead, it simply represents poor project management. This happens whenever a team is more focused on its process than the business results. The focus of every project must be delivering business value. This means the physical, tangible product, service, or result of the project. Since Agile development was originally proposed by software developers, this requirement is logically about working software.

8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. Eventually, there had to be a bit of marketing right? Well, here it is. Agile development promotes sustainable development. What the heck is that, and why should you care? First, it is more than just marketing. Although there is a bit of that here. The real issue is something many resources have



Page 41

experienced over the years. If you have ever been part of a project that starts out slow where many team members have nothing to do until the end of the project when everything becomes a crisis and a mad dash to the finish line. During these late periods, team members are expected to work significant overtime and often their personal life struggles in order to deliver the project. This cycle repeats itself time and time again until the resources eventually burn out and leave the organization. Agilists argue that this pace is not only unsustainable, but also unnecessary. A better approach they contend is to use Agile processes that increase the daily productivity throughout the entire lifecycle of the project thereby reducing or completely eliminating the mad dash crisis at the end. This pace is often referred to as the HEARTBEAT OF AGILITY and will be discussed in a few moments.

Continuous attention to technical excellence and good design enhances agility. To truly deliver business results the team must focus on not only an understanding of the business need, but the specific technical areas of the project. The Development Team must ensure they are delivering technically strong solutions that are well designed and actually meet the intended purpose. This concept is sometimes referred to as FITNESS FOR PURPOSE. The idea is that the solution must be capable of solving the customer’s business problem.

Simplicity - the art of maximizing the amount of work not done - is essential. Simplicity is a critical Agile concept. It is the notion of implementing the least complex solution that works at all times. Think of this idea as being like climbing a ladder. You only climb to the next rung of complexity when the Team has determined that the simpler solution represented by the lower rung does not work. The Team then moves on to the next feature or requirement and only adds complexity when there is not a simpler option available that works.

The best architectures, requirements, and designs emerge from self-organizing teams. The best solutions come from teams that are not forced to accept specific roles. A team reaches its maximum efficiency when they are able to go through a natural process such as the TUCKMAN MODEL. In this or other similar models, team members come together and determine their own natural working relationships. External individuals are not allowed to dictate how the team operates. When the Team is able to find its own way they end up producing better architectures, requirements and designs, which ends in them producing better products, services or results.

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. Introspection is a key aspect of any Agile team. Unlike linear approaches to project execution where the Team typically does a single release, Agile development cycles repeatedly. This gives the customer lots and lots of opportunities to comment on the work product. It also provides the Team many opportunities to learn. With every loop, the Team has a chance to execute the basic process. At the end of that process most Agile methodologies provide some kind of reflection process



Page 42

where the Team is tasked with examining their performance in the cycle and determining the best way to improve before moving on to the next iteration. This reflection period is absolutely critical. It recognizes that the Team is never perfect, and there are always improvements to be made. It moves the concept of continuous improvement from some abstract theory we say is important into something we at regular intervals focus on and actually do something about.

The Heartbeat of Agility

Earlier, the Heartbeat of Agility was mentioned as a key aspect of developing an Agile cadence or pace. The notion of cadence is absolutely critical to an Agile team. It is all about establishing a rhythm that is comfortable and sustainable by the Team. This rhythm differs from what many teams experience in the real world where they often experience slow periods of production throughout most of the project only to be forced into a mad dash at the end in hopes of delivering business results. Typically, the team fails to meet the deadline, is burnt out, and has left a frustrated customer. Agile processes attempt to solve this problem by increasing the daily productivity of the team. The goal is to have a higher rate of daily productivity and avoid the massive spikes experienced by the team. This notion does not argue there are no spikes, instead it is about creating much smaller, regular spikes that are within the realm of sustainability.

Must, Wants & Needs

Earlier in my career when I first began investigating Agile development, I struggled to understand its advantage over more linear approaches. As I looked around the dozens of projects I had visibility to, most of the Agile ones had failed to deliver all the features specified in lengthy scope and requirements documents. “Isn’t it the job of the team to deliver all these requirements?” I thought. Unfortunately, I was missing a key piece of information necessary to fully

Slide 40

Slide 41



Page 43

Slide 42

understand this issue. According to the Chaos Chronicles, only about 36% of all features are regularly used. Another 19% of a software project’s features are rarely used, and a full 45% of a software applications features are never used at all. Why does this matter? It matters because far too often project teams force stakeholders to wait for the important, must have features because they are trying to produce features that will never be used. This makes no sense, but is a function of the process. Most linear processes play a zero sum game. You either get all the requirements or you get none. To make this game worse, teams often sacrifice the quality of their product to hit a deadline imposed by the customer. They deliver all the requirements, but the package is not fully tested. So not only does the customer have to wait until the last possible moment for those all important features, but they also get them in a substandard fashion.

Agile development addresses this problem in two ways. First, most Agile methodologies require the customer or key stakeholders to prioritize the requirements from most important to least. The Team then makes every effort to deliver the features in the defined order. At the end of the project, when the Team is at the deadline, there will still likely be a number of features or requirements that are incomplete. The difference is that these are the least important ones. This puts the customer in a position of great power. Now the customer can decide whether or not they want the team to continue the project in order to deliver these minor features. In a linear process, the customer is stuck. They have to continue the project because if they don’t they get nothing of value. In Agile they have the most important items and get to decide how much the lessor items are really worth to them. Secondly, Agile development gives the customer the most important features earlier in the process. This means they are able to begin using the mission-critical features as soon as they are done, without waiting for lessor features. Finally, Agile development forces business stakeholders to make hard decisions like spend more money and time or not. It forces a hard discussion around those never-used features in a highly visible way. As a result, it becomes far more difficult to sneak a feature or requirement into the process at the end.

Key Terms There are a number of basic Agile terms you need to know before we begin our discussion of the various methodologies within the Agile family. These include:

Pairing – Two developers working together at one workstation. One writes the code while the other reviews each line as they go.

Swarming – The entire team swarms around a single feature or story e.g. everyone works together on a single story or feature at the same time. It sets a WIP limit of 1.

Mobbing – Combines the concepts of pairing and swarming. The entire team works off of a single keyboard on a single feature.

Mini-Waterfalls – team addresses all of the requirements in a given period, then attempts to do all of the design, then moves onto do all of the execution.



Page 44

Fishbowl window – Long-lived video conference link that allows non-collocated team members to watch each other throughout the day to reduce collaboration lag.

Agile Methodologies Today there are more than 16 different methodologies that are considered part of the “Agile” family. Some of these like to refer to themselves as “frameworks”, but I tend to refer to them as methodologies as I believe they each have specific rules and processes that must be followed. The framework is found in the PMBOK® Guide. The most common of these methodologies include Scrum, Extreme Programming (XP), Feature-Driven Development (FDD), Dynamic Systems Development Method (DSDM), and the many forms of Crystal. Two less common—but no less important—closely related methodologies include Lean Software Development and Kanban. The PMI-ACP® exam focuses most of its attention on Scrum and Extreme Programming, but provides potential coverage on each of these concepts. Therefore, the rest of this chapter will cover all of them in order to ensure your full preparedness. It is a lot of information, but the key thing is to be able to point out the differences, rather than to understand all the nuances of each.

Scrum Scrum is far and away the most popular Agile methodology globally. It was first defined as “a flexible, holistic product development strategy where a development team works as a unit to reach a common goal” as opposed to a “traditional approach” (i.e., linear approach such as Waterfall) in January, 1986 by Hitotaka Takeuchi and Ikujiro Nonaka in “The New New Product Development Game” published in the Harvard Business Review. This article described a new approach to commercial product development that they argued would increase both speed and flexibility. The article was based on their examination of case studies in the photocopier and printer industries. They called this the holistic or rugby approach. The idea was to create a single, small cross-functional team that possessed all, or at least most of the skills required to complete the project. The idea was that this team would work on the project across multiple overlapping phases constantly passing work back and forth until complete.

In the early 1990s, Ken Schwaber used a version of this approach at Advanced Development Methods while Jeff Sutherland with others developed a similar approach at Easel Corporation. Sutherland is believed to be the first to refer this approach as “Scrum.” In 1995, Sutherland and Schwaber jointly presented a paper describing the “Scrum Methodology” at the Business Object Design and Implementation Workshop held as part of the Object-Oriented Programming, Systems, Languages, and Applications ‘95 Conference in Austin, Texas. The two continued to work together for several years to bring together their ideas on Scrum until in 2001 when Schwaber published Agile Software Development with Scrum with Mike Beedle. Schwaber later founded the Scrum Alliance with other Agilists, and created the Certified Scrum Master (CSM™) program. In the fall of



Page 45

Slide 43

2009, Schwaber left the Alliance in a very public disagreement and founded Scrum.org with Alex Armstrong. Scrum.org offers the Professional Scrum Master (PSM™) program.

Scrum is based on two aspects of the industrial process theory: self-organization and emergence. Self-organization is the idea that the Development Team will decide what work needs to be accomplished and who will do the work to deliver the desired business results. Emergence is the idea that information, requirements, and facts will emerge as the project progresses. The key is that the team uses processes, tools, and techniques capable of harnessing this new information for the betterment of the organization.

The creators of Scrum argue that traditional linear approaches for projects such as Waterfall are based on the concepts of defined processes. Defined processes are repeatable processes such as you find in manufacturing. Imagine working at the Acme Widget Factory. In order to produce widgets of a consistent level of quality it is imperative that our machines stamp and assemble each widget the same way. The more consistently we can stamp the widgets, the less variance we see in the finished product. As we move forward we also try to increase the rate of production. With smaller and smaller variances and greater and greater production we are able to take our widget production to a point where we commoditize the production of widgets. Commoditization is defined as the process in which goods that have economic value, and are distinguishable in terms of attributes (uniqueness or brand), end up becoming interchangeable in the eyes of the market or consumers. This also means our widgets become easy for the consumer to obtain because we have made them uniform, plentiful and affordable. Our widgets are like laundry detergent. If you go to most major grocery stores you find an entire row of detergents. All of them priced similarly and they are all largely indistinguishable from each other. They cost the manufacturer little to produce, and their profit margins are small. In manufacturing this is mostly a good thing. The lag time between when we are able to reduce the cost of production and when the consumer recognizes our product as a commodity affords maximum profitability. However, such processes in project management are not good.

To understand why, we first must understand how projects relate to the overall operation of the organization. In any organization, regardless of its purpose, there are only two types of things occurring: the first is operations and the second is projects or new initiatives. The purpose of operations is to keep the organization moving forward. Operations are all about repetition or doing the same thing over and over again while constantly seeking to become more efficient and to squeeze just a little more cost out of the process. This is possible when we produce the exact same thing day after day. A defined process is perfectly tailored to operational management because we want people to follow the exact same steps day after day. Projects, or new initiatives, are a very different animal. They are all about creating something we haven’t had before. They are about creating something new and in some way different. By this definition, the processes we used to execute the last project won’t necessarily work with the next project.



Page 46

Success relies on flexibility, and flexibility requires a different way of doing things. Projects have the greatest chance of success when empirical processes are used.

Empirical processes are used in situations where it is difficult to have consistent processes. Therefore, empirical processes focus on creating a situation with the highest likelihood of success using three primary drivers.

Visibility – The aspects of the process that affect the outcome must be visible to those controlling the process, and what is seen must be true. The team cannot successfully manage or optimize that which they cannot see. Therefore, the first key is to ensure the team can see all pertinent information.

Inspection – The various aspects of the process must be examined frequently enough that any unacceptable variances in the process can be detected. It is not enough to say you can see what is going on in a process. The team must also regularly examine all aspects of that process so they can determine when variances are occurring that are beyond what the team has determined is allowable.

Adaptation – If one or more of the processes are determined out of control, the processes must change. Once you can see the drivers in a process and have taken the time to examine those variables to ensure you know which variables are in control and which ones are not, the only thing left is to fix those processes that are not performing as expected. This step is called adaptation.

Scrum Roles Scrum is both infinitely simple and incredibly powerful. Learning Scrum requires you to know its three roles, four artifacts or documents, and five meetings. That’s it! We begin by describing the three roles of Scrum.

The first role is the Product Owner or PO. The PO is the individual responsible for representing the interests of all stakeholders, obtaining funding, defining the initial requirements, defining the return on investment or ROI, and the project objectives. They are the primary owners of the Product Backload, which is a document where the User Stories, features, or requirements of the project are listed in rank order from most important to least important from the perspective of the business. The closest term in the PMBOK® Guide to the Product Owner is the Project Sponsor, but there are some differences. Theoretically, a Sponsor exists as the all powerful leader. They give the Project Manager and their team the authority they need to execute the project. The rule when discussing a Project Sponsor is that you want the most powerful one you can find because the Project Manager is only as powerful as their Sponsor. This concept creates a hierarchical structure and a direct reporting relationship from the Sponsor to the Project Manager, and then to the team. In Scrum, it is not assumed that the PO is this all powerful entity. Instead, we simply say that the Product Owner is responsible for certain areas. This means that the PO either has the direct authority to provide the funding and other items, or they must go into the greater organization and obtain

Slide 44

Slide 45



Page 47

those things. Scrum doesn’t care which. When the Development Team needs more information about a User Story, they rely on the Product Owner to either know that information or ensure that the correct people are in the room to provide that information.

The second role is the Development Team. In earlier Scrum writings, this role was referred to as simply the Team. This is the small group of people who actually do the work to deliver the product, service, or result of the project. The Development Team is self-managing, self-organizing, and cross functional. The team does not have a Project Manager or functional leader who directs the team’s efforts. The Development Team is also small. According to the rules of Scrum, the team size is six plus or minus three. This puts the optimal team size somewhere between three and nine individuals. This is an important aspect of Agile development. Research has repeatedly shown that smaller teams are much more successful than larger ones. Scrum also defines the Development Team as being multi-functional, meaning that it contains all the skills the team needs to complete the work of the project. Furthermore, the team is 100% dedicated to one and only one project. This notion of a team is often difficult for people who are new to Agile Development, especially the idea of a team being dedicated to one and only one project. “How is that even possible in the real world?” They ask. It works because the typical Agile team is much smaller than teams in traditional projects. It is still the same total number of total people in the organization, but by breaking the whole into smaller independent teams the organization is able to divide and conquer.

The third and final role is the Scrum Master. The Scrum Master is responsible for the Scrum process, teaching Scrum to everyone, implementing Scrum so it fits with culture, and ensuring that everyone follows Scrum’s rules and practices. The closest approximation of this in a linear framework is the Project Manager, but there are some key differences—at least from the perspective of the Agilist. Most Agilists believe that traditional Project Managers are only part of hierarchical organizations with the project manager at the top. All the resources report to the PM. Additionally, this person serves as an administrator directing the team, but having no technical skills or knowledge of the project. This is a huge over simplification of the role, but makes for a nice comparison. A Scrum Master serves as a facilitator. Remember, a Scrum Development Team is self-managing. The expectation is that the Scrum Master role is to only help the team, to ask probing questions, to ensure the team knows the Scrum process and follows it. Development Team members report to each other and not the Scrum Master so the Scrum Master has no formal authority to make anyone do anything.

Throughout much of the literature (and in this book) a fourth role is added to the list that is not officially part of Scrum but is often unwittingly included. It is The Team. The Team is different from the Development Team because it includes all three Scrum roles. It is defined as everyone involved in delivering the project. It is the Product Owner, the Scrum Master and the Development Team together. As we go through the rest of this discussion it is important that you can differentiate the Team from the Development Team.



Page 48

Everyone involved in the project fits into one of these three roles. For many, this is a bit disconcerting. What do you do if you are a Business Analyst or quality assurance person? How do you fit in when there are only three roles and you aren’t one of them? In most situations, these additional roles are included as part of the Development Team. They represent other resources needed to complete the work of the project. However, occasionally they also might fit in to the organization as resources used by the Product Owner to define the requirements of the project.

Although all three Scrum roles are critical to project success, they are not all created equal. Significantly more is offered and expected from the Development Team. Often Agilists use an acronym to describe the expected behavior of the Development Team. It is CFORCE. The C stands for Committed. An Agile Development Team must be committed to the Team’s goals and to the other members of the Team. F stands for focused. This criteria goes back to an earlier point. A Development Team must be focused on one and only one project. O stands for open. Each member of the team must be open to receive and provide honest criticism intended to improve the project and the team. Team members must always assume the positive intentions of their compatriots. R stands for respected and respectful. This requirement is also tied to how team members treat each other. It is expected that each team member is a respected part of the organization and that they respect all the other members of the team. Team members must give respect in order to receive it. The second C stands for courageous. The team must take risks, find innovative solutions, and focus on finding the best solutions to meet the needs of the business. Finally, we have the E, which stands for extreme. Scrum calls on the Development Team to be zealous in the pursuit of the mission.

Scrum Artifacts

We have now covered the three roles found in Scrum so it is time to move on to the four documents required to implement Scrum. The first of these documents is called the Product Vision. Most people are familiar with this document by another name, the Project Charter. Many Agilists would contend that the two documents are not the same thing, but this has more to do with the fact that many project managers fail to create proper charters than with the actual comparison. The Vision sets the direction of the project and guides the Scrum Team. In 2004, Schwaber described the Vision this way, “The minimum plan necessary to start a Scrum project consists of a Vision and a Product Backlog. The vision describes why the project is being undertaken and what the desired end state is. (Schwaber 2004, p.68) A well formed Vision is a single page document that answers a number of questions. These questions cover five major areas.

The Business Need — This question is sometimes referred to as the problem statement. What is the problem the business needs solved? This can be a very broad topic that includes questions such as who is going to buy the product or who is the target customer? Successful projects solve a point of pain for the business. Someone has to need the thing produced by the team for it to have value. These questions and others must be answered by the business: How

Slide 46

Slide 47



Page 49

Slide 48-50

does the product created in this project compare to existing products of either competitors or our organization? Or, what are the product’s unique selling features?

Project Justification — It is not enough to simply solve a business need. That need has to be significant enough to warrant spending time and money to solve it. Projects exist in a competitive landscape. The business must be able to explain why focusing on this project is the best expenditure of the available resources.

Success Criteria — This is where the rubber hits the road. It answers the question, How will we know when we are successful? It is where the business defines the attributes that are critical to satisfying the business’ needs, and the overall success of the product. The measures must be quantifiable and objective to prevent different people from interpreting the project’s results differently.

Prioritization — This area is all about determining how the project fits into the landscape of all the other projects going on within the organization. This is critical information for the team to know. Understanding where a project rates versus all the other work the organization is trying to accomplish informs the team about the level of support they are likely to receive. It is also a good idea to understand how the Product Owner values the three legs of the triple constraints. This will also provide guidance about what the PO is truly expecting from the project.

Constraints and Assumptions — This last area provides critical information for the Development Team because it allows the business to define the limitations within which the team must live. This includes issues like budget limitations, time constraints, and technology or resource limitations.

A common way to validate your vision is to answer the elevator test. Can you explain the product, service, or result of the project in the time it takes to ride up in an elevator? (Moore 2006 p. 152). No project can begin without a vision. It is how the organization recognizes a potential project exists. Regardless of methodology, every project should have a correctly formed Product Vision.

The second document in the list of four is a Ranked Product Backlog. More often than not, the literature talks about just the Product Backlog. A Product Backlog is a listing of the User Stories, features or requirements. These items are often referred to as Product Backlog Items or PBIs. The key is the word “ranked.” Ranking the backlog requires the business to prioritize the items in the Backlog from most important to the business to least important. Sometimes the Backlog is further grouped into User Stories that belong together. The Development Team uses the Backlog to define which features to deliver when. Each of the items on the Backlog exist relatively independent of each other. Additionally, the items on the Backlog may be reprioritized at any time.

Before moving to the Scrum process, there are a few additional pertinent terms that must be introduced.



Page 50

User Stories — A story is a self-contained unit of work agreed upon by the developers and the stakeholders. Stories are the heart of Scrum, and the building blocks of each sprint. Each User Story must be producible in a single sprint. Often, this requires the Development Team to break Stories down until they fit into that length of work. Additionally, each story must provide functionality that has real value to the business. A User Story is different from a feature, however. A feature represents a distinct element of functionality that provides capability to the business. A User Story, on the other hand, is a small aspect of a feature that is used to get feedback from stakeholders and find out if the team is doing anything wrong. In the real world of implementing Agile, the two terms are often used synonymously. Later in this book, in the Stakeholder Engagement chapter, we will discuss User Stories in greater detail.

Themes — Themes may be thought of as groups of related stories. Often the stories all contribute to a common goal or are related in some obvious way, such as focusing on a single customer. Sometimes stories within a theme may be dependent on each other, but they do not necessarily encapsulate a specific work flow or need to be delivered together.

Epics — Epics resemble themes in the sense that they are made up of multiple stories. Sometimes they also resemble stories in the sense that may appear as a big story. Unlike themes, epics often comprise a complete workflow for a user and they typically cut across all or some of the three business dimensions (time, scope and organizations). Another important difference is while the stories that comprise an epic may be completed independently, their business value isn’t realized until the entire epic is complete. This means that it rarely makes sense to deliver an epic until all of the underlying stories are complete. In contrast, while stories comprising a theme are related, each is independent enough to be delivered separately and still provide some measurable sense of business value. A related rule of thumb is to automatically break down any story that is estimated above a certain threshold. A good starting point for this threshold may be where your team has historically tended to become inaccurate with their estimates. Epics are most often seen when teams are implementing SAFe as they are often used to enhance business value of the FULL solution set or bring a range of technologies together. They are often the key economic drivers for the portfolio,

Rocks — Rocks are pieces of functionality used as placeholders when there is an absence of information. The rock acts as a signpost signifying that the team needs information about a feature or requirement.

Sprint — A sprint is a short iteration of fixed time where features are produced that have tangible value to the customer. The original Rules of Scrum stated that each Sprint was 30 days in length. However, over the years Scrum has adopted the practices from other Agile methodologies and the common practice is to see sprints of somewhere between two and six weeks long. The key is that each sprint must be the exact same fixed length size, and each MUST produce fully tested functionality that has real value to the customer.



Page 51

Slide 51-52

Release — A release is a group of related sprints. Releases become necessary for a variety of reasons. The Rules of Scrum require every sprint to provide fully tested, production ready features. However, there are many situations where it is either impractical or ill advised to put the features completed from a single sprint into production. Imagine an organization that has set release windows where new code can be put into the production system. In these situations, the Development Team simply places the results from sprints “on the shelf” until all the features that are part of the Release are complete, and then the entire group of features is placed into production together.

The other two artifacts that make up the four artifacts of Scrum are the Team or Scrum Board and the Burndown Chart. A fifth that is occasionally included, but does not nicely fit into the memory jogger is the Sprint Backlog. Each of these are introduced later in the course. Let’s take a look now at the basic Scrum process. This process is relatively simple, but it is critical that it be followed exactly for one to gain the benefits of Scrum. The most commonly cited source for these rules or guidelines is the Scrum Guide, which is available from the Scrum Alliance, or Scrum.org. It is also often provided as an appendix in most books on Scrum.

Scrum Process

Every project begins the same way. Someone creates a Vision and a Ranked Product Backlog. Some students expect the Scrum Guide to provide specifics on how to develop these two documents, but they are not in the Guide. Instead, readers are provided with a general outline of what is included and then left to their own devices to find the best way to achieve the desired result. Books on User Stories, by Mike Cohn and others attempt to fill this gap but it is still a problem for some. Rather than making a mountain out of a mole-hill, I will provide you with a high level process that is often used in the real world. Just imagine someone in the organization has a problem and that they complete a single page document to starts the ball rolling. This is the Vision. Next, some type of governance decides that the idea has merit and assigns a team to do some something about it. The Development Team conducts an initial kickoff meeting with the Product Owner and key stakeholders to develop the Ranked Product Backlog. Once the Development Team has the initial Backlog they enter the Release Planning Meeting.

The Release Planning Meeting serves several purposes. The Development Team first uses the meeting to examine the backlog items to determine how they need to be grouped together into releases. Additionally, the team determines how long each sprint needs to be. Remember, each User Story must fit into a single sprint. So the Team must find a sprint length that is as short as possible, but long enough to deliver fully tested, production ready results that have real value to the business. To do this, the Team must determine estimates for each PBI. There are a number of techniques commonly used for this purpose that are discussed later in this book. The estimates are used by the Development Team to ensure each sprint is approximately the same size. Once the Development Team has determined how long the sprints will be and how the sprints will be grouped into releases, the team is done with the Release Planning Meeting. Approximately once a quarter the team must revisit the Release Planning Meeting.



Page 52

The next step in the process is the Sprint Planning Meeting, which happens at the beginning of each sprint. As you might have guessed, the purpose of the Sprint Planning Meeting is to plan the work of the current Sprint. It officially kicks off the sprint. The meeting is broken into two parts.

The Team begins the meeting by examining the Ranked Product Backlog led by the PO. Their goal is to produce the features that are most important to the business first. That means they take the maximum number of items they can produce in a single sprint. They chose the items by starting at the top of the list and working down until they have all they can reasonably complete. There are a number of factors that can limit this production, but let’s keep it simple for now. Sometimes, as the Team examines the Backlog, they discover there are User Stories that appear lower down the Backlog that should be pulled up to the current sprint because they relate to the current work in some way, make it easier to produce future items, or are just easier to produce right then. It is perfectly acceptable to occasionally pull those items up so long as it is an exception and not the rule. In addition to selecting the User Stories to be produced in the current sprint, the team must also get a lot more detail about those items. The process of gaining more detailed information about a story or backlog item is called Backlog Grooming. During Backlog Grooming, the product backlog items are defined in enough detail that the Development Team can build the story. This is a process of defining the requirements, and it is expected to take half the meeting.

The second half of the meeting is used to break apart the now well defined PBIs into the tasks needed to complete the User Stories. This is also when the Team defines the task order and takes note of any dependencies or specific resource requirements. Earlier we established the rule that no User Story could be larger than a single sprint. Now we establish a similar rule concerning the size of the tasks used to deliver the PBIs. The rule is that not task can be larger than a single day. Some sources say that no task can be larger than two days. The problem I have with this two-day alternative is that it fails to align with Scrum’s measurement system, the Daily Scrum. I prefer to say that each task must either be a whole-day or a half-day. No other options are allowed. This means the exacting estimates of “X” number of hours are completely unnecessary.

The first half of the meeting requires heavy involvement by the PO. However, the second half does not. Remember, the Development Team is self-governing, so there is no need for a Project Manager or Product Owner to tell the team members what tasks they should do. Each sprint then becomes a small project with a fixed duration. The Development Team’s plan must include all the resource requirements, dependencies, task order, and any other necessary information to complete the work. This plan is documented using a visual posted in a War Room called a Team or Scrum Board. The Scrum Board is recreated for each sprint. In the original Rules of Scrum, the Sprint Planning Meeting was expected to take a full work day. However, in the real world where sprints average between two and three weeks, the Sprint Planning Meeting rarely takes longer than four hours. Once the Development Team has created their Scrum Board they end the Sprint Planning Meeting and begin executing what they just planned.

Slide 53



Page 53

54-55

The goal of the execution phase in Scrum is to produce the just-defined User Stories by the end of the sprint. These features must be fully tested and truly ready for production. Remember, part of the Release Planning Meeting process was to determine how long the sprints needed to be so the Development Team had enough time to produce a potentially shippable increment that was fully tested. This means we test and test in every sprint. This process often limits the number of features we can produce in each sprint, but it also tends to produce a better finished product.

To reach our goal, the team uses a standard process every single day to complete the desired work. This is where Scrum really adds value to organizational performance. The early leaders of Scrum learned an obvious lesson that is often missed by their linear project management cousins. In more linear projects, the team often struggles to determine whether or not they are in trouble and to then react to the challenge. This happens because of the basic mechanisms used to report progress. In most projects, reporting is done on a weekly or alternating week basis. The team comes together either via a conference call or physically, and is asked report on where they are with their tasks. The most common answer is, “right on track.” If a numeric value is required, the most common value is 90%. Yet, somehow it always takes twice as long to do the last 10% as it did the first 90%. Furthermore, no one reports that they are behind until it is the last possible second when they suddenly discover they can’t meet the deadline. This all happens because of the reporting model. It is not because of bad people! It is a problem with the project measuring increments. If the team is working on a project expected to take several years to complete it is likely OK to have every other week or weekly reporting. However, when the project is a year or less, that is likely not frequent enough. Scrum figured out long ago a lesson that most of us consider common sense: Smaller things are much easier to manage than larger ones. One of the reasons Scrum works is that it aligns its measurement with reporting frequency.

Every day in a Scrum project the team uses the same process. This is part of what creates its cadence. Each day begins with a meeting called the Daily Scrum. This is a ten to fifteen minute meeting that provides the Team with the basic project information. Many other forms of Agile development also use a Daily Standup to position the team for success. In iteration-based Agile lifecycles like Scrum each day the Development Team stands around the Scrum or Team Board and answers three questions:

What did they accomplish yesterday?

What are they going to accomplish today?

What impediments do they have?

In flow-based Agile methods the team stands around their Kanban board and answers four questions:

What do we need to do to advance this piece of work?

Is anyone working on anything that is not on the board?



Page 54

What do we need to finish as a team?

Are there any bottlenecks or blockers to the flow of work?

In iteration-based Agile the focus is supposed to be on the second and third questions as the first is historical and there is no chance to impact it in iteration-based agile. Flow-based Agile focuses on the first and fourth questions again because they are future focused and will have the greatest impact on the outcome.

Each member of the Development Team reports their results to the other members of the Development Team and NOT to the Scrum Master or Product Owner who are also present. The Scrum Master is tasked to act as a facilitator and the PO is only present an observer. As each Team member reports their answers to the three questions they move physical representations of the tasks on the Team Board. The team is allowed to spend a quick moment or two solving simple problems, but cannot get sidetracked as the meeting is only allowed to take 10 to 15 minutes. Once each member of the Development Team has answered their three questions, the meeting disbands and everyone begins working on the tasks for that day.

While the Development Team works to produce the days results, the Product Owner works on grooming yet undefined User Stories for future sprints while also working with the Scrum Master to remove impediments. No one from the business may add a feature to the current sprint once work has commenced, but they can add, delete, or change items on the Product Backlog at their discretion. The Development Team occasionally has to take User Stories out of the current sprint when new information is learned. They can also pull up a new item if the situation warrants such action.

On the last day of each sprint two meetings are conducted. First, the Team conducts a Sprint Review. This meeting lasts one hour to 90-minutes and allows the Product Owner to present the results of the sprint to the customers. This is all about showing a working product to the people who will really use it. The Development Team wants the product owner to take this responsibility because it both provides a connection between them and the users and it helps to ensure their engagement throughout the sprint. The Team is allowed a few hours to prepare for this meeting.

Once the Sprint Review is complete, the complete Team conducts a Sprint Retrospective. If the Sprint Review is all about the product of the project, the Sprint Retrospective is all about the process. The Product Owner is allowed to attend the Retrospective. However, the Scrum Master is only present as a facilitator. This meeting provides the Team with the opportunity to review the past sprint and find the best way to improve the process. The team uses a wide range of games and tools to answer the question, “If tomorrow we were 1,000% more efficient what did we do to get there?” They focus with single pointedness on the process the Development Team uses to achieve their results.

The next day the process begins again with a new sprint and the Sprint Planning Meeting until either the Development Team delivers all the promised functionality or is out of time and money, at which point the Product Owner must decide to close the project or obtain more. That is all there is to the basic Scrum process.

Slide 56

Slide 57



Page 55

Slide 58-59

Slide 60

Slide 61

However, before we completely leave Scrum, lets spend a minute and add a few connected ideas that are often added to Scrum as the team becomes more advanced.

The first if these ideas is a revisit of a previous topic. If you remember, several pages ago we discussed Work In Progress or WIP. Managing WIP requires the Team to limit the number of tasks they work on in a single moment based on priority. However, none of the Scrum tools we have discussed so far force this to occur. One tool that is often added to Scrum to achieve this desired result is Kanban. We are not going to introduce Kanban here, we will just describe its implementation with Scrum.

Within the Team’s Scrum Board, there are a series of columns that each represent a separate state in the work’s progress. When using Kanban, the primary alteration the Team makes to the Board is adding numeric values for each column. These values represent the maximum number of items that can be present in that column. The effect of these limiters is to force the Team to focus on getting tasks all the way through the process rather than allowing them to stagnate in one particular state (usually the Impeded State).

Another practice sometimes used by Scrum teams is Iteration 0. This is NOT part of Scrum found in the Scrum Guide. Remember the basic rule we established for Scrum that said every single sprint would be the same length of time and must produce functionality that has real value to the business? Iteration 0 violates both of those rules. The goal of Iteration 0 is to produce two items that do not initially have value to the business. These are the core architecture and feature list. It is common for this work to take significantly longer than a single sprint, and as such it violates the Rules of Scrum. If a team has decided to use Iteration 0 because they believe the project needs a more formal architectural plan and/or work on its feature list, it is important that the team also provides an iteration or milestone plan to ensure the team quickly moves into more standard Scrum sprints.

Extreme Programming The second major methodology is Extreme Programming or XP. XP is a methodology that introduces checkpoints when new requirements can be adopted to improve a project team’s overall productivity. It was originally created by Kent Beck, Ward Cunninghan, and Ron Jeffries while at Chrysler. Famed Agilist Mike Cohn contends that many Agile teams start with Scrum which represents a relatively loosely defined process and end with XP as they become more experienced and interested in gaining greater control over technical areas of the project. As we go through this section, I will highlight a number of differences between what we have already learned about Scrum and Extreme Programming. The first of these differences is the length of each iteration. The original Rules of



Page 56

Scrum required a sprint length of 30 days. More common practice is to see sprint lengths of from two to six weeks. XP operates with much shorter iterations of one to two weeks in length with one week being the most common.

Extreme Programming is focused on five areas:

Goals — The primary goal of XP is to produce high quality software, but isn’t that the goal of every software development methodology you ask? Yes, it is but Extreme Programming carries this goal a step further by arguing that it does this through the use of very short development cycles.

Activities — Extreme Programming defines four core activities necessary to meet its stated goal. These include:

Listening – Programmers must listen to customers and understand the business processes.

Designing – Software must be designed as components without complexity or dependencies between components.

Coding – Is the meat of the methodology. It is the most important part according to XP advocates.

Testing – The team must test a functionality.

Values — Values represent what the team hold highest. When discussing Extreme Programming, here are its core values:

Simplicity – Reduce complexity, extra features and waste. “Find the simplest thing that could possibly work” and try that first. Only add complexity when the simple solution fails.

Communication – All the team members know what is expected of them and what others are working on. This is the value of transparency.

Feedback – The team must get impressions and suitability early. It’s about “failing fast.” This requires the team to put the product in front of the customer early and often. They customer must then provide unvarnished feedback so the team can adjust and change as required.

Courage – The team has to be willing to put its work out there for others to see. It must also use pair programming and shared code. These two principles will be discussed later.

Respect – The team is accountable to each other for results. Great performance cannot be forced on a team. Members must hold each other accountable to fantastic performance.

Principles — XP focuses on two core principles that drive it.

Assume Simplicity – This is about treating every problem as if its solution were extremely simple.

Embrace Change – Do not work against change, embrace it.

Practices — Extreme Programming’s 12 practices are grouped into four practice areas. These practice areas provide the toolset used by teams implementing XP and the groupings include: Fine Scale Feedback, Continuous

Slide 62-65



Page 57

Slide 66

Slides 67-69

Process, Shared Understanding and Programmer Welfare. Most of the rest of this section focuses on these 12 practices.

The first grouping of practices is called Fine Scale Feedback. It is the notion of providing rapid feedback to each individual developer in a fashion they can actually act upon it in a timely manner. The four practices tied to Fine-Scale Feedback include:

Paired Programing — Paired Programming is used by all Extreme Programming teams. In Paired Programming two programmers work together at a single workstation. One programmer writes the code while the other reviews it and thinks strategically. At set intervals the two programmers switch roles. In Paired Programming, the pairs are not fixed and change often to keep perspectives fresh. In XP Paired Programming is NOT a developer and a business person.

The Planning Game — The Planning Game represents the main planning process used in Extreme Programming. Like the Sprint Planning Meeting in Scrum, The Planning Game is a meeting that occurs once per iteration. In most XP environments, this means once a week. There are two parts to the Game, Release Planning and Iteration Planning. Release Planning is focused on determining which requirements will be included in which near-term release and specifying exactly when they should be delivered. Both the customer and developer are part of this process. It includes three phases:

Exploration Phase – In the Exploration Phase, the customer provides a short list of high-value requirements for the system that are written as User Stories on Story Cards in the language of the business.

Commitment Phase – In the Commitment Phase, the business and developers commit to the functionalities they will include as well as to the next release date.

Steering Phase – In the Steering Phase, the plan can be adjusted, new requirements can be added, and existing requirements can be changed or removed.

The second half of the Planning Game is Iteration Planning. In this process the customer is not involved because it is where the developer plans the tasks and activities to produce the desired functionality. It also includes three phases:

Exploration Phase – The requirements are translated to specific tasks that are all recorded on task cards.

Commitment Phase – The tasks are assigned to programmers and the task durations are estimated.

Steering Phase – Tasks are performed and the results are then matched with the original User Story.

In addition to the Planning Game and Paired Programming there are two other practices used as part of Fine-Scale Feedback. These practices include Test Driven Development or TDD, and Whole Team. Test Driven Development is a



Page 58

topic we will talk about repeatedly in this course because it represents a foundational practice used by multiple Agile methodologies. Therefore, in this its first appearance our discussion will be brief. In TDD, the tests are written before any code is written and those tests are automated. Typically, the TDD process contains five steps.

The developer who will eventually write the code writes the unit tests. This is unlike most testing doctrines where someone other than the developer writes the tests and it is often done at the same time or after the developer begins writing the code.

The developer runs the test to ensure the test fails. Since no code has been written, a passed test without any code would mean a bad test.

The developer writes the minimum amount of code possible that allows the test to be passed.

The developer reruns the test to ensure passage. The developer then refactors the code removing any code smells from the

code. We will talk extensively about what this means later in the course.

The final practice found in Fine-Scale Feedback is the Whole Team. This is a basic requirement seen in many Agile methodologies. The premise is that although the customer does not always pay for the project, they are always the people who use the product, service or result of the project. As a result, the customer must always be on hand to answer questions from the developers.

The second grouping of practices found in Extreme Programming is called Continuous Process. This is the concept that the process is never done — whether you are talking about an individual release or the process itself. Continuous Process includes three practices:

Continuous Integration – Extreme Programming employs continuous integration and requires the use of a code repository. The expectation is that developers load the repository every few hours. Once the repository is loaded, integration tests are run automatically. This allows the developers to regularly get reports on how the separate components of code function together.

Design Improvement – Only write code that is needed today. XP demands that the teams work in a highly focused manner. Each day they are tasked with delivering specific functionality. This means the components must be relatively small. When problems occur in the integration of the code, the team must refactor their code to make it simpler and more generic in order to remove what is causing the problem.

Small Releases – Extreme Programming demands frequent small releases to the test environment. This concept is closely linked to Continuous Integration above. Quality is maintained through Continuous Integration, and Small Releases allow the team to quickly adapt when tests fail.

The next group of practices is called Shared Understanding, and represents the set of practices that ensure all the members of the team have the same information about the project and its product. But, as you will see from the following practices, it requires more than just access to information.

Slide 70

Slide 71



Page 59

Slide 72

Slides 73-75

Coding Standards – The Coding Standard represents an agreed upon set of rules that the entire team follows for a consistent style and format. XP advocates “self-documenting code” that reduces the need for code comments. This practice is often one of the most criticized in Agile Development. The idea is relatively simple. Write code that is so clean, well formed, and easy to understand that it does not require any additional comments. In the real world, this often leaves way to much room for error since what is obvious to the developer writing the code is often not obvious to anyone else.

Collective Code Ownership – Any pair of developers can make changes to any code, and everyone is responsible for all the code. XP uses Paired Programming to write all code. As a team of developers works, they might discover new information that requires rewriting or changing existing components to improve functionality or to make other required functions work.

Simple Design – “Simplest” is the best approach to software design. Often, software fails because of the layers of complexity that constantly get added until the application collapses under its own weight. XP attempts to peel back the layers of the onion to achieve a design that is more robust and long lasting. A common XP expression used along with Simple Design is the acronym YAGNI which stands for “You Aren’t Gonna Need It.” This expression means that something is not needed, and it will complicate things. Therefore, the best solution is to throw it out.

System Metaphor – It is a story that everyone can understand about how the system works. It creates a naming convention that allows customers to guess what class/methods do. The use of the System Metaphor is very Extreme Programming. It allows the team to better communicate with the business and promote transparency.

The last practice found in Extreme Programming is part of a group called Programmer Welfare. It is the practice of a Sustainable Pace where programmers are not required—or even allowed—to work more than 40 hours per week on average and they do not have overtime two weeks in a row. The idea is based on the concept that programming is highly technical, detailed work and that fresh programmers produce better code. A key enabler of this concept is frequent code merges of code that is always executable. This code must constantly be tested to ensure it is of a high quality.

Like most methodologies, Extreme Programming has a five-step process. The names of these steps are different than what many are used to, but the actual work will be familiar. The five steps include:

Envision — The Envision step is the first step in the process. It requires the development team to have a series of directed conversations with the customer with a goal of understanding the business need. The customer is defined as the people who actually use the product or service of the project. The team must determine the product vision, the project community, and how the team will work together. Envisioning aligns to the Initiating Process Group described in the PMBOK® Guide.

Speculate — The second step in the process is called Speculate. In this step, User Stories are generated that lead to the successful resolution of the business



Page 60

need. Often this stage requires additional tools such as Feature Breakdowns Structures or, even more commonly Story Maps to graphically represent all the stories required for the project. The focus of this step is on developing a feature-based plan to deliver on the vision that includes milestones, iterations and release dates. Speculation aligns to the Planning Process Group described in the PMBOK Guide®.

Explore — In the Explorer Phase, developers use Pair Programming to deliver tested features in a short timeframe, constantly seeking to reduce the risk and uncertainty of the project. One Developer writes the code while the other reviews the first developer’s work and thinks strategically. Exploring aligns to the Executing Process Group described in the PMBOK® Guide.

Adapt — In the Adapt Phase the team reviews the delivered results, the current situation, and the team’s performance, and then adapts as necessary. It requires the team to continuously integrate their code using their Source Control, which requires checking-in and out the source code. It also requires local integration and a constant focus on refactoring. Adapting aligns to the Monitoring and Controlling Process Group described in the PMBOK® Guide.

Close — Every project must be closed properly when finished. In Extreme Programming, closure focuses on Customer Acceptance Testing. Here the customer tests the fully integrated package against the business need in an operational environment to ensure their satisfaction with the output. Additionally, the team must pass along any key learning and celebrate their success. Closing the XP project aligns to the Closing Process Group described in the PMBOK® Guide.

At this point, your head might be swimming with different Agile concepts and we have only just covered the big two. So to help you get rooted, let’s spend a couple of moments comparing Scrum and Extreme Programming to ensure you have a firm grasp of these two critical methodologies before moving on. As we make these comparison remember that they are rough generalizations, and it is always possible to find exceptions to them.

Scrum teams work in timeboxes called Sprints that are two to six weeks in length. Extreme Programming uses timeboxes called Iterations that are one to two weeks in length. A two week Sprint is the most common in Scrum and a one week Iteration is most common in XP.

Scrum teams do not allow the Product Owner to introduce changes into a Sprint. The Development Team may remove a Story from the current Sprint and pull another in, but they must make the decision. In Extreme Programming so long as work has not started on a feature, the customer may change or replace that feature with another deemed more important.

Scrum Development Teams control the order of work, but are informed by the Product Owner whereas Extreme Programming Teams work on a strict priority basis as defined by the customer.

Slide 76



Page 61

Slide 77

Slide 78-82

Finally, Scrum does not prescribe any specific engineering practices whereas XP prescribes Test Driven Development, automated testing, pair programming and simple design. This last distinction often confuses students or creates arguments because they come from organizations that are using Scrum and are also using several other engineering practices. That is great and there is nothing in the rules of Scrum that says you can’t use these and many other practices. The difference is that XP requires these practices, whereas Scrum allows for them.

Feature-Driven Development The third methodology we will introduce is Feature-Driven Development or FDD. This methodology is far less popular than either Scrum or XP. FDD was originally created by Jeff De Luca to use on a specific 15-month, 50 person software development effort at Singapore Bank in 1997. De Luca created a five process methodology that included the development of the overall model and then the listing, planning, designing and developing of the features. Much of the methodology draws on the earlier work of Peter Coad and his approach to object modeling. After the project was deemed a success, the methodology was introduced to the public in Chapter 6 of the book Java Modeling in Color with UML by Coad, De Luca, and Eric Lefebvre in 1999. The 2002 book A Practical Guide to Feature-Driven Development provided a more general description of the methodology and also served to decouple it from Java.

FDD is a model-driven, short-iteration methodology that has five basic processes or activities. In FDD the first two activities are used to generate an overall model shape. Then, the final three processes or activities are iterated for each feature. The five processes or activities include:

Develop Overall Model — The team holds a kickoff and a high-level walkthrough of the scope of the system. This includes all of its context. Next, detailed Domain Models are created for each modeling area by small teams and then presented for peer review. One of the proposed models, or a combination of them, is selected to become the model for each domain area. These Domain Area Models are progressively merged into a single overall model.

Build Feature List — Knowledge and information from the initial modeling effort is used to identify the list of features by functionally decomposing the domain into subject areas. Each subject area contains business activities with steps that form the basis for a categorized feature list. Think of these “features” as small pieces of client-valued functionality expressed in the form “<action><result><object>.” This is an IT specific way of writing features that might have little meaning if you do not come from a software development background. Don’t worry, you do not need to be a software developer to pass the PMI-ACP® Exam. These features need to be small enough that they can be completed in two weeks or less. Once the team has finished this activity, they have their overall model and are ready to proceed into the activities used to actually produce the features of the project.



Page 62

Plan By Feature — In this step, a development plan is created where ownership of features, or feature sets are assigned as classes to specific programmers.

Design By Feature — A design package is produced for each feature. A Chief Programmer selects a small group of features that are to be developed within two weeks. Together with the corresponding class owners, the chief programmer works out detailed sequence diagrams for each feature and refines the overall model. Next, the class and method prologues are written and finally a design inspection is held.

Build By Feature — After a successful design inspection, a per-feature activity is planned that will produce a completed client-valued function (feature). The class owners develop the code for their classes. After a unit test and a successful code inspection, the completed feature is promoted to the main build. The team then returns to the Plan By Feature Activity and repeats the process until the entire project is complete.

Since features are small, completing a feature is a relatively easy task. For accurate reporting to keep track of the software development project, it is important to mark the progress made on each feature. Feature-Driven Development therefore defines six milestones per feature that are to be completed sequentially. The first three milestones are completed during the Design By Feature activity, the last three are completed during the Build By Feature activity. To help with tracking progress, a percentage complete is assigned to each milestone. At the point that coding begins a feature is already 44% complete (Domain Walkthrough 1%, Design 40% and Design Inspection 3% = 44%). The code itself is worth 45%. Code Inspection provides another 10%, and finally Promoting the Feature to Build adds 1%.

FDD makes use of a core set of best practices from software engineering. These practices all attempt to drive a client-valued feature perspective. These practices include:

Domain Object Modeling – The team explores and explains the domain of the problem. That probably doesn’t mean very much to you at this point so let’s spend a few minutes discussing Domain Modeling. Domain Modeling is a way to describe and model real world things and the relationships between them. This is collectively called the “Problem Domain Space.” Domain Modeling is used by lots of Agile techniques including FDD and SAFe. It is considered one of the key models used in software engineering and there is a saying, “if you only model one thing in Agile, model the domain.” It is considered important because it helps resolve ambiguities in both the requirements and the design intent. Domain Models reflect our understanding of real world entities and their relationships and responsibilities. Key to remember is that effective Domain Modeling may only occur in the context of the system-level requirements that are often captured as Use Cases or User Stories. Domain Modeling is used to support the analysis of Epics, Backlog refinement at the program and team levels, design workshops at different levels, and the refinement of the Product Vision and Roadmap. A Domain Model is typically developed by the project’s System Architect in collaboration with other stakeholders to help in the understanding of the impact of

Slide 83



Page 63

epics and features on the system. Requirements and domain modeling are considered mutually dependent. The Domain Model supports efforts to clarify requirements, whereas requirements help build up and clarify the model. Additionally, once a requirement is implemented, the domain model may also have to change. A Domain Model is NOT a set of diagrams describing software classes, or software objects and their responsibilities. It is a visual representation of the decomposition of a domain into individual conceptual classes or objects. The Domain Object Modeling is the process of building Class Diagrams that depict the significant types of objects within a problem domain and show the relationships between them. The first published description of FDD appear as part of a concept called UML in Color. This is the same as plain UML, but the classes are color-encoded. This is done to allow for quick understanding of the dynamics of the problem domain. Each of the class categories are represented by a different color that has specific meaning:

Yellow – A role being played by a person or an organization.

Blue – A catalogue-like description of an object, but one that is not considered the object itself.

Green – A party (individual), place, or thing. The green class usually has some identifying attributes, such as a serial number or a person’s name associated with it.

Pink – A moment in time or an interval of time usually associated with some business process.

Developing by Feature – Break the functions down into two-week or shorter chunks and calls them features.

Individual Class Ownership – Areas of code have a single owner (This is different from XP).

Inspections – Reviews that help ensure good-quality design and code.

Configuration Management – Labeling code, tracking changes, and managing source code.

Regular Builds – Make sure new code integrates with existing.

Visibility of Progress & Results – Track progress based on completed work.

Gerald Weinberg’s Size / Complexity Dynamic argues that as the size of a software system grows, the complexity of that software system grows at least as fast as the square of the size of the program. It therefore quickly outstrips the relatively fixed capacity of the human brain.

FDD decomposes the entire problem domain into tiny problems, which can be solved in a small period of time, usually two weeks.

FDD splits the project into iterations so that the distance in time between analysis and test is reduced under the belief that early discovery of errors reduces the cost to fix those errors.



Page 64

FDD has six primary roles, five support roles and three additional roles. FDD, like all Agile Methodologies argues that when you consider the key drivers of a project — people, process, and technology — people are the most important aspect. The primary roles include:

Project Manager – Many Agile Methodologies specifically avoid the title of Project Manager because of its use in linear methodologies such as Waterfall. FDD does not shy away from it. In FDD, the PM is the administrative head of the project and is responsible for reporting progress, managing budgets, fighting for headcount, and managing equipment, space, and resources, etc.

Chief Architect – The Chief Architect is responsible for the overall design of the system. He or she is responsible for running the workshop design sessions where the team collaborates in the design of the system. This is a senior technical role not described in Scrum or Extreme Programming.

Development Manager – The Development Manager is another role not described in Scrum or XP. The Development Manager leads the day-to-day activities of the Chief Programmers and Class Owners. The DM is also responsible for resolving resource conflicts when the Chief Programmers cannot do it.

Chief Programmers – The Chief Programmers are the most experienced developers who are responsible for leading small teams of three to six developers throughout the entire process, including low level analysis, design, and development of the application. Notice that this team size is close to the team size of six plus or minus three found in Scrum.

Class Owners – The Class Owners are the developers who work as members of those three to six member teams led by the Chief Programmers who design, code, test and document the features required on the project. They are called Class Owners because that is exactly who they are. FDD ensures that every single class (defined as a breakout of code) is owned by one and only one person. If anything is wrong with it, they are responsible.

Domain Experts – The Domain Experts are users, sponsors, and business analysts who have the specific knowledge the Class Owners rely upon to deliver the correct system.

In addition to the primary roles, Feature Driven Development relies on five supporting roles to succeed. These roles are not considered primary to the team delivering the required features, but they are important roles to the project’s success. These roles include:

Release Manager – The Release Manager is an administrative role that is tasked with ensuring that the Chief Programmers report progress each week. They then report that information directly to the Project Managers. Not all FDD teams use a Release Manager. The determining factor is project and/or team size. Project Managers of larger teams often require assistance in collecting all the information used to manage a large project. This raises a critical point to remember about Feature-Driven Development, it was



Page 65

Slide 84

specifically designed for large teams and complex projects.

Language Guru – A Language Guru is the person on the team who is responsible for knowing a programming language or a specific technology inside out. When the product or service of the project is using a technology or programming language new to the organization, this role is very important.

Build Engineer – The Build Engineer is responsible for setting up, maintaining, and running the regular build process.

Toolsmith – The Toolsmith creates small development tools used by the Development and Data Conversion Teams.

System Administrator – The System Administrator configures, manages, and troubleshoots any servers or networks of workstations specific to the project team.

There are three roles that appear in Feature-Driven Development that are not considered primary or secondary. These roles include:

Testers – A Tester is responsible for independently verifying that the system’s functions meet the users’ requirements, and that the system performs those functions correctly.

Deployers – A Deployer converts existing data to the new formats required by the new system and works on the physical deployment of new releases of the system.

Technical Writer – A Technical Writer writes and prepares online and printed user documentation.

As you can tell in the name of the methodology, features are at the heart of the methodology. A feature is a small, client valued function that can be implemented in two weeks. Any function that is too complex to be implemented within two weeks must be further broken down until it meets the definition of a feature. Features are grouped based on business relationships, and those groups are called a Feature Set. FDD requires that there is always a demonstrable system available. To meet this requirement, the team must take all the source code (for the completed features, the libraries, and the components on which those features depend) and regularly complete a system build. This is done on a regular schedule in FDD.

To help you better understand Feature-Driven Development, let’s spend a few moments to compare it to Scrum. First, Scrum does not specify a formal process inside each sprint. It says you have to start with a Sprint Planning Meeting, hold your Daily Scrum and end each Sprint with a Retrospective and Review, but that is it. How you accomplish the work inside each spring is yours to decide. Feature-Driven Development has five specific steps used to produce the work product. The second main difference is that Scrum does not require a specific model, whereas FDD requires a Domain Model be created first before any software is produced. The third main difference is that Scrum works from a ranked Product Backlog that is owned by the Product Owner. The Development Team works



Page 66

from the Backlog, informed by the PO. In contrast, FDD works from its Feature List which is strictly based on the priority list. The fourth difference is that Scrum uses a Release Plan to provide its initial view of when the Product Backlog Items will be delivered. Feature-Driven Development, on the other hand, plans strictly by feature order. The final difference is that the entire process of Scrum is iterative. In FDD, only the last three steps are iterative. The first two steps only occur once.

Because of the length of this chapter, it is broken into two parts. This ends Part I. Please complete the exam that follows before you continue to Part II.



Page 67

Exercise 3 -Agile Principle & Mindset Pt. I

Agile Principles & Mindset Part I Exam

1. Which of the following statements BEST describes the relationship between Agile Development and the PMBOK® Guide?

A. The PMBOK® Guide represents PMI's methodology for executing projects while Agile Development represents a software development framework.

B. Agile Development represents the newest way to execute a project while the PMBOK® Guide represents the old way of executing a project.

C. The PMBOK® Guide represents the overall framework for executing projects and Agile Development represents a set of specific methodologies used in project execution.

D. Agile Development represents the overall framework for executing projects and the PMBOK Guide represents a set of specific practices used in large scale projects.

2. Which of the following thought leaders is considered the father of the linear development methodology know as "Waterfall"

A. Alistair Cockburn B. Winston Royce C. Lyssa Adkins D. Ken Schwaber

3. Which of the following terms refers to a staging and scheduling strategy in which the various parts of the system are developed at different times or rated and integrated as they are completed?

A. Iterative development B. Incremental development C. Staged development D. Agile development

4. Which of the following terms represents a scheduling strategy where time is set aside to revise and improve parts of the system?

A. Iterative development B. Incremental development C. Staged development D. Agile development

5. When comparing traditional, linear development to Agile Development which of the following statements is most likely to be true?

A. Agile development makes extensive use of best resourcing to ensure optimal productivity while traditional development uses WIP.

B. Both traditional development and Agile make use of best resourcing to ensure optimal productivity.

C. Both traditional development and Agile make extensive use of WIP to ensure optimal productivity.

D. Agile development makes extensive use of WIP while traditional development uses best resourcing to ensure optimal productivity.

6. Within the Agile Manifesto, which of the following is valued more than processes and tools?

A. Individuals and interactions B. Customer collaboration C. Responding to change D. Working software



Page 68

7. Within the Agile Manifesto, which of the following is valued more than contract negotiations?


8. Within the Agile Manifesto, which of the following is valued more than following a plan?


9. Within the Agile Manifesto, which of the following is valued more than comprehensive documentation?


10. Which of the following Agile principles, found in the Agile Manifesto, is considered MOST important?

A. Welcoming changing requirements, even late in develop. B. Working software is the primary measure of progress. C. Simplicity -- the art of maximizing the amount of work not done. D. Satisfying the customer through early and continuous delivery of valuable software.

11. Which of the following principles found in the Agile Manifesto focuses the team on the importance of adaptation?

A. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

B. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

C. Business people and developers must work together daily throughout the project. D. Our highest priority is to satisfy the customer through early and continuous delivery

of valuable software.

12. Within the Agile Manifesto, which of the follow principles focuses the team on the importance of iterations?

A. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

B. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

C. Business people and developers must work together daily throughout the project. D. Our highest priority is to satisfy the customer through early and continuous delivery

of valuable software.

13. Which of the following principles found in the Agile Manifesto focuses the team co-location, osmotic communication, and information radiators?

A. Simplicity - the art of maximizing the amount of work not done - is essential. B. Agile processes promote sustainable development. Everyone should be able to

maintain a constant pace indefinitely. C. Business people and developers must work together daily throughout the project. D. The most efficient and effective method of conveying information to and within a

development team is face-to-face conversation.



Page 69

14. Which of the following principles found in the Agile Manifesto focuses teams on a pace often referred to as the Heartbeat of Agility?

A. Continuous attention to technical excellence and good design enhances agility. B. Agile processes promote sustainable development. The sponsors, developers, and

users should be able to maintain a constant pace indefinitely. C. Build projects around motivated individuals. Give them the environment and support

they need, and trust them to get the job done. D. Deliver working software frequently, from a couple of weeks to a couple of months,

with a preference to the shorter timescale.

15. Which of the following principles from the Agile Manifesto calls on the team to complete an introspection step as part of their process?

A. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

B. Continuous attention to technical excellence and good design enhances agility. C. Agile processes promote sustainable development. The sponsors, developers, and

users should be able to maintain a constant pace indefinitely. D. Business people and developers must work together daily throughout the project.

16. A common term used by agilists to describe the cadence or pace created in Agile Development is__________.

A. The Agile Cadence B. Agile Throughput C. The Heartbeat of Agility D. The Agile Rhythm

17. Which of the following statements concerning the Heartbeat of Agility is NOT true? A. The notion of a consistent cadence or pace is absolutely critical to Agile

Development. B. The Heartbeat of Agility is all about establishing a rhythm that is comfortable and

sustainable by the team. C. The Heartbeat of Agility establishes a rhythm that often differs from what the Team

experiences in the real world. D. The Heartbeat of Agility establishes a pace with slow periods throughout most of the

project.

18. An Agile Coach is explaining to a new Scrum Master that they believe the team has NOT been doing Scrum correctly as they are experiencing slow periods of production throughout most of the project only to be forced into a mad dash at the end of each Sprint in hopes of delivering business value. Typically, the team has failed to meet the deadline, is burnt out, and has left their customer frustrated. Which term BEST describes what the team has failed to establish?

A. Clear team expectations B. The Heartbeat of Agility C. Proper Scrum training D. Well defined spike management

19. According to one recent study, what percentage of the average software development project's features are never used?

A. 55% B. 45% C. 35% D. 25%



Page 70

20. Which of the following represents a way Agile Development helps to prevent the customer from having to sacrifice quality in order to hit a targeted delivery date?

A. Agile methods require the customer to prioritize the project requirements from most important to least.

B. Agile methods iterate the project to prevent mistakes. C. Agile methods require the customer to continue the project until the backlog is

delivered. D. Agile methods force the customer to not require unused features be delivered.

21. Which of the following statements concerning Agile Development is NOT true?

A. Agile Development increases the visibility a customer has on a project. B. Agile Development puts the customer in a position to see constraints before they

cause failure. C. Agile Development ensures the customer receives something of value by the

deadline. D. Agile Development gives the customer their most important features earlier in the

process.

22. In 1986 Hitotaka Takeuchi and Ikujiro Nonaka published an article that appeared in the Harvard Business Review entitled The New New Product Development Game which became the basis for which Agile method?

A. Feature-Driven Development B. Extreme Programming C. Dynamic Systems Method D. Scrum

23. Scrum is based on which of the following aspects of Industrial Process Theory? A. Self-organization and emergence B. Convergence and self-organization C. Emergence and dynamic evolution D. Dynamic evolution and Convergence

24. Which of the following concepts represents the idea that information, requirements, and facts are seen over time as the project progresses?

A. Convergence B. Emergence C. Self-organization D. Dynamic evolution

25. Which of the following concepts represents the idea that the Development Team decides what work needs to be accomplished and who will do the work to deliver the desired business results?

A. Convergence B. Emergence C. Self-organization D. Dynamic evolution

26. According to Jeff Sutherland and Ken Schwaber, traditional project management is based on the concept of a defined process. This concept is most effective when used in what kind of organization?

A. A projectized organization B. A matrix organization C. A functional organization D. A manufacturing organization



Page 71

27. Which of the following terms represents a process in which goods that have economic value and are indistinguishable in terms of attributes (uniqueness or brand) end up becoming simple commodities in the eyes of the market or consumers.

A. Standardization B. Commoditization C. Convergence D. Optimization

28. When describing the various types of processes a project might use, which of the following statements is MOST true?

A. Projects have the greatest chance of success when empirical processes are used. B. Projects have the least chance of success when empirical processes are used. C. Projects have the greatest chance of success when defined processes are used. D. Projects have the least chance of success when defined processes are used.

29. Which of the following is NOT a key driver for empirical processes?

A. Visibility B. Inspection C. Adaption D. Flexibility

30. When describing an empirical process, which of the three major drivers defines the step where the team brings the process back into conformance once an unacceptable variance is found?

A. Visibility B. Inspection C. Adaptation D. Conformation

31. Which of the following Scrum roles represents the person who is responsible for representing the interests of all stakeholders, obtaining project funding, defining the initial requirements, defining the project ROI, and the key project objectives?

A. Product owner B. Key stakeholder C. Project sponsor D. Customer

32. Within Scrum, where are the product features maintained and appear in ranked order from most important to least?

A. The product scope statement B. The product backlog C. The project charter D. The requirements matrix

33. Which of the following statements concerning the Product Backlog is NOT true?

A. A product backlog is never complete. B. The product backlog evolves as the product and the environment in which it will be

used evolves. C. The product backlog lists all features, functions, requirements, enhancements, and

fixes that constitute the changes to be made to the product. D. The product owner may decide to "lock down" the product backlog at any time.



Page 72

34. Which of the following statements concerning the product backlog is NOT true? A. Higher ranked backlog items are usually more clearly and completely defined than

lower ranked items. B. Any backlog item that can be "done" within one sprint is deemed "ready" for

selection in sprint planning. C. The product owner is responsible for all estimates of items appearing on the product

backlog. D. The Scrum team defines when refinement is done for all backlog items.

35. What primary Scrum role is described as self-managing, self-organizing, and cross functional?

A. The product owner B. The development team C. The Scrum team D. The Scrum master

36. What is the recommended size of the Scrum development team?

A. 6 +/- 3 B. 5 +/- 3 C. 3 +/- 4 D. 4 +/- 4

37. Which of the following statements about the Scrum master is NOT true?

A. The Scrum master is responsible for the Scrum process. B. The Scrum master is responsible for implementing Scrum so it fits with culture. C. The Scrum master acts as a facilitator. D. The Scrum master acts as the project manager for the project.

38. Which one of the following represents one of the key expected behaviors of the development team represented by the acronym CFORCE?

A. Convicted B. Focused C. Opportunistic D. Courteous

39. Which of the following represents one of the key expected behaviors of the development team NOT represented by the acronym CFORCE?

A. Extreme B. Courageous C. Reasoned D. Committed

40. You are acting as a Scrum master for a new project within your organization. There currently isn't any documentation for the initiative. Which of the following documents is required before the team can begin work according to the rules of Scrum?

A. A business case B. A needs analysis C. User stories D. A product vision



Page 73

41. Which of the following items is NOT one of the five core elements found in a project vision document?

A. The business case B. The project justification C. Success criteria D. Constraints and assumptions

42. According to Moore, which of the following is a common way to validate a project Vision?

A. The PDCA Test B. The ROAD Test C. An Elevator Test D. An Ishikawa Test

43. You are asked to explain the project initiation process when using Scrum to a coworker. As part of the discussion you explain two documents are required. What are those two documents?

A. A business case and user stories B. A burndown chart and user story log C. A Kanban board and a business case D. A product vision and product backlog

44. Which of the following terms represents a self-contained unit of work agreed upon by the developers and the stakeholders?

A. User stories B. Themes C. Epics D. Releases

45. Which of the following terms represents a group of related user stories that contribute to a common goal or are related in some obvious way?


46. Which of the following terms are made up of multiple user stories, but also sometimes resemble stories in the sense that they may appear as a larger story or comprise a complete workflow for a user and cut across all or some of the three business dimensions?


47. Which of the following terms represents a grouping of functionality that is most often seen when teams implement SAFe and are often used to enhance business value of the FULL solution set or bring a range of technologies together?

A. Epics B. Rocks C. Sprints D. Releases



Page 74

48. Which of the following terms represents pieces of functionality used as placeholders when there is an absence of information and act as a signpost signifying the team does have information about a feature or requirement?

A. Epics B. Stories C. Sprints D. Rocks

49. When discussing sprints, which of the following statements is NOT true?

A. The original Rules of Scrum stated that each Sprint was 30 days in length. B. The development team must decide the length of each sprint during the sprint

planning meeting. C. Over the years, Scrum has adopted the practices from other Agile methodologies and

the common practice is to see sprints of between two and six weeks in length. D. Each sprint must be the exact same fixed length.

50. Which of the following may explain why releases become necessary:

A. The organization that has set specific windows where new code can be put into the production system.

B. It is either impractical or ill advised to put the features completed from a single sprint into production. because the Scrum master determines it to be so.

C. Releases are never necessary. D. Releases are required on every Scrum project.

51. What is the first official meeting defined in the Scrum Guide?

A. The project kickoff B. The release planning meeting C. The sprint planning meeting D. The sprint retrospective

52. What officially signifies the start of each sprint?

A. The product owner announces the sprint initiation. B. It is noted by the calendar. C. The sprint planning meeting D. It varies from one Scrum project to the next.

53. Which of the following is NOT a core purpose of the release planning meeting?

A. The development team uses the meeting to examine the backlog items to determine how they need to be grouped together to produce releases.

B. The development team uses the meeting to determine how long each sprint will be. C. The development team uses the meeting to determine how the sprints will be grouped

into releases. D. The development team uses the meeting to create estimates for the significant tasks.

54. The process of defining backlog items in greater detail is called __________.

A. Grooming B. Defining C. Decomposition D. Consecration



Page 75

55. When defining a user story, which of the following rules apply?

A. Each user story must be completed within one release. B. Each user story must provide monetary value to the business. C. Each user story must be completed within one sprint. D. Each user story represents a single work package.

56. Which of the following is NOT a key question asked during the Daily Scrum?

A. What did they accomplish yesterday? B. What are the user story durations? C. What are they going to accomplish today? D. What impediments do they have?

57. What is the role of the product owner in the Daily Scrum?

A. The PO leads the Daily Scrum. B. The PO does not attend the Daily Scrum. C. The PO answers the key questions. D. The PO acts as an observer in the Daily Scrum.

58. As the development team completes the work of a Scrum Sprint what is the primary responsibility of the PO?

A. Defend the team and secure project funding. B. Groom the backlog and remove impediments. C. Groom the backlog and define the next sprint. D. Remove impediments and define the next sprint.

59. You are working on a software development project within your organization serving the role of Scrum master. The team is in the middle of its fourth two-week iteration when the Product Owner, who is also the company CEO, has just come to you demanding a critical piece of functionality be added to the current Sprint. What should you do?

A. Immediately call the team together to discuss the issue. B. Add the functionality to the sprint backlog. C. Remind the PO that in agreeing to use Scrum they committed to not changing the

features the team worked on once a Sprint began. Then ask that they add the feature to the Product Backlog and prioritize it highly.

D. Freeze the project until the issue is resolved.

60. May the Development Team ever alter the features being completed in the current Sprint?

A. Yes, whenever a member of the team believes it is warranted. B. No, changing the work of an in-progress Sprint is never allowed. C. Yes, when new information is learned, or the team finds they have extra time and the

entire team agrees. D. No, only the Product Owner may change the work of an in-progress Sprint.

61. You are the Scrum Master for a mid-sized project that has just completed its third two-week Sprint. What should the Team do next?

A. Plan and conduct the Sprint Review. B. Plan and conduct the Sprint Retrospective C. Review the Product Backlog before beginning the next Sprint. D. Initiative a Release Planning Meeting.



Page 76

62. When a team conducts a Sprint Retrospective what is the role of the Product Owner?

A. The Product Owner leads the Sprint Retrospective. B. The Product Owner acts as a team member in the Sprint Retrospective. C. The Product Owner coordinates the objectives of the Sprint Retrospective with the

Scrum Master. D. The Product Owner does not participate in the Sprint Retrospective.

63. A member of the business organization has just returned from a basic Agile training course and wants you and the rest of the Development Team to use an iteration zero in an upcoming Scrum project. Which of the following is NOT a reason for this recommendation?

A. The team believes a more formal architecture plan is needed. B. The team believes the project requires an iteration or milestone plan. C. The team believes the project is extremely complex requiring more traditional

planning. D. The team believes the advanced planning will allow it to move quickly moves into

more standard Scrum sprints.

64. Which of the follow is NOT one areas of focus for Extreme Programming?

A. Goals B. Testing C. Activities D. Values

65. Which of the following is NOT a core activity used in Extreme Programming used to meet its stated goal?

A. Listening – Programmers must listen to customers and understand the business processes.

B. Designing – Software must be designed as components without complexity or dependencies between components.

C. Testing – The team must test a functionality. D. Deployment - The team must implement the product or service of the project.

66. Which of the following is a core value of the Extreme Programming methodology?

A. Guidance B. Commitment C. Simplicity D. Dedication

67. Which of the following is NOT a core value of the Extreme Programming framework?

A. Curious B. Feedback C. Communication D. Respect

68. Which of Extreme Programming practices does NOT belong in the Fine Scale Feedback group?

A. The Planning Game B. Design Improvement C. Test-Driven Development D. Whole Team



Page 77

69. What Extreme Programming practice calls for a meeting that occurs once per iteration and likely occurs once per week? This practice is focused on determining which requirements are included in which near-term release and when specifically they should be delivered.

A. Paired Programming B. The Planning Game C. The Whole Team D. Test-Driven Development

70. The team is using Extreme Programming to complete the project, the business and developers are meeting to commit to the functionality to include within the next release and what the release date will be. In what phase of the Planning Game are you?

A. Exploration B. Planning C. Commitment D. Steering

71. In the XP practice group known as Shared Understanding which of the following is not a core practice?

A. Coding Standards B. Simple Design C. Collective Code Ownership D. Complete Metaphor

72. In discussions with another developer on an XP project team your remind them of YAGNI. What are you suggesting?

A. System designs are usually best when they are kept simple. B. Good design requires a strong overall view of the the project. C. Good architecture is layered in its approach. D. Systems thinking is critical to project success.

73. When the creators of Extreme Programming discuss the importance of a sustainable pace to what are they referring?

A. Programmers are not permitted to work more than 40 hours per week on average and no two weeks in a row have over time.

B. Programmers are not permitted to work more than 40 hours per week on average and no more than one week per month has overtime.

C. Programmers are not permitted to work more than 50 hours per week on average and no more than two weeks per month have overtime.

D. Programmers are not permitted to work more than 50 hours per week on average and no more than two weeks in a row have over time.

74. Which of the following is NOT one of the basic steps found the the Extreme Programming process?

A. Envision B. Speculate C. Create D. Adapt



Page 78

75. Which of the following is NOT one of the basic steps found the Feature-Driven Development process?

A. Develop Overall Architecture B. Build Feature List C. Plan By Feature D. Build By Feature

76. Feature-Driven Development defines six milestones per feature. During which activity are the first three milestones completed?

A. Build Feature List B. Plan By Feature C. Design By Feature D. Build By Feature

77. FDD is unique because at the point coding begins a feature is already ____ complete.

A. 36% B. 38% C. 42% D. 44%

78. Which of the following statements concerning domain models is NOT true?

A. Domain models reflect our understanding of real world entities and their relationships and responsibilities.

B. Domain models help resolve ambiguities in both the requirements and the design intent.

C. Domain models are typically developed by the Product Owner. D. Domain models reflect our understanding of real world entities and their relationships

and responsibilities.

79. In which FDD role does the person work as a member of a three to six member team who designs, codes, tests and documents the features required on the projects?

A. Domain Experts B. Class Owners C. Chief Programmers D. Development Manager

80. In which FDD role are the users, sponsors, and business analysts who have the specific knowledge relied upon to deliver and correct the system?

A. Domain Experts B. Class Owners C. Chief Programmers D. Development Manager

81. Which of the following is NOT a secondary role found in Feature-Driven Development?

A. Toolsmith B. Build Engineer C. Language Guru D. Product Manager



Page 79

82. Within the process of Domain Object Modeling, which class category color represents a moment in time or an interval of time usually associated with some business process?

A. Yellow B. Blue C. Green D. Pink

83. In FDD, which of the following terms is the process by which the team explores and explains the domain of the problem?

A. Domain Area Modeling B. Designing by Feature C. Domain Object Modeling D. Configuration Management

84. In which FDD step does the team use knowledge from the initial model to identify the list of features by functionally decomposing the domain into subject areas?

A. Domain Area Modeling B. Designing by Feature C. Domain Object Modeling D. Build Feature List

85. Which of the following FDD concepts is used to reference the process of labeling code, tracking changes, and managing source code?

A. Inspections B. Regular builds C. Configuration management D. Domain modeling



Page 80

Answers 1. Answer: C. LGd course manual p. 27 - The relationship between Agile Development and the

PMBOK Guide has traditionally been contentious. Many Agilists try to argue Agile Development and the PMBOK Guide are at odds. However, nothing could be further from the truth. The PMBOK Guide represents generally accepted principles and practices. It does NOT represent a methodology that can be followed step-by-step. Many agilists also claim that their particular concepts are a framework representing a loose scaffolding. However, most thinkers agree Agile represents an aggregation of methodologies.

2. Answer B. LGd course manual p. 30 - Dr. Winston W. Royce is often falsely credited with developing the waterfall methodology based on a he wrote in 1970. However, if one actually reads his paper they find he actually argued there were significant risks in the linear process and proposed an iterative and incremental approach with at least two loops. He also argued for prototyping.

3. Answer B. LGd course manual p.30-31 - Alistair Cockburn defines Incremental development as a staging and scheduling strategy in which the various parts of the system are developed at different times or rated and integrated as they are completed. This means that the features or requirements do not have to be completed as part of a single release. When a team uses incremental delivery they are able to deliver features or requirement in a wide range of orders defined by the team. This fundamentally changes how projects are executed. Suddenly, it what is delivered at any point in the project. This notion is somewhat similar to the ideas surrounding Object Oriented Programming where features and requirements are delivered as discrete objects independent of others.

4. Answer A. LGd course manual p. 231 - Iterative development is a rework scheduling strategy in which time is set aside to revise and improve parts of the system. The concepts of Iterative Development creates loops in the process of executing a project that allow the team to change their process to improve execution and delivery. In a single looped linear process, the team is stuck with the process with which they start the project. This is a key advantage to seasoned, experienced teams. Those teams have completed multiple projects together and hopefully those experiences provide insights on the current effort. Agile projects get lots and lots of chances to deliver because they use lots of short iterations. Each one requires a short cycle of reflection to determine the best way to improve the process and deliver better results.

5. Answer D. LGd course manual p. 35 - Agile Development makes extensive use of WIP or Work In Progress. Although there is no rule or requirement to do so, most traditionally managed projects use a concept called Best Resourcing. In Best Resourcing whichever resource possesses the highest skill level is assigned to execute the task. WIP argues that we want to limit the amount of Work In Progress occurring at any single point. The principle can be thought of like a water main. The objective of the Water Department is to ensure the maximum amount of water is constantly available to the end users when they turn on their faucets. Contrary to what you might think, the best way to ensure high water pressure is to ensure the mains are less than 100% full. Remember, the mission is to get each drop to the customer as quickly as possible. If you ask your friendly neighborhood civil engineer, they will confirm that the water will travel the fastest when the pipe is less that 100% full. We do the same thing with our project tasks when using WIP.

6. Answer A. LGd course manual p.37 & the Agile Manifesto at http://agilemanifesto.org. This is perhaps the most important and highlights a common complaint about many Project Managers. According to many involved in Agile Development, traditional Project Managers often lack technical skills dealing with the product or service of the project. This causes them to rely far too much on process and tools to fix problems when they arise. The key is to always remember that projects are about creating business value. The processes, tools and techniques we choose to use to create that value are simply means to an end. Without the end they have no value.



Page 81

7. Answer B. LGd course manual p. 37 & the Agile Manifesto at http://agilemanifesto.org. -The second value statement is that we value customer collaboration over contract negotiations. This value statement highlights the importance of the Development Team working directly and daily with the Business Stakeholders to deliver value to the business. Rarely does the Development Team understand the business need as well as the customer. Furthermore, the Customer is the final arbiter of whether or not the Team has delivered the right product or service. Therefore, to succeed the team must constantly talk to the stakeholders. In most cases, this means DAILY! Contracts are important, and many project require them. However, when the Team gets caught up in the legalize of what a contract says they often loose site of truly meeting the customer’s needs. At the end of the day, meet the customer’s needs.

8. Answer C. LGd course manual p. 37 & the Agile Manifesto at http://agilemanifesto.org. - The third value statement is we value responding to change over following a plan. This statement often causes an immediately negative knee-jerk reaction from traditionally trained project managers. “Ah ha!” They exclaim. “Here it is. Agile Development leads to chaos because it doesn’t allow for planning or plans. We can’t live this way. We have to be able to tell people what’s coming next.” Unfortunately, this is a complete misunderstanding of what the statement says and how most Agile Methodologies work. Agile projects absolutely have plans and processes. However, these processes and plans are set up in such as way that they can quickly evolve and change as the team learns new information. It is this ability that significantly differentiates Agile Development from other methods for managing projects. Do not misread this value. It is not a license for a no planning free-for-all. Agile requires plans and processes. In many cases, activities are planned to the daily level, a much smaller unit than many traditional projects use.

9. Answer D. LGd course manual p. 37 & the Agile Manifesto at http://agilemanifesto.org. - Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. This statement says it all. The highest priority or the most important thing is delivering value to the customer. In the early days of Agile the community was almost entirely software developers so naturally the product was software. Today, Agile has extended to many different industries so it often makes sense to replace “valuable software” with “valuable product, service or result.”

10. Answer D. LGd course manual p. 38 - Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. This statement says it all. The highest priority or the most important thing is delivering value to the customer. In the early days of Agile the community was almost entirely software developers so naturally the product was software. Today, Agile has extended to many different industries so it often makes sense to replace “valuable software” with “valuable product, service or result.”

11. Answer A. LGd course manual p. 39 - Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. We made all the way to the second principle before things blew up. I hear project managers constantly complain about scope change. It is almost a daily occurrence. “We would have succeeded, if it wasn’t for the customer making all those last minute scope changes.” This statement ignores the fact that it is the customer’s right to demand scope changes so long as they accept the impacts. The problem is that too many team uses processes that make change difficult at best. This is a real key to Agile Development’s success. It make change easy, or at least easier, even late in the process.



Page 82

12. Answer B. LGd course manual p. 39 & the Agile Manifesto at http://agilemanifesto.org. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. Remember, Agile Development is focuses on being iterative. This means loops of repeated processes. The large number of loops affords the team the opportunity to learn from the past. As the team executes more and more loops, they are able alter the processes to better deliver. However, the key is that at the end of each iteration the team must deliver working product, service or result. With a timescale of only a few weeks to a few months the team is limited in how much functionality they can produce. This means the team must produce a small amount of functionality that has value to the customer, present it to them, and allow the customer to comment on that functionality. The team then adapts to the feedback, makes changes and moves to the next iteration. A common phase used to highlight this process is, “fail fast.”

13. Answer D. LGd course manual p. 40 & the Agile Manifesto at http://agilemanifesto.org. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. Here is a news flash. E-mail is a terrible vehicle for most communication needs! Since its inception, Agile Development has understood this and pushed for better ways of sharing information. Broadcasting status reports via email or attempting to collect requirements electronically are examples of using e-mail poorly, but there are many more. Agile Development pushes teams to work closely and be co-located. If you are not familiar with the term CO-LOCATED it is important that you learn it. It means all the members of a group are physically sitting in the same location. This is why you can often quickly pick out and organization that is using Agile Development when the Development Team is all physically located in a single conference room or central area. Being co-located affords the team a number of advantages. First, team members can quickly turn and talk to compatriots when they have issues. Second, information quickly gets dispersed using OSMOTIC COMMUNICATION. This is where information is absorbed by team members simply by being in the room when it is shared. Finally, information moves between parties much more quickly through the use of INFORMATION RADIATORS when the team is in a single location. We will discuss this last term in a later section of the course.

14. Answer B. LGd course manual p. 40 -Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. Agile Development promotes sustainable development. What the heck is that, and why should you care? First, it is more than just marketing, although there is a bit of that here. The real issue is something many resources have experienced over the years. If you have ever been part of a project that starts out slow where many team members have nothing to do until the end of the project when everything becomes a crisis and a mad dash to the finish line. During these late periods, team members are expected to work significant overtime and often their personal life struggles to deliver the project. This cycle repeats itself time and time again until the resources eventually burn out and leave the organization. Agilists argue that this pace is not only unsustainable, but also unnecessary. A better approach they contend, is to use Agile processes that increase the daily productivity throughout the entire lifecycle of the project thereby reducing or completely eliminating the mad dash crisis at the end. This pace is often referred to as the HEARTBEAT OF AGILITY and will be discussed in a few moments.

15. Answer A. LGd course manual p. 41 - At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. Introspection is a key aspect of any Agile team. Unlike linear approaches to project execution where the Team typically does a single release, Agile Development cycles repeatedly. This gives the customer lots and lots of opportunities to comment on the work product. It also provides the Team many opportunities to learn. With every loop, the Team has a chance to execute the basic process. At the end of that process most Agile Methodologies provide some kind of reflection process where the Team is tasked with examining their performance in the cycle and determining the best way to improve before moving on to the next iteration. This reflection period is absolutely critical. It recognizes that the Team is never perfect, and there are always improvements to be made. It move the concept of continuous improvement from some abstract theory we say is important into something we at regular intervals focus on and actually do something about.



Page 83

16. Answer C. LGd course manual p. 42 - The notion of a cadence is absolutely critical to an Agile team. It is all about establishing a rhythm that is comfortable and sustainable by the Team. This rhythm differs from what many teams experience in the real world where they often experience slow periods of production throughout most of the project only to be forced into a mad dash at the end in hopes of delivering business results. Typically, the team fails to meet the deadline, is burnt out, and has left a frustrated customer. Agile processes attempt to solve this problem by increasing the daily productivity of the team. The goal is to have a higher rate of daily productivity and avoid the massive spikes experienced by the team. This notion does not argue there are not spikes, instead it is about creating much smaller, regular spikes that are within the realm of sustainability. It is called the heartbeat of agility.

17. Answer D. LGd course manual p. 42 - The Heartbeat of Agility represents a key aspect of developing an Agile Cadence or pace. The notion of a cadence is absolutely critical to an Agile team. It is all about establishing a rhythm that is comfortable and sustainable by the Team. This rhythm differs from what many teams experience in the real world where they often experience slow periods of production throughout most of the project only to be forced into a mad dash at the end in hopes of delivering business results. Typically, the team fails to meet the deadline, is burnt out, and has left a frustrated customer. Agile processes attempt to solve this problem by increasing the daily productivity of the team. The goal is to have a higher rate of daily productivity and avoid the massive spikes experienced by the team. This notion does not argue there are not spikes, instead it is about creating much smaller, regular spikes that are within the realm of sustainability.

18. Answer B. LGd course manual p. 42 - The Heartbeat of Agility represents a key aspect of developing an Agile Cadence or pace. The notion of a cadence is absolutely critical to an Agile team. It is all about establishing a rhythm that is comfortable and sustainable by the Team. This rhythm differs from what many teams experience in the real world where they often experience slow periods of production throughout most of the project only to be forced into a mad dash at the end in hopes of delivering business results. Typically, the team fails to meet the deadline, is burnt out, and has left a frustrated customer. Agile processes attempt to solve this problem by increasing the daily productivity of the team. The goal is to have a higher rate of daily productivity and avoid the massive spikes experienced by the team. This notion does not argue there are not spikes, instead it is about creating much smaller, regular spikes that are within the realm of sustainability.

19. Answer B. LGd course manual p. 43 - Chaos Chronicles, only about 36% of all features are regularly used. Another 19% of a software project’s features are rarely used, and a full 45% of a software applications features are never used. So why does this matter? It matters because far to often project teams force stakeholders to wait for the important, must used features because they are trying to produce features that will never be used.

20. Answer A. LGd course manual p. 43 - Most Agile methodologies require the customer or key stakeholders to prioritize the requirements from most important to least. The Team then makes every effort to deliver the features in the defined order. At the end of the project when the Team is at the deadline there will still likely be a number of features or requirements that are incomplete. The difference is that these are the less important ones. This puts the customer in a position of great power. Now the customer can decide whether or not they want the team to continue the project to deliver these minor features. In a linear process, the customer is stuck. They have to continue the project because if they don’t they get nothing of value. In Agile they have the most important items and get to decide how much the lessor items are really worth to them. Secondly, Agile Development gives the customer these most important features earlier in the process. This means they are able to begin using these mission critical features as soon as they are done without waiting for lessor features. Finally, Agile Development forces business stakeholders to make hard decisions like spend more money and time or not. It forces a hard discussion around those never used features in a highly visible way. As a result it becomes far more difficult to sneak a feature or requirement into the process at the end.

21. Answer C. LGd course manual p. 43 - Be careful in reading the choices. Although Agile Development does dramatically increase the likelihood the customer will get something of value by the deadline, nothing can ensure this fact.



Page 84

22. Answer D. LGd course manual p. 44 - Scrum was first defined as “a flexible, holistic product development strategy where a development team works as a unit to reach a common goal” as opposed to a “traditional approach” (read a linear approach such as Waterfall) in January of 1986 by Hitotaka Takeuchi and Ikujiro Nonaka in the New Product Development Game published in the Harvard Business Review. This article described a new approach to commercial product development that they argued would increase both speed and flexibility based upon their examination of numerous case studies in manufacturing, photocopier and the printer industries. They called this the holistic or rugby approach. The idea was to create a single, small cross functional team that possessed all, or at least most, of the skills required to complete the project and this team would work on the project across multiple overlapping phases constantly passing work back and forth until complete.

23. Answer A. LGd course manual p.45 - Scrum is based on two aspects of industrial process theory self-organization and emergence. Self-organization is the idea that the Development Team will decide what work needs to be accomplished and who will do the work to deliver the desired business results. Emergence is the idea that information, requirements and facts will emerge as the project progresses. The key is that the team uses processes, tools, and techniques capable of harnessing this new information for the betterment of the organization.

24. Answer B. LGd course manual p. 45 - Emergence is the idea that information, requirements and facts will emerge as the project progresses. The key is that the team uses processes, tools, and techniques capable of harnessing new information as it becomes available for the betterment of the project.

25. Answer C. LGd course manual p. 45 - Self-organization is the idea that the Development Team will decide what work needs to be accomplished and who will do the work to deliver the desired business results.

26. Answer D. LGd course manual p. 45 - The creators of Scrum argue that traditional linear approaches for projects such as Waterfall are based on the concepts of defined processes. Defined processes are repeatable processes such as in manufacturing.

27. Answer B. LGd course manual p. 45 - Commoditization is defined as the process in which goods that have economic value and are indistinguishable in terms of attributes (uniqueness or brand) end up becoming simple commodities in the eyes of the market or consumers. This means or widgets become easy to obtains for the consumer because many different organizations have made them uniform, plentiful and affordable.

28. Answer A. LGd course manual p. 46 - A defined process is perfectly tailored to operational management because we want people to follow the exact same steps day after day. Projects or new initiatives are a very different animal. They are all about creating something we haven’t had before. They are about creating something new and in some way different. By this definition, the processes we used to execute the last project won’t necessarily work with next. Success relies on flexibility, and flexibility requires a different way of doing things. Projects have the greatest chance of success when empirical processes are used.

29. Answer D. LGd course manual p. 46 - Empirical processes focus on creating a situation with the highest using three primary drivers visibility, inspection and adaptation. Flexibility is not a driver.

30. Answer C. LGd course manual p. 46 - If one or more of the processes are determined out of control the processes change. Once you can see the drivers in a process and have taken the time to examine those variables to ensure you know which variables are in control and which ones are not, the only thing left is to fix those processes that are not performing as expected. This step is called adaptation.

31. Answer A. LGd course manual p. 46 - The PO is the individual responsible for representing the interests of all stakeholders, obtaining funding, defining the initial requirements, defining the return on investment or ROI, and the project objectives. They are the primary owner of the Product Backload, a document where the User Stories, features or requirements of the project are listed in rank order from most important to least important from the perspective of the business.



Page 85

32. Answer B. The Scrum Guide p. 12 & LGd Course Manual p.49 - "The Product Backlog is an ordered list of everything that might be needed in the product and is the single source of requirements for any changes to be made to the product. The Product Owner is responsible for the Product Backlog, including its content, availability, and ordering."

33. Answer D. The Scrum Guide p. 12 & LGd Course Manual p.49 - "The Product Backlog is an ordered list of everything that might be needed in the product and is the single source of requirements for any changes to be made to the product. The Product Owner is responsible for the Product Backlog, including its content, availability, and ordering. A Product Backlog is never complete. The earliest development of it only lays out the initially known and best-understood requirements. The Product Backlog evolves as the product and the environment in which it will be used evolves. The Product Backlog is dynamic; it constantly changes to identify what the product needs to be appropriate, competitive, and useful. As long as a product exists, its Product Backlog also exists. The Product Backlog lists all features, functions, requirements, enhancements, and fixes that constitute the changes to be made to the product in future releases. Product Backlog items have the attributes of a description, order, estimate and value."

34. Answer C. The Scrum Guide p. 13 & LGd Course Manual p.49-50 - The Development Team is responsible for all estimates. The Product Owner may influence the Development Team by helping it understand and select trade-offs, but the people who will perform the work make the final estimate.

35. Answer B. LGd course manual p. 47 - The Development Team is self-managing, self-organizing, and cross functional. The team does not have a project manager or functional leader who directs the team’s efforts. The Development Team is also small. According to the rules of Scrum, the team size is six plus or minus three. This puts the optimal team size somewhere between three and nine individuals.

36. Answer A. LGd course manual p. 47 - The Development Team is self-managing, self-organizing, and cross functional. The team does not have a project manager or functional leader who directs the team’s efforts. The Development Team is also small. According to the rules of Scrum, the team size is six plus or minus three. This puts the optimal team size somewhere between three and nine individuals.

37. Answer D. LGd course manual p. 47 - The Scrum Master is responsible for the Scrum process, teaching Scrum to everyone, implementing Scrum so it fits with culture, and ensuring that everyone follows Scrum’s rules & practices. The closest approximation to in a linear project is the Project Manager, but there are some key differences, at least from the perspective of the Agilist. Most Agilists believe that traditional project managers are only part of hierarchical organizations with the project manager at the top. All the resources report to the PM. Additionally, this person serves as an administrator directing the team, but having no technical skills or knowledge of the project. This is a huge over simplification of the role, but makes for a nice comparison. A Scrum Master serves as a facilitator. Remember, a Scrum Development Team is self-managing. The expectation is that the Scrum Master role is to only help the team, to ask probative questions, to ensure the team knows the Scrum process and follows it. Development Team members report to each other and not the Scrum Master so the Scrum Master has no formal authority to make anyone do anything.



Page 86

38. Answer B. LGd course manual p. 48 - Often Agilists use an acronym to describe the expected behavior of the Development Team. It is CFORCE. The C stands for Committed. An Agile Development Team must be committed to the Team’s goals and to the other members of the Team. F stands for focused. This criteria goes back to an earlier point. A Development Team must be focused on one and only one project. O stands for open. Each member of the team must be open to receive and provide honest criticism intended to improve the project and the team. Team members must always assume positive intend of their compatriots. R stands for respected and respectful. This requirement is also tied to how team members treat each other. It is expected that each team member is a respected part of the organization and that they respect all the other members of the team. Team members must give respect in order to receive it. The C stands for courageous. The team must take risks, find innovative solutions, and focus on finding the best solutions to meet the needs of the business. Finally, we have the E, which stands for extreme. Scrum calls on the Development Team to be zealous in the pursuit of the mission.

39. Answer C. LGd course manual p. 48 - Often Agilists use an acronym to describe the expected behavior of the Development Team. It is CFORCE. The C stands for Committed. An Agile Development Team must be committed to the Team’s goals and to the other members of the Team. F stands for focused. This criteria goes back to an earlier point. A Development Team must be focused on one and only one project. O stands for open. Each member of the team must be open to receive and provide honest criticism intended to improve the project and the team. Team members must always assume positive intend of their compatriots. R stands for respected and respectful. This requirement is also tied to how team members treat each other. It is expected that each team member is a respected part of the organization and that they respect all the other members of the team. Team members must give respect in order to receive it. The C stands for courageous. The team must take risks, find innovative solutions, and focus on finding the best solutions to meet the needs of the business. Finally, we have the E, which stands for extreme. Scrum calls on the Development Team to be zealous in the pursuit of the mission.

40. Answer D. LGd course manual p. 48 - Most people are familiar with a project vision by another name, the Project Charter. Many Agilists would contend that the two documents are not the same thing, but this has more to do with many project managers failing to create proper charters than the comparison. The Vision sets the direction of the project and guides the Scrum Team. In 2004, Schwaber described the Vision this way, “The minimum plan necessary to start a Scrum project consists of a vision and a Product Backlog. The vision describes why the project is being undertaken and what the desired end state is.: (Schwaber 2004, p.68)

41. Answer A. LGd course manual p. 48 - A well formed Vision is a single page document that answers a number of questions. These questions cover five major areas: The Business Need, The Project Justification, The Success Criteria, The Project's Prioritization, and any Constraints or Assumptions. A Business Case offers much of the same information as it explains why the business needs the product or service of the project.

42. Answer C. LGd course manual p. 49 - A common way to validate your Vision is to answer the elevator test. Can you explain the product, service or result of the project in the time it takes to ride up in an elevator? (Moore 2006 p. 152).

43. Answer D. LGd course manual p. 48-50 - The two documents necessary required to implement Scrum. The first of these documents in called the Product or Project Vision. The Vision sets the direction of the project and guides the Scrum Team. In 2004, Schwaber described the Vision this way, “The minimum plan necessary to start a Scrum project consists of a vision and a Product Backlog. The vision describes why the project is being undertaken and what the desired end state is.: (Schwaber 2004, p.68). The second document in the list of four is a Ranked Product Backlog. More often than not the literature talks about just the Product Backlog. A Product Backlog is a listing of the User Stories, features or requirements.



Page 87

44. Answer A. LGd course manual p. 49 - A story is a self-contained unit of work agreed upon by the developers and the stakeholders. Stories are the heart of Scrum, and the building blocks of the sprint. Additionally, each story must provide functionality that has real value to the business. A User Story is different from a feature however as a feature represents a distinct element of functionality that provides capability to the business while a User Story is a small aspect of a feature that is used to get feedback from stakeholders and find out if you are doing anything wrong.

45. Answer B. LGd course manual p. 50 - Themes may be thought of as groups of related stories. Often the stories all contribute to a common goal or are related in some obvious way, such as focusing on a single customer. Sometimes stories within a theme may be dependent on each other, and then do not necessarily encapsulate a specific work flow or be delivered together.

46. Answer C. LGd course manual p. 50 - Epics resemble themes in the sense that they are made up of multiple stories. Sometimes they also resemble stories in the sense that may appear as a big story. Unlike themes, epics often comprise a complete workflow for a user and they typically cut across all or some of the three business dimensions (time, scope and organizations). Another important difference is while the stories that comprise an epic may be completed independently, their business value isn’t realized until the entire epic is complete. This means that it rarely makes sense to deliver an epic until all of the underlying stories are complete.

47. Answer A. LGd course manual p. 50 - Epics are most often seen when teams are implementing SAFe as they are often used to enhance business value of the FULL solution set or bring a range of technologies together. They are often key economic drivers for the portfolio.

48. Answer D. LGd course manual p. 50 - Rocks are pieces of functionality used as placeholders when there is an absence of information. The rock acts as a signpost signifying the team does have information about a feature or requirement.

49. Answer B. LGd course manual p. 51 - A short iteration of fixed time where features are produced that have tangible value to the customer. The original Rules of Scrum stated that each Sprint was 30 days in length. However, over the years Scrum has adopted the practices from other Agile methodologies and the common practice is to see sprints of between two and six weeks in length. The key is that each sprint must be the exact same fixed length, and each MUST produce fully tested functionality that has real value to the customer.

50. Answer A. LGd course manual p. 50 - A release is a group of related sprints. Releases become necessary for a variety of reasons. The Rules of Scrum require every sprint to provide fully tested, production ready features. However, there are many situations where it is either impractical or ill advised to put the features completed from a single sprint into production. Imagine an organization that has set release windows where new code can be put into the production system. In these situations, the Development Team simply places the results from sprints “on the shelf” until all the releases that are part of the release are complete and then the entire group of features is place into production together.

51. Answer B. LGd course manual p. 51 - Every project begins the same way. Just imagine someone in the organization has a problem so they complete a single page document that starts the ball rolling. This document is a Vision. Some type of governance decides the idea has merit so they assign a team to do some initial work. The Development Team conducts an initial kickoff meeting with the Product Owner and key stakeholders to develop an initial Ranked Product Backlog. Once the Development Team has the initial Backlog they enter the Release Planning Meeting. Although the Kickoff Meeting is a common solution for project initiation the Release Planning Meeting is the first official meeting listed in the Scrum Guide.

52. Answer C. LGd course manual p. 52 - The Sprint Planning Meeting represents the first step of the process that gets repeated with each sprint. The purpose of the Sprint Planning Meeting is to plan the work of the current Sprint, and it officially kicks off the sprint. The meeting is broken into two parts.



Page 88

53. Answer D. LGd course manual p. 52 - The Release Planning Meeting serves several purposes. The Development Team first uses the meeting to examine the backlog items to determine how they need to be grouped together to produce releases. Additionally, the team needs to determine how long each sprint needs to be. Remember, each User Story must fit into a single sprint. So the Team is tasked with getting a sprint length that is as short as possible, but long enough to deliver fully tested, production ready results that have real value to the business. To do this, the Team must somehow determine estimates for each PBI. There are a number of techniques commonly used for this purpose that are discussed later in this book. The estimates are used by the Development Team to ensure each sprint is approximately the same size. Once the Development Team has determined how long the sprints will be and how the sprints will be grouped into releases, then team is done with the Release Planning Meeting. Approximately once a quarter the team must revisit the Release Planning Meeting. Tasks are created and managed in the sprint planning meeting

54. Answer A. LGd course manual p. 52 - The process of gaining more detail about a feature or backlog item is called Backlog Grooming. This is process where the Product Backlog Items are defined in enough detail that the Development Team can build the feature.

55. Answer C. LGd course manual p.51-52 - No User Story could be larger than a single sprint.

56. Answer B. LGd course manual p. 53 - Each day begins the same way with a meeting called the Daily Scrum. This is a ten to fifteen minute meeting that provides the Team with basic project status and communication. Each day the Development Team stands around the Scrum or Team Board and answers three questions: What did they accomplish yesterday? What are they going to accomplish today? What impediments do they have?

57. Answer D. LGd course manual p. 53-54 - Each day begins the same way with a meeting called the Daily Scrum. This is a ten to fifteen minute meeting that provides the Team with basic project status and communication. Each day the Development Team stands around the Scrum or Team Board and answers three questions. Each member of the Development Team reports their results to the other members of the Development Team and NOT to the Scrum Master or Product Owner who are also present. The Scrum Master is tasked to act as a facilitator and the PO is only an observer.

58. Answer B. LGd course manual p. 54 - While the Development Team works to produce the days results, the Product Owner works on grooming yet undefined User Stories for future sprints while also working with the Scrum Master to remove impediments.

59. Answer C. LGd course manual p. 54 - No one from the business may add a feature to a sprint once work has commenced, but may add, delete or change items on the Product Backlog at their discretion. The Development Team occasionally has to take User Stories out of the current sprint as new information is learned and may at their discretion pull up a new item if the situation warrants.

60. Answer C. LGd course manual p. 54 - No one from the business may add a feature to a sprint once work has commenced, but may add, delete or change items on the Product Backlog at their discretion. The Development Team occasionally has to take User Stories out of the current sprint as new information is learned and may at their discretion pull up a new item if the situation warrants.

61. Answer A. LGd course manual p. 54 - On the last day of each sprint two meetings are conducted. First, the Team conducts a Sprint Review. This one hour to 90 minute meeting allows the Product Owner to present the results of the sprint to the customers. This is all about showing working product to the people who will really use it. The Development Team wants the product owner to take this responsibility because it both provides a connection from them to the users and helps to ensure their engagement throughout the sprint. The Team is allowed a few hours to prepare for this meeting. Once the Sprint Review is complete, the Development Team conducts a Sprint Retrospective. If the Sprint Review is all about the product of the project, the Sprint Retrospective is all about the process.



Page 89

62. Answer B. LGd course manual p. 54 - Once the Sprint Review is complete, the Development Team conducts a Sprint Retrospective. If the Sprint Review is all about the product of the project, the Sprint Retrospective is all about the process. The Product Owner attends the Retrospective as a team member and the Scrum Master is only present as a facilitator. This meeting provides the Team an opportunity to review the process and find the best way to improve the process. The team uses a wide range of games and tools to answer the question, “If tomorrow we were 1,000% more efficient what we do to get there?” It is singularly focused on the process the Development Team is using to achieve their results.

63. Answer C. LGd course manual p. 55 - Another practice sometimes used by Scrum teams is Iteration 0. This is NOT part of Scrum found in the Scrum Guide. Remember the basic rule we established for Scrum that said every single sprint would be the same length of time and must produce functionality that has real value to the business? Iteration 0 violates both those rules. The goal of Iteration 0 is to produce two items that do not initially have value to the business. These are the core architecture and feature list. It is not unusual for this work to take significantly longer than a single sprint, and as such it violates the Rules of Scrum requiring and out. If a team has decided to use Iteration 0 because they believe the project needs a more formal architectural plan and/or work on its feature list it is important that the team also provides an iteration or milestone plan to ensure the team quickly moves into more standard Scrum sprints.

64. Answer B. LGd course manual p. 56 - The five areas of focus within Extreme Programming include: Goals, Activities, Values, Principles and Practices.

65. Answer D. LGd course manual p. 56 - Extreme Programming defines four core activities necessary to meet its stated goal. These include:

Listening – Programmers must listen to customers and understand the business processes. Designing – Software must be designed as components without complexity or dependencies between components. Coding – Is the meat of the methodology. It is the most important part according to XP advocates. Testing – The team must test a functionality.

66. Answer C. LGd course manual p. 56 - Values represent what the team hold highest. When discussing Extreme Programming, here are its core values: Simplicity, Communication, Feedback, Courage, and Respect.

67. Answer A. LGd course manual p. 56 - Values represent what the team hold highest. When discussing Extreme Programming, here are its core values: Simplicity, Communication, Feedback, Courage, and Respect.

68. Answer B. LGd course manual p. 57 - The first grouping of practices is called Fine Scale Feedback. It is the notion of providing rapid feedback to each individual developer in a fashion they can actually act upon it in a timely manner. The four practices tied to Fine-Scale Feedback include: Paired Programming, The Planning Game, Test-Driven Development, Whole Team.

69. Answer B. LGd course manual p. 57 - The Planning Game represents the main planning process used in Extreme Programming. Like the Sprint Planning Meeting in Scrum, The Planning Game is a meeting that occurs once per iteration. In most XP environments, this means once a week. There are two parts to the Game, Release Planning and Iteration Planning. Release planning is focused on determining which requirements are included in which near-term release and when specifically they should be delivered. Both the customer and developer are part of this process. It includes three phases.

70. Answer C. LGd course manual p. 57 - The Planning Game represents the main planning process used in Extreme Programming. Like the Sprint Planning Meeting in Scrum, The Planning Game is a meeting that occurs once per iteration. In most XP environments, this means once a week. There are two parts to the Game, Release Planning and Iteration Planning. Release planning is focused on determining which requirements are included in which near-term release and when specifically they should be delivered. Both the customer and developer are part of this process. It includes three phases. In the Commitment Phase, the business and developers commit to the functionality to include and next release date.



Page 90

71. Answer D. LGd course manual p. 58-59 - Shared Understanding represents the set of practices that ensure all the members of the team have the same information about the project and its product. It requires more than just access to information though as you will see from its four practices: Coding Standards, Collective Code Ownership, Simple Design, and System Metaphor.

72. Answer A. LGd course manual p. 59 - “Simplest” is best approach to software design. Often, software fails because of the layers of complexity that constantly get added until the application collapses under its own weight. XP attempts to peel back the layers of the onion to achieve a design that is more robust and long lasting. A common XP expression used along with Simple Design is the acronym YAGNI which stands for “You Aren’t Gonna Need It.” This expression means that something is not needed, and it will complicate things. Therefore, the best solution is to throw it out.

73. Answer A. LGd course manual p. 59 - The last practice found in Extreme Programming is part of a group called Programmer Welfare. It is the practice of a Sustainable Pace where programmers are not required or even allowed to more than 40 hours per week on average and no two weeks in a row have overtime. The idea is based on the concept that programming is highly technical, detailed work and that fresh programmers produce better code. A key enabler of this concept is frequent code merges of code that are always executable. This code must constantly be tested to ensure it is of a high quality.

74. Answer C. LGd course manual p. 59-60 - Like most methodologies, Extreme Programming has a five-step process. These steps include: Envision, speculate, Explore, Adapt, and Close.

75. Answer A. LGd course manual p. 61-62 - FDD is a model-driven, short-iteration methodology that has five basic processes or activities. In FDD the first two activities are used to generate an overall model shape. Then, the final three processes or activities are iterated for each feature. The five processes or activities include: Develop the Overall Model, Build Feature List, Plan By Feature, Design By Feature and Build By Feature.

76. Answer C. LGd course manual p. 62 - Since features are small, completing a feature is a relatively small task. For accurate state reporting and keeping track of the software development project it is important to mark the progress made on each feature. Feature-Driven Development therefore defines six milestones per feature that are to be completed sequentially. The first three milestones are completed during the Design By Feature activity, the last three are completed during the Build By Feature activity. To help with tracking progress, a percentage complete is assigned to each milestone. At the point that coding begins a feature is already 44% complete (Domain Walkthrough 1%, Design 40% and Design Inspection 3% = 44%). The code is then worth 45%. Code Inspection provides another 10%, and finally Promoting the Feature to Build adds 1%.

77. Answer D. LGd course manual p. 62 - The first three milestones are completed during the Design By Feature activity, the last three are completed during the Build By Feature activity. To help with tracking progress, a percentage complete is assigned to each milestone. At the point that coding begins a feature is already 44% complete (Domain Walkthrough 1%, Design 40% and Design Inspection 3% = 44%). The code is then worth 45%. Code Inspection provides another 10%, and finally Promoting the Feature to Build adds 1%.

78. Answer C. LGd course manual p. 62 - Domain models reflect our understanding of real world entities and their relationships and responsibilities. Key to remember is that effective Domain Modeling may only occur in the context of the system-level requirements that are often captured as Use Cases or User Stories. Domain Modeling is used to support the analysis of Epics, Backlog refinement at the program and team levels, design workshops at different levels, and the refinement of the Product Vision and Roadmap.



Page 91

79. Answer B. LGd course manual p. 64 - FDD has six primary roles, five support roles and three additional roles. FDD, like all Agile Methodologies argues people are the most important aspect when you consider the key drivers of people, process, and technology. The primary roles include: Project Manager, Chief Architect, Development Manager, Chief Programmer(s), Class Owners, Domain Experts. The Class Owners are the developers who work as members of those three to six member teams led by the Chief Programmers who design, code, test and document the features required on the project. They are called Class Owners because that is exactly who they are. FDD ensures every single class (defined as a breakout of code) is owned by one and only one person. If anything is wrong with it they are responsible.

80. Answer A. LGd course manual p. 64 - FDD has six primary roles, five support roles and three additional roles. FDD, like all Agile Methodologies argues people are the most important aspect when you consider the key drivers of people, process, and technology. The primary roles include: Project Manager, Chief Architect, Development Manager, Chief Programmer(s), Class Owners, Domain Experts. The Domain Experts are users, sponsors, and business analysts who have the specific knowledge the Class Owners rely upon to deliver the correct system.

81. Answer D. LGd course manual p. 64-65 - In addition to the primary roles, Feature Driven Development relies on five supporting roles to succeed. These roles are not considered primary to the team delivering the required features, but they are important roles to the project’s success. These roles include: Release Manager, Language Guru, Build Engineer, Toolsmith, and the System Administrator.

82. Answer D. LGd course manual p. 63 - The Domain Object Modeling is the process of building Class Diagrams depicting the significant types of objects within a problem domain and the relationships between them. The first published description of FDD appear as part of a concept called UML in Color. This is the same as plain UML, but the classes are color-encoded. This is done to allow for quick understanding of the dynamics of the problem domain. Each of the class categories are represented by a different color that has specific meaning: Yellow – A role being played by a person or an organization; Blue – A catalogue-like description of an object, but it is not considered the object itself; Green – A party (individual), place, or thing. The green class usually has some identifying attributes, such as a serial number or person’s name associated with it; Pink – A moment in time or an interval of time usually associated with some business process.

83. Answer C. LGd course manual p. 62 - Domain Object Modeling – The team explores and explains the domain of the problem. That probably doesn’t mean very much to you at this point so let’s spend a few minutes discussing Domain Modeling. Domain Modeling is a way to describe and model real world things and the relationships between them. This is collectively called the “Problem Domain Space.” Domain Modeling is used by lots of Agile techniques including FDD and SAFe. It is considered one of the key models used in software engineering and there is a saying, “if you only model one thing in Agile, model the domain.”

84. Answer D. LGd course manual p. 61 - Build Feature List — Knowledge and information from the initial modeling effort is used to identify the list of features by functionally decomposing the domain into subject areas. Each subject area contains business activities with steps that form the basis for a categorized feature list. Think of these “features” as small pieces of client-valued functionality expressed in the form “<action><result><object>”. This is a IT specific way of writing features that might have little meaning if you do not come from a software development background. Don’t worry, you do not need to be a software developer to pass the PMI-ACP Exam. These features need to be small enough that they can be completed in not more than two weeks. Once the team has completed this activity they have their overall model and are ready to proceed into the activities used to actually produce the features of the project.

85. Answer C. LGd course manual p. 63 - Configuration Management – Labeling code, tracking changes, & managing source code.



Page 92

Slide 85

Agile Principles & Mindset Part II

Dynamic Systems Development Method As we begin the second half of the Agile Principles and Mindset, it is time to introduce the next Agile Methodology: the Dynamic Systems Development Methodology. DSDM was created in 1994 to add discipline to Rapid Application Development. It was originally designed to be compatible with both ISO 9000 and Prince2. In the United States the Prince2 standard is not well known, but it represents a highly detailed project management methodology from the APM Group in the United Kingdom. APMG is also responsible for the ITIL standard and several others. To learn more about this organization, which was founded in 1993, visit http://www.apmgroupltd.com. Much of the information provided on DSDM can be found on the DSDM website, at http://www.dsdm.org.

The Dynamic Systems Development Methodology is both iterative and incremental. This means it is just like many other Agile methodologies. It fixes cost, quality, and time at the very beginning of the project. This fact makes it somewhat unique. Most Agile methodologies play an interesting game with the traditional triple constraints of project management. For those of you not familiar with the relationship between these three legs, and the arguments that go along with it, I will briefly summarize this.

The triple constraints of project management is sometimes known as the iron triangle, or Dempster’s triangle. The idea is that there is a connection between a project’s key drivers: time, cost, scope and quality. Modern versions of this relationship visualize it as a pyramid instead of a triangle to allow for the treatment of scope and quality as separate variables, whereas the traditional triangle has them together. The old adage is that you can have two out of three sides of this triangle. Many traditional, linear projects struggle with this triangle because the scope changes while the business side of the project expects the team to deliver the updated scope within the same time and budget. Two sides are locked while one grows. Usually, the side that gives is quality. The product gets released on time, but the customer pays because the product fails to work as promised. Most Agile methodologies respond to this problem by fixing the time side at a micro-level (think iterations or sprints) and allowing the scope to flex. The customer is then tasked with deciding when the project has spent enough to provide maximum value. DSDM goes one extra step by fixing the cost and quality sides as well. This forces the business to constantly evaluate the trade-offs between cost and scope.

DSDM has gone through a number iterations beginning with its first rebranding in 2007, when the name was changed to DSDM Atern. The addition of Atern was a reference to the Artic Tern, a collaborative bird that can travel great distances. In its natural behavior, the bird was seen to epitomize many elements of the method, such as prioritization and collaboration. In 2014, the framework was revised again and the name was changed back to simply DSDM. Today, DSDM is most often used in conjunction with Scrum to provide an overall project framework. DSDM advocates argue that it is the ideal wrapper for more limited Agile frameworks.



Page 93

Slide 86

Advocates also argue that DSDM provides the full project focus while a method like Scrum only focuses on the product development process.

We begin with the Dynamic Systems Development Method Lifecycle. The visualization for this lifecycle is sometimes referred to as the “Cheese and Pizza Diagram.” At the top of the diagram is the project’s upfront work, namely it’s feasibility and foundation. This is where the team understands the nature of the business problem and determines the feasibility of the solution. They begin with Feasibility in order to decide whether a proposed project is viable both from a business AND a technical perspective. They achieve this through a high level investigation of the potential solutions, costs, and timeframes. Feasibility typically has six objectives that include the following:

To establish whether there is a feasible solution to the business problem described in the Terms of Reference which is defined during Pre-Project.

To identify the benefits likely to arise from the delivery of the proposed solution.

To outline possible approaches for delivery, including strategies for sourcing the solution and for project management.

To describe the organization and governance aspects of the project. To state first-cut estimates of timescale and costs for the project overall. To plan and resource the Foundations phase.

Before starting Feasibility, it is assumed that the Terms of Reference for the project have been approved, and that the required resources necessary to carry out the feasibility investigation are available. Additionally, the Business Visionary must have sufficient time available to help shape the project. Once the Feasibility is determined, the project moves to the Foundation Phase.

The Foundation Phase works to determine the firm and enduring foundations of the project in the three essential perspectives: business, solution and management. It does this by combining them to provide a clear project focus that is both robust and flexible. This requires that detail, especially around the solution, is strictly limited so that it does constrain the way the solution evolves but still clearly demonstrates how the solution will meet the needs of the business. The objectives for this phase include:

To baseline the high-level requirements for the project and describe their priority and relevance to the business need.



Page 94

Slide 87-88

To describe the business processes to be supported by the proposed solution (where appropriate).

To identify the information used, created, and updated by the proposed solution.

To describe the strategies for all aspects of solution deployment. To detail the Business Case for the project. To start designing the solution architecture and identifying the physical or

infrastructural elements of the solution. To define the technical implementation standards. To describe how quality will be assured. To establish appropriate governance and organization for the project. To describe the solution development lifecycle for the project, along with the

techniques to be applied in managing the project and in demonstrating and communicating progress.

To baseline a schedule for development and deployment activities for the solution.

To describe, assess and manage the risk associated with the project.

Once the foundation or cheese is laid, the project progresses to its iterative stages which include the two pizzas. The Functional Model Iteration or Exploration Iteration is the first pizza. This is where the team develops a model they believe will meet the customer’s needs. This is a critical aspect of DSDM. It uses prototypes which are elsewhere called Functional Models.

The second pizza is the Design and Build Iteration, which is sometimes simply referred to as Engineering. This is the phase where the team builds the actual product based upon the previously designed prototype. The final stage is referred to as the pizza box. This represents the implementation or deployment phase, where the completed product is placed into production. The two pizzas and the pizza box are iterated repeatedly. The key to this model is that it is not a flowchart. The team flips between Exploration and Engineering a lot.

There are four potential outcomes in DSDM from deployment. These include:

All requirements have been satisfied. In this case, there is no further work currently needed, and there is no returning arrow.

A major change of scope was discovered during development that had to be ignored for the time being in order to deliver on the required date. This means returning to the foundations and reinitiating the process from there.

Features that were already planned for the next increment now need to be added. In this case the process returns to exploration.

The next increment will solely address areas of technical concern. In this case the process returns to engineering.

There are a number of prerequisites required for using the Dynamic Systems Development Method. These include:

Acceptance of the Atern philosophy before starting work. This philosophy is relatively simple. A project must be aligned to clearly defined strategic goals of the organization. The team must then focus on the early delivery of



Page 95

the real benefits to the business. According to the Atern philosophy, this is best achieved when key stakeholders understand the business objectives, are empowered to an appropriate level, and collaborate to deliver the right solution. This solution must be delivered in the agreed timescale and according to the priorities set by the business. The stakeholders must be prepared to accept a fit-for-purpose solution. They must also be prepared to accept the fact that change is inevitable whenever the team comes to understand more about the solution being delivered.

Appropriate empowerment of the Solution Development Team. Stakeholders must empower the team to discover the optimal solution to the business problem given the limitations of time and money provided. It is assumed that the team will provide transparency through the use of an iterative process.

Commitment of senior business management to provide the necessary Business Ambassador involvement. Stakeholders are not allowed to assign work to the team and walk away from the project. It is assumed that a Business Ambassador will be involved daily with the project team.

Incremental delivery. The team will work in short iterations to deliver valuable components of working software. This means the business will receive the functionality in a series of steps, rather than all at once.

Access by the Solution Development Team to business roles. For the project to succeed, the team must have constant access to the business stakeholders to continually improve their understanding of the requirements and to verify outputs.

Solution Development Team stability. The Development Team must not see team members flowing on and off the team. This prevents the Team from building the cohesiveness necessary to deliver business results optimally.

Solution Development Team skills. The Development Team must possess the skills necessary to successfully deliver the project results and understand the problem space.

Solution Development Team size. The Development Team needs to be small. The latest incarnation of DSDM defines 13 specific roles. DSDM is the only Agile methodology that explicitly calls out role responsibilities. It is a big deal in DSDM. However, the average Development Team is 2 to 6 members.

A supportive commercial relationship. There must be a viable market for the product of the project.

DSDM delineates 13 specific roles within a project. These roles have varying degrees of importance. A key difference between DSDM and other Agile Methodologies is how detailed these roles are and how much emphasis is placed on them.



Page 96

Slide 89 Business Sponsor — This is the most senior project-level business role. The Business Sponsor is the Project Champion who is committed to the project, to the proposed solution, and to the approach to delivering it. This role is specifically responsible for the Business Case throughout the process, however formally or informally this may be expressed. This role will own the solution once it is delivered, and will be responsible for the realization of any benefits associated with it. The Business Sponsor must hold a sufficiently high position in the organization to be able to resolve business issues (e.g. to force open closed doors) and make financial decisions. This role has a crucial responsibility to ensure and enable fast progress throughout the project. There should be only one person responsible for this role. This person should be committed and available for the duration of the project, providing a clear escalation route.

Business Visionary — This is a senior project-level business role. More actively involved than the Business Sponsor, the Business Visionary is responsible for interpreting the needs of the Business Sponsor, communicating these to the team, and ensuring that those needs are properly represented in the Business Case when appropriate. The Business Visionary remains involved throughout the project by providing the team with strategic direction and by ensuring that the solution delivered will enable the benefits described in the Business Case to be achieved.

Project Manager — The Project Manager role is responsible for all aspects of the delivery of the solution. This role is focused on providing high-level management direction to the project team(s) and is also responsible for managing the working environment in which the solution is evolving. The Project Manager co-ordinates all aspects of the management of the project at a high level, but does so in line with the Atern concept of empowerment. This means the Project Manager is expected to leave the detailed planning of the actual delivery of the product(s) to the Team Leader and to members of the Solution Development Team. Despite the fact that the Project Manager role is delivery-focused, this does not dictate from where in an organization the role is resourced. Appropriate sourcing of the role will depend on the skills and knowledge required. It is vital that the Project Manager take responsibility throughout the duration of the project. This includes both business and technical delivery aspects of the project, from establishing the Foundations of the project through to the Deployment of the solution.

Technical Coordinator — As the project’s technical design authority, the Technical Coordinator ensures that the Solution Development Teams work in a consistent way, that the project is technically coherent, and that the project meets the desired technical quality standards. The role provides the glue that holds the project together, while also advising on technical decisions and innovation. The Technical Coordinator performs the same function as the Business Visionary does from a business perspective.

Team Leader — The Team Leader reports to the Project Manager and ensures that the Solution Development Team functions as a whole and meets its



Page 97

objectives. The Team Leader works with the team to plan and coordinate all aspects of product delivery at the detailed level. This is a leadership role rather than a management role. The person holding it will ideally be elected by his or her peers and is considered by them to be the best person to lead them through a particular stage of the project. It is therefore likely that they will also perform another Solution Development Team role (e.g. Business Analyst, Solution Developer or Solution Tester) in addition to their team leadership responsibilities. It is also feasible that the person carrying out the Team Leader role can be different from one timebox to another, where timeboxes have a different focus.

Business Ambassador — This is a business role within the Solution Development Team. The Business Ambassador generally comes from the business area that is being addressed by the project, and provides business-related information from the perspective of those who will ultimately make direct use of the solution. The role provides the business perspective for all decisions related to the way the solution’s fitness for business purpose is defined and implemented. Working closely with the rest of the Solution Development Team, the Business Ambassador guides the evolution of the solution, and brings other users’ inputs and ideas to the project as required. As a true ambassador, the role is responsible for the day-to-day communication channels between the project and the business. The Business Ambassador must have the desire, authority, responsibility and knowledge to be able to ensure that the right solution emerges to meet the business need. This does not necessarily imply a senior position within the organization, but it does necessitate a level of empowerment during the project as well as an allocation of time to fully participate in the project as required.

Business Analyst — The Business Analyst is fully integrated with the Solution Development Team and focuses on the relationship between the business and technical roles. This role ensures that accurate and decisive direction is provided to the Solution Development Team on a day-to-day basis. The Business Analyst ensures that the business needs are properly analyzed and are correctly reflected in the guidance the team receives to generate the solution. Active involvement of the business users in the process of evolving the solution is vital to the success of a Atern project, so it is important that the Business Analyst does not become an intermediary between the Developers and the Business Ambassadors and Advisors, but rather supports and facilitates the communication between them.

Solution Developer — The Solution Developer interprets business requirements and translates them into a deployable solution that meets functional and non-functional needs. A person assuming a Solution Developer role should ideally be allocated full time to the project they are working on. Where they are not full time, the project ought to be their first priority. If this cannot be achieved, significant risk is introduced with regard to timeboxing. This risk needs to be managed proactively by the Project Manager.



Page 98

Solution Tester — The Solution Tester is fully integrated with the Solution Development Team and performs testing in accordance with the Technical Testing Strategy throughout the project.

Business Advisor — Often a peer of the Business Ambassador, the Business Advisor is called upon to provide specific and often specialist input to solution development or solution testing. The Business Advisor will normally be an intended user or beneficiary of the solution but may, for example, simply provide legal or regulatory advice with which the solution must comply.

Workshop Facilitator — The Workshop Facilitator is responsible for managing the workshop process and is the catalyst for preparation and communication. The Workshop Facilitator is responsible for the context of the workshop, not the content. The Workshop Facilitator should be independent of the outcome to be achieved in the workshop.

Atern Coach — The role of the Atern Coach is to help a team with limited experience using Atern to get the most out of the approach within the context of the wider organization in which they work. The Atern Coach should ideally be independently certified in Atern to ensure competence to fulfil this role. As with any method of working in any context, the approach cannot be followed blindly. If there is something in the project environment that will inhibit the effectiveness of a particular Atern technique, then it is vital that the potential problem is addressed. There are typically two ways of addressing such a problem: the first is to influence the environment to allow the technique to be effective; the second is to adapt or substitute the technique. Either way, an expert in the DSDM process – the Atern Coach – will have the knowledge and experience to help.

Specialist Roles — The Solution Development team roles will not always cover every skill needed in a project. Specialist roles may also need to be involved and brought into the Solution Development Atern teams on an ad hoc basis by the Project Manager or Team Leader to fulfil specific functions. The required roles will depend on the size and nature of the project. Some will be brought in with a view to facilitate skills transfer to the Solution Development Team. Others may be brought in under the role of the Business Advisor as they have specialist knowledge. These roles need to be properly integrated into the project team as appropriate. The required specialist input to the Solution Development Team should be formally planned, the individuals identified and their availability checked so that they can attend relevant meetings, facilitated workshops, etc. Their responsibilities should be defined so that they clearly understand their role and what is expected of them. It is also possible to have Specialist roles at the Project level. At this level, the Specialist involvement is less likely to be ad-hoc and would more commonly be throughout the project. A common example of a Project level specialist role would be an Operations Coordinator, who is responsible for the operational aspects during both design and implementation, and who also ensures that any new solution is included in the Disaster Recovery Plan for the site as relevant.



Page 99

Slide 91

Slide 92

Slide 93

Slide 94

Atern identifies roles in three categories: Project, Solution Development and Other. The business interests are represented by the Business Sponsor, Business Visionary, Business Ambassador, Business Analyst and Business Advisor. The solution/technical interests are represented by the Technical Coordinator, Team Leader, Solution Developer and Solution Tester. Management and ‘other’ interests are represented by the Project Manager, Workshop Facilitator and Atern Coach. On an Atern Project, one role may be taken by several people and one person may take several roles.

The Dynamic Systems Development Method is governed by eight principles. These principles establish the overarching rules every DSDM team must follow as they progress through the project. The eight principles of DSDM include:

1. Focus on the business need — The main acceptance criteria for every project is delivering something that addresses the defined business need.

Clearly define the scope of the system. Understand the true business priorities. Establish a sound business case. Seek continuous business sponsorship and commitment. Guarantee the minimum usable subset of features.

2. Deliver on time — I am sure that this is news, but delivering on time is kind of a big deal. There are many situations where delivering a project late can undermine the very reason for doing the project in the first place. DSDM focuses the team on this principle by:

Timebox project work. This means that the end date of each iteration is fixed.

Focus on business priorities. Technology is not an end unto itself. The product of the project must serve a business need.

Always hit deadlines. This should be obvious, but it doesn’t happen very often.

3. Collaborate — Decisions must be made with users and developers working together quickly. When a team works collaboratively they almost always outperform groups of individuals working independently.

Involve the right stakeholders at the right time throughout the project. Ensure that the members of the team are empowered to make decisions

on behalf of those they represent without waiting for higher-level approval.

Actively involve the business representatives. Build a one-team culture.

4. Never compromise quality — The level of quality must agreed upon at the beginning of the project. Quality cannot be a variable thing. The measure of quality must be quantitative and objective so that both the business and the development team can agree when the features that are part of the minimum usable subset is complete. In order to achieve this result the team must:



Page 100

Slide 95

Slide 96

Slide 97

Set the level of quality at the beginning. Make sure everyone involved in the project understands what success looks like and how it will be measured. False expectation can lead to disaster.

Ensure that quality does NOT become a variable. Quality must be binary. It cannot be a sliding scale. The team must have a clear cutoff.

Design, document, and test appropriately. The team must use the appropriate level of design, testing and documentation for the complexity and importance of the project.

Build in quality by constant review. Every Agile project makes use of an iterative process. These loops allow the team to constantly evaluate their output to ensure that they correctly meet the quality standards.

Test early and continuously. Testing cannot be something done only at the end of the project. The team must test early to catch errors when they are small and never assume they have tested enough.

5. Build incrementally from firm foundations — Incremental delivery provides a number of advantages. An easy way to understand incrementalism is to think about bite-sized chunks. It is much easier to swallow a small bite as opposed to a large one. It also give you confidence that you actually like what you are eating. It is the same for the customer of a software project. Constantly seeing working software confirms that the team is building what they want and therefore gives the customer confidence in the team. It also provides a primary point of feedback for the team. Finally, when these increments are regularly deployed, the organization gains early business value. Key to this principle are the following:

The team strives for early delivery of business benefit wherever possible.

The team continually confirms that the correct solution is being built. The team formally re-assess the priorities and the ongoing project

viability with each delivered increment.

6. Develop iteratively — As we have already learned, iterative development is very closely related to incremental development. Both are also key to Agile. Iterative development is a fancy way of saying short, repeating or looping cycles. The premise is that a team rarely gets things perfect the first time. In most cases, the team needs several cycles with repeated feedback from the customer to get it right. Key to this principle are the following:

Do enough design up front to create strong foundations. Take an iterative approach to building all products. Build customer feedback into each iteration. Accept that most detail emerges later rather than sooner. Embrace change – the right solution will not emerge without it. Be creative, experiment, learn, and evolve.

7. Communicate continuously and clearly — One of the biggest causes of project failure is poor communication. DSDM uses a variety of techniques to improve overall communication for both teams and individuals. DSDM



Page 101

Slide 98

focuses the team on the value of human interaction through the Daily Standups, Facilitated Workshops, and clearly defined roles and user involvement. The extensive use of modelling and prototyping help to ensure that thee product of the project is available for early scrutiny. This principle requires the team to do the following:

Run daily team stand-up sessions. Use facilitated workshops. Use rich communication techniques such as modelling and prototyping. Present iterations of the evolving solution early and often. Keep documentation lean and timely. Manage stakeholder expectations throughout the project. Encourage informal, face-to-face communication at all levels.

8. Demonstrate control — It is essential to be in control of a project at all times. A DSDM team needs to be proactive when monitoring and controlling progress in line with the Foundations Phase products, especially the Business Case. You need to be able to prove you are in control. In order to fulfil this principle, Atern teams, and especially the Project Manager and Team Leader, will need to do the following:

Use an appropriate level of formality for tracking and reporting. Make plans and progress visible to all. Measure progress through focus on delivery of products rather than

completed activities. Manage proactively. Evaluate continuing project viability based on the business objectives.

DSDM advocates the use of several tools and techniques including:

Facilitated Workshops — Facilitated Workshops are a process in which a neutral facilitator who has no stake in the outcome of the workshop enables a group to work together to achieve an agreed goal. That goal can be solving a problem, building a plan, gathering requirements or making a decision. Facilitated Workshops ensure a team-based approach to rich communication and collaboration and they achieve results with speed and with commitment and buy-in to the outcome. They enable people to communicate and collaborate effectively and thus pay enormous dividends.

Modeling and iterative development — Iterative Development follows a fundamental cycle of Identify, Plan, Evolve and Review, which is embedded in the DSDM process. In particular, this process is an intrinsic component of Timeboxing. It ensures that both the Timebox is controlled and that a feedback loop is built into the evolution of the solution. At the Development Timebox level, the Iterative Development cycles are short, typically a matter of days or even hours. However this cycle may also be applied outside a Development Timebox (e.g. to create an DSDM product such as a document or an increment of the solution) and in these circumstances the Iterative Development Cycles will typically be longer. Wherever it is used within DSDM, the feedback afforded by the cycle ensures that the right solution



Page 102

evolves over time, in a controlled manner. The Iterative Cycle is as follows:

Identify — The team agrees on the objective of the next evolution of whatever is being developed at the moment.

Plan — The team works out what needs to be done by whom in order to meet the current objective.

Evolve — The planned activities take place in the agreed timescale. Review — The results of the activities are checked to see if the

objective has been achieved.

The review may conclude that the objective has been fully achieved. If this is the case, then the changes made are accepted and a new baseline of the deliverable is agreed. If required, the cycle starts again with a new evolutionary objective. If the review concludes that the objective has not been met, the team has a choice of either

a) discarding the changes made (reverting to the last baseline, i.e. rolling back to the last agreed version) and possibly planning a new approach to achieving the objective or

b) identifying remedial work required for the objective to be achieved in a new pass through the iterative cycle.

MoSCoW Prioritization — In a DSDM project where time has been fixed, understanding the relative importance of things is vital to making progress and keeping to deadlines. Prioritization can be applied to requirements, tasks, products, use cases, user stories, acceptance criteria and tests. MoSCoW is a technique for helping to understand priorities. The letters stand for:

Must have Should have Could have Won’t have this time

The reason we use MoSCoW in DSDM is that the problem with simply saying that requirements are of High, Medium or Low importance is that the definitions of these priorities are missing. Using MoSCoW means that priorities are specific. The specific use of Must, Should, Could or Won’t Have clarifies the results of failing to deliver that requirement.

These are some possible definitions of what the different priorities mean. It is important to agree on the definitions with the users. Preferably these are agreed upon before the requirements are captured – i.e. before it becomes emotive.

Must Haves — These provide the Minimum Usable Subset (MUS) of requirements which the project guarantees to deliver. This may be defined using some of the following ideas:

Cannot deliver on target date without this No point in delivering on target date without this; if it were not

delivered, there would be no point deploying the solution on the intended date.



Page 103

Not legal without it Unsafe without it Cannot deliver the Business Case without it

Ask the question “what happens if this requirement is not met?” If the answer is “cancel the project – there is no point in implementing a solution that does not meet this requirement,” then it is a Must Have requirement. If there is some way round it, even if it is a manual workaround, then it will be a Should Have or a Could Have requirement. Downgrading a requirement to a Should Have or Could Have does not mean it won’t be delivered, it simply means that delivery is not guaranteed.

Should Haves — Items appearing in this group are considered important but not vital to the business or success of the project.

These may be painful to leave out, but the solution is still viable These may need some kind of workaround, e.g. management of

expectations, some inefficiency, an existing solution, paperwork, etc.

A Should Have may be differentiated from a Could Have by reviewing the degree of pain caused by it not being met, either in terms of business value or numbers of people affected.

Could Haves — Features or requirements in this group are wanted or desirable, but are less important to the business than items appearing in the previous two groups. They will have less of an impact if they are left out as compared to the previously listed groups.

Won’t Have This Time — These are requirements which the project team has agreed it will not deliver. They are recorded in the Prioritized Requirements List where they help clarify the scope of the project. This helps to avoid their being reintroduced ‘via the back door’ at a later date. This also helps to manage expectations so that everyone knows that some requirements will simply not make it into the delivered solution—at least not this time around.

Timeboxing — Timeboxing is a key technique in DSDM, and it is more than just setting short time periods, and partitioning off the development work. It is a well defined process to control the creation of low-level products in an iterative fashion, with several specific review points to ensure the quality of those products and the efficiency of the delivery process. By managing on-time delivery at the lowest level, on-time delivery at the higher levels can be assured. A combination of the initial MoSCoW prioritization of the work within the Timebox and the continual re-assessment of what can be achieved in the agreed timeframe ensures that Timeboxes finish on time, every time. Every Timebox begins with a Kick-off and ends with a close-out meeting. The Timebox itself comprises three main stages or Iterations: Investigation, Refinement, and Consolidation. Each stage represents a pass through the Iterative Development cycle. The model to the right provides a simple visualization of the Timeboxing model. The image not only highlights the



Page 104

beginning and ending stages, but it also shows the three primary stages that are each broken into four smaller parts. As you examine this model, also examine the table that appears on the top of page 98. Pay attention to the amount of time spent on each of the stages. Notice how most of the time is spent in the Refinement Stage. Let us now take a deeper look at each of the stages.

Kick-Off — The Kick-Off is attended by the entire Solution Development Team. This includes the Business Ambassadors, the Project Manager, the Technical Coordinator, and if possible the Business Visionary. There are a number of goals for the DSDM Kick-off:

Review the timebox objectives to gain a common understanding of what is to be achieved.

Ensure that it is still feasible to deliver within the Timebox what was expected at the Foundation stage, and re-plan accordingly if it is not feasible.

Agree upon the acceptance criteria for each product to be delivered. If it is not possible to do this in detail at this point, such an agreement can be deferred to the end of the Investigation iteration. In this case, however, high-level acceptance criteria should be agreed upon until the additional detail is available.

Review the precise availability of team members to participate in timeboxed activities. Remember that commitment to delivery is based on pre-agreed upon (and fixed) minimum resource levels.

Ensure that any dependencies that are on teams working in other Timeboxes (or elsewhere in the business) are understood.

Timebox Nature of the Work Done Suggested

Kick-off Short session for the Solution Development Team to understand timebox objectives and accept them as realistic 1-3 hours

Investigation The initial investigation of the detail of all the products to be delivered by the timebox including agreement on the timebox deliverables and quantitative measures that will prove success

10-20% of timebox

Refinement The bulk of the development and testing of the timebox prod-ucts in line with agreed priorities 60-80% of timebox

Consolidation Tying up of any loose ends related to development and ensuring all products meet their acceptance criteria 10-20% of timebox

Close-out Formal acceptance of the timebox deliverables by the Business Visionary and Technical Coordinator 1-3 hours



Page 105

Analyze the risks associated with the above, and on that basis ensure that there is an acceptable balance of requirements of differing priorities in accordance with the MoSCoW rules.

Investigation Iteration — The aim of Investigation is to provide a firm foundation for the work to be carried out during Refinement. For Timeboxes focused on Exploration activity, the Solution Developers and Business Ambassadors must jointly investigate the details of the requirements and agree on how these requirements will be met as part of the Evolving Solution. This detailed information may be captured as part of a formal product description or as an embellishment of the Prioritized Requirements List. Ideally, an initial prototype of the solution will be created to both demonstrate an understanding of the requirements and provide an early impression of the solution. This will help facilitate assessment of the solution. During Investigation, the entire team should work together on the full set of requirements agreed at the Kick-off. It is necessary to understand all the work intended for completion in the Timebox in full detail if informed decisions are to be made later on about what lower priority requirements may be dropped if necessary.

Refinement Iteration — The aim of Refinement is to complete as much of the development work as possible, and this includes testing the deliverable(s). Development is carried out iteratively, with the primary objective being to meet the detailed acceptance criteria previously agreed upon (at the latest, by the end of Investigation). Refinement should start off with a quick and informal planning session that is focused on determining which members of the team will be working on what products, and in what order. The order of the work should be driven by the MoSCoW priorities for the Timebox. but should be pragmatically influenced by other factors (such as a sensible development order from a technical perspective, the availability of specific resources like Specialists or Business Advisors, and any known cross-team dependencies). Refinement ends with a review by the Business Ambassadors and—when appropriate—other stakeholders. The review should determine which actions are necessary in order to achieve completion of the work according to the acceptance criteria. No new work should be started after this point. Final changes requested at this time should be carefully considered and prioritized. Significant demands for change at this point often expose a lack of appropriate involvement of the business representatives through the Timebox to date. That is a lesson to be learned for the future.

Consolidation Iteration — During Consolidation, the actions agreed upon at the Refinement review are carried out together with any work required to satisfy organizational or project standards. Final Quality Control checks are carried out on all products to ensure they meet the required standards. Any products not meeting the agreed acceptance criteria by the end of the Timebox are deemed not to have been delivered.



Page 106

Close-Out — The primary aim of the Close-out session is to record the formal sign-off or acceptance of all the products delivered by the Timebox. An important secondary aim is to determine what is to be done about any work that was initially part of the Timebox but was not completed. Such work may be either considered for the next Timebox, scheduled for some point in the future, or even dropped from the increment or project completely. If overall timescales are to be met it is important to avoid the situation where unfinished work simply passes unthinkingly in to the next Timebox. A final aim of the Close-Out is to look back on the Timebox to see if there is anything that can be learned to make the development and/or Timebox management process more effective in the future. This could be classed as a mini retrospective and is useful to provide information for the later, formal retrospective. Otherwise the formal retrospective will depend on attendees’ prowess in recollection. If the Timebox has been well controlled, this session should be very short and can be run back-to-back with the kick-off session for the next timebox.

The Daily Stand-Up — The Daily Stand-Up is a concept you have seen before in Scrum. DSDM presents a similar meeting where the team working in a Timebox gets together on a daily basis for a “Stand-up” meeting. Normally run by the Team Leader, it is a daily opportunity to understand progress against objectives at a detailed level, and expose issues that may be getting in the way. The Stand-up in DSDM has the following features:

It is attended by all members of the Solution Development Team.

It runs to a strict format in which each team member in turn describes: What they have been doing since the last Stand-up. What they will be doing between now and the next Stand-up. Any problems, risks or issues they are encountering that are slowing progress.

The meeting has a short and fixed duration – normally no longer than 15 minutes (two minutes per team member + two minutes is a good guide)

It is ideally held with all participants standing in a circle in their normal work-place (this re-enforces the desire to keep the session short and informal)

May be attended by other roles, e.g.

The Project Manager – in order to observe progress and pick up escalated issues.

The Technical Coordinator – in order to keep abreast of technical decisions and pick up escalated technical issues.

Specialists – to participate as transient team members.



Page 107

Slide 99

Slide 100

Slide 101

It is important that the session is used to identify problems and to agree upon who needs to participate in solving any problems that arise. It should not attempt to solve problems if reaching the solution will take any more than a minute or two. The stand-up provides the primary mechanism for the Team Leader to track progress and exert the necessary control over the work of the team to ensure on-time delivery of the agreed products of the timebox.

Crystal Development The next Agile methodology to introduce is Crystal. However, Crystal is not a single methodology, rather it is a family of methodologies. It was originally developed by Alistair Cockburn in the mid-1990s. The methodologies come from several years of research and interviews Cockburn did with teams that were successful despite the fact that they did not use a formal methodology. Crystal represents Cockburn’s list of specific things these teams did to be successful. Crystal is usually described as a “light-weight methodology.” The use of the word Crystal comes from the gemstone where, in software terms, the faces are a different view on the “underlying core” of principles and values. In the metaphor, the faces represent different techniques, tools, standards and roles. The methodology tends to avoid any strict or rigid processes found in other methodologies.

Cockburn begins by differentiating three key terms in his discussion. These terms are:

Methodologies – Sets of elements (e.g. practices or tools) Techniques – Skill areas (e.g. developing Use Cases) Policies – Dictate organizational musts

Once these three terms are defined, Cockburn moves on to defining the core areas of focus for Crystal. These are as follows:

People Interaction Community Skills Talents Communications

Cockburn says that although process is important, it should be considered after these six areas of focus are examined. In other words, process is as a secondary focus. The whole idea behind the Crystal Methods is that the teams involved in developing software typically have a wide variety of skill and talents, so the process element becomes less important. Since teams using Crystal can go about similar tasks in very different ways, Crystal is naturally very tolerant of these process differences. This makes the Crystal family one of the easiest agile methodologies to apply.

In his research, Cockburn describes the behavior of people in teams:



Page 108

Slide 102

Slide 104

“People are communicating beings, doing best face-to-face, in person, with real-time question and answer.”

“People have trouble acting consistently over time.” “People are highly variable, varying from day to day and place to place.” “People generally want to be good citizens, are good at looking around, taking

initiative, and doing ‘whatever is needed’ to get the project to work.”

The points above are why Cockburn devised Crystal methods to be so flexible, and why they avoid the strict or rigid processes that are typically found in other methodologies. However, Cockburn did not stop there. He developed different methods within the family to suit projects of varying team sizes that naturally required different strategies to deliver business value. The family uses colors to denote the “weight” of the methodology being used. As the project becomes larger, has more team members, and is more mission critical to the organization, the appropriate version adds more elements to their process. For the exam, it is a good idea to study the number of people used with each version of Crystal and to make sure you know the order of the color scheme.

The various versions of Crystal share seven common properties or practices. Like the other Agile methodologies we have already covered, these can be thought of as general rules Crystal expects to be followed. These properties include:

Frequent Delivery — Frequent delivery is the regular releasing of iterations of the software program. This idea comes from the 12 Principles of Agile Development. Designers and developers decide what features to include in each release and they design and test for each release. With Crystal Methods, iterations are to be released in short iterations with the timescale being somewhere between weekly to quarterly. By releasing iterations, stakeholders are able to spot problems earlier in the project and this saves a lot of hassle later on. Furthermore, if the end users decide that the project does not do things the way they’d like them to be done, then steps can be taken to resolve this before it is too late. With Crystal Methods, there can be more than one iteration in a release. This is because it may not be feasible to release every iteration, so a collection of iterations are gathered and delivered in a single release.

Reflective Improvement — Reflective improvement involves the Development Team periodically taking a break from regular coding efforts to



Page 109

Slide 106

Slide 107

Slide 108

focus on finding ways to improve their processes. Iterations help with this by providing feedback on whether or not the current process is working. Crystal Methods, uses Reflection Workshops that meet every couple of weeks. These workshops focus on finding processes that are working and are not working well, and then helping the team to modify those processes so they improve.

Close or Osmotic Communication — In Crystal Clear and the other smaller Crystal versions, Osmotic Communication is used. Osmotic Communication involves the team being together in a room and getting information to flow around it. With regards to larger teams (over 8 or so), where distraction can arise, Close Communication is used. The team must be in the same room for this to work. This is because if the developer has to break concentration to move somewhere else to ask a question then his or her thought process is often lost. By using this type of communication, information flows quickly throughout the team. Questions can be rapidly answered and all the team members know what is going on and also have the ability to correct any misconceptions that may arise. By listening to the others in the team, a developer can pick up on what the others are doing, gain experience and develop new ideas. Developers who work near each other can help with problems that other developers encounter. Communication overhead is greatly reduced by using this type of communication. The need for email updates, extra documentation, etc. is lowered. Also, by having the team together, each member knows what the others are doing and so they should be able to take over their teammate's parts of the project as required.

Personal Safety — Personal Safety focuses on the issue of speaking freely within a group of people. If a person is ridiculed whenever they ask a question, suggest an idea, etc. then they will be less likely to speak up the next time. The people in the team must be able to trust each other and feel free to speak up about whatever issues arise.

Focus — Focus in crystal refers to two things. Firstly, focusing refers to concentrating on an individual task in a project for enough time that progress will be made. Secondly, it refers to the direction to which the project is heading. With the first, the flow of progress is taken into account while thinking of issues that affect it such as interruptions, meetings, long questions, phone call, etc. It can take a while to get back into the flow again so this delays completion of the current task. Crystal defines two rules for dealing with issues that may interrupt focus. One is to set a two-hour period where the developer is to have no interruptions. The other one is to assign a developer to a project for at least two days before being switched to another project. The second meaning of focus is pertinent whenever issues such as the definition of goals are discussed. The definitions should be clear and the developers should know exactly what the goals of the project are. The project leader should prioritize the goals, which will allow developers to focus on particular areas.

Easy Access to Expert Users — This involves the developers working with a person of expertise in the project area so that the expert can answers any



Page 110

Slide 109

Slide 110

questions, suggest solutions to problems, etc. The expert user should be an actual/real-life user and not just a tester from the development team. The more involved the expert user is in the project, the better. Their hands-on experience with the need the project is trying to fill is invaluable. The more time that the expert user can give, the more the project will benefit. Such time is not always feasible, but there should be a minimum of at least one, two-hour meeting a week with the expert user. They should also be available for phone calls.

Automated Tests, Configuration Management, and Frequent Integration The idea behind these criteria is that there should be continuous integration and testing so that if any changes are made, then the errors, breakages, etc. can be spotted quickly. Since this is done on a regular basis, problems are less likely to grow and they can therefore be resolved earlier in the project. The process of checking code into a repository can help with identifying the problem code and removing it by either reverting back to the old code or updating the file with correct code. This is where configuration management and automated testing come in. These allow for quicker unit testing and eventual resolution of problems.

Lean Software Development The next methodology is Lean Software Development. It represents a translation of Lean Manufacturing and Lean IT principles and practices into the world of software development. It was adapted from the Toyota Production System by a pro-lean subculture within the Agile community. Lean is most popular with startups that want to penetrate the market or test their ideas to see if they would make a viable business. The term Lean Software Development was originally coined by Mary and Tom Poppendieck in the 2003 book Lean Software Development: An Agile Toolkit. There are seven principles that provide the foundation of Lean Software Development. These principles include:

Eliminate Waste — The Lean Philosophy regards everything not adding value to the customer as MUDA or waste. This waste comes in several forms:

Unnecessary code and functionality Delay in the software development process Unclear requirements Avoidable process repetition (often caused by insufficient testing) Bureaucracy Slow internal communication

For the team to eliminate waste, they must first be able to recognize that it is occurring. If an activity could be bypassed, or the result could be achieved without it, it is considered waste. Another form of waste is found in partially completed code that is eventually abandoned. Waiting for other people, activities, or processes is also considered waste. Discovering waste can sometimes be difficult, therefore a Value Stream Map is a tool that is often used in Lean Software Development to identify waste. Once discovered, the second step is to point out the sources of waste and eliminate them. This process should take place iteratively until even seemingly essential processes and procedures are liquidated.



Page 111

Amplify Learning — The creation of software is a continuous learning process that is combined with the additional challenge of having to manage and develop people. The key to success is the team’s ability to amplify learning. This is done by using short iteration cycles that are coupled with refactoring and integration testing. Increasing feedback via short feedback sessions with customers helps when determining the current phase of development and when adjusting efforts for future improvements. During those short sessions, both customer representatives and the development team learn more about the domain problem and figure out possible solutions for further development. Thus the customers better understand their own needs—based on the existing results of development efforts—and the developers learn how to better satisfy those needs. Another idea in the communication and learning process with a customer is set-based development. This concentrates on communicating the constraints of the future solution (rather than communicating the possible solution), thus promoting the birth of the solution via dialogue with the customer.

The accumulation of defects is prevented by running tests as soon as the code is written.

More time is spent trying new ideas than writing documentation. Mockups and prototypes are regularly presented to the customer to

gather requirements. The use of short iterations is key, and is done in conjunction with

refactoring and integration testing. Set-based development concentrates on communicating the constraints

of the future solution, and not on the possible solution, thus promoting the solution birth via dialogue with the customer.

Decide As Late As Possible — The best results are achieved with an options-based approach using facts instead of assumptions or predictions. Unfortunately, this creates a problem for most teams because it often happens that facts don’t appear until late in the development process. The more complex a system is, the more capacity for change should be built into it, thus enabling the delay of important and crucial commitments. The iterative approach promotes this principle. The ideal is to have the ability to adapt to changes and correct mistakes that might be very costly if discovered after the release of the system. An agile software development approach can move the building of options earlier for customers, thus delaying certain crucial decisions until customers have realized their needs better. This also allows for later adaptation to changes, as well as the prevention of costly earlier technology-bounded decisions. This does not mean that no planning should be involved–on the contrary. Planning activities should be concentrated on identifying the different options and on adapting to the current situation. Planning should also be used to clarify confusing situations by establishing patterns for rapid action. It is important to evaluate different options as soon as possible, and also to maintain the needed flexibility for late decision making. Keys to this principle include:

Planning focus is on the different options and on adapting to the current situation.



Page 112

Planning focus includes clarifying confusing situations and establishing rapid action patterns.

The team must decide on options as soon as information is available.

Deliver As Fast As Possible — The sooner the end product is delivered without major defects, the sooner feedback can be received, and incorporated into the next iteration. The shorter the iterations, the better the learning and communication within the team. With speed, decisions can be delayed. Speed assures the fulfilling of the customer's present needs and not what they required yesterday. This gives them the ability to delay making up their minds about what they really require until they gain better knowledge. Customers value rapid delivery of a quality product. The just-in-time production ideology could be applied to software development, recognizing its specific requirements and environment. This is achieved by presenting the needed result, and letting the team organize itself and divide the tasks for accomplishing the needed result for a specific iteration. At the beginning, the customer provides the needed input. This could simply be presented in small cards or stories. The developers then estimate the time needed for the implementation of each card. Thus the work organization changes into a self-pulling system. Each morning during a stand-up meeting each member of the team reviews what has been done yesterday, what is to be done today and tomorrow, and prompts for any inputs needed from colleagues or the customer. This requires transparency in the process, which is also beneficial for team communication. Another key idea in Toyota's Product Development System is set-based design. If a new brake system is needed for a car, for example, three teams may design solutions to the same problem. Each team learns about the problem space and designs a potential solution. If a solution is deemed unreasonable, it is cut. At the end of a period of time, the surviving designs are compared and one is chosen—perhaps with some modifications based on learning from the others. This is also a great example of deferring commitment until the last possible moment. Software decisions could also benefit from this practice to minimize the risk brought on by big up-front design.

The best results are achieved with an options-based approach using facts instead of assumptions or predictions.

Planning focus is on the different options and on adapting to the current situation.

Planning focus includes clarifying confusing situations and establishing rapid action patterns.

The team must decide on options as soon as information is available.

Empower the Team — The Lean approach focuses on a simple rule: find good people and then trust them to get the job done. Good managers encourage, remove impediments, and avoid micro-managing. The developers should be given access to the customer. The team leader should provide support and help in difficult situations, as well as ensure that skepticism does not ruin the team’s spirit. The most effective teams use a Work-Out Technique in which the managers do NOT tell workers how to do their job.



Page 113

The guidelines are as follows:

Find good people and let them do their own job. Encourage progress, catch errors, and remove impediments. Discourage micro management. People are more than just resources. They simply require motivation

and a higher purpose. The developer should be given access to the customer.

Build Quality In — The customer needs to have an overall experience of the System. This is the so-called Perceived integrity issue: how it is being advertised, delivered, deployed, accessed, and priced, as well as how intuitive its use is and how well it solves a problem. Conceptual integrity means that the system’s separate components work well together as a whole, with balance between flexibility, maintainability, efficiency, and responsiveness. This can be achieved by understanding the problem domain and solving it at the same time, not sequentially. The needed information is received in small batch pieces, not in one vast chunk. Preferably this is done with face-to-face communication and not written documentation. The information flow should be constant in both directions–from customer to developers and back. This helps to prevent developers from receiving a large stressful amount of information after long period of development in isolation. One of the healthy ways to achieve integral architecture is refactoring. As more features are added to the original code base, it becomes harder to add further improvements. Refactoring is about keeping simplicity, clarity, and a minimum number of features in the code. Repetitions in the code are signs of bad code designs and should be avoided. The complete and automated building process should be accompanied by a complete and automated suite of developer and customer tests. This should have the same versioning, synchronization and semantics as the current state of the System. In the end, the integrity should be verified with thorough testing, thus ensuring the System does what the customer expects it to. Automated tests are also considered part of the production process. If such tests do not add value, they should be considered waste. Automated testing should not be a goal, but rather a means to an end—namely, the reduction of defects. Keys to building in quality include:

The customer needs to have an overall experience of the system. This is called perceived integrity. This includes how it is being advertised, delivered, deployed, and accessed, as well as how intuitive it is to use, what its price is, and how well it solve problems.

Conceptual integrity means the system’s separate components work well together as a whole, while maintaining balance between flexibility, maintainability, efficiency and responsiveness.

Refactoring is about keeping simplicity, clarity, and minimum amounts of features in the code.

Integrity is verified through testing to ensure that the system does what the customer expects.



Page 114

Slide 111

See the Whole — Software systems nowadays are not simply the sum of their parts, but also the product of their interactions. Defects in software tend to accumulate during the development process. By dividing the big tasks into smaller tasks and by standardizing different stages of development, the root causes of defects should be found and eliminated. The larger the system is, the more organizations that are involved in its development, and the more parts that are developed by different teams, the greater the importance of having well-defined relationships between different vendors. This makes it possible to produce a system with smoothly interacting components. During a longer period of development, a stronger subcontractor network is far more beneficial than short-term profit optimizing—which does not enable win-win relationships. Lean thinking has to be well understood by all members of a project before it is implemented in a concrete, real-life situation. “Think big, act small, fail fast; learn rapidly” These slogans summarize the importance of understanding the field and the suitability of implementing lean principles along the entire software development process. Only when all of the lean principles are implemented together and are combined with strong “common sense” with respect to the working environment, is there a basis for success in software development. There are three keys to seeing the whole:

Defects accumulate during the development process. By decomposing big tasks into smaller ones and standardizing the

stages of development, defect root causes can be found and eliminated. Think big, act small, fail fast, learn rapidly.

The Poppendiecks describe a number of Lean Software Practices they call tools that vary slightly from their equivalents in Agile Software Development. These tools include the following:

Seeing Waste — Muda is a Japanese word meaning “futility; uselessness; idleness; superfluity; waste; wastage; wastefulness,” and is a key concept in the Toyota Production System (TPS) as one of the three types of deviation from optimal allocation of resources (muda, mura, muri). Waste reduction is an effective way to increase profitability. Toyota adopted these three words beginning with the prefix mu, which in Japan are widely recognized as a reference to a product improvement program or campaign. A process adds value by producing goods or providing a service that a customer will pay for. A process consumes resources and creates waste when more resources are consumed than are necessary to produce the goods or to provide the service that the customer actually wants. The attitudes and tools of the TPS heighten awareness and give a new perspectives on identifying waste and therefore identifying the unexploited opportunities associated with reducing waste.

Value Stream Mapping — Value stream mapping is a lean-management method for analyzing the current state of a project and designing a future state for the series of events that take a product or service from its beginning stage to the time it is in the customer’s hands. At Toyota, it is known as “material and information flow mapping.” It can be applied to nearly any value chain.



Page 115

Set Based Development — Sometimes called set based concurrent engineering (SBCE), Set Based Design is a powerful lean engineering method. Set based design builds on concurrent engineering principles (multifunctional, co-located team design) by establishing a design space for design optimization to meet a challenging set of requirements. Set based design involves exploring many design alternatives up-front to allow for trade-offs that are particularly important for integrated systems with competing requirements. Set based design improves on ‘point design’ with its many shortfalls, such as fixation on first design selected, time delay before feedback, and locked-in costs too early in the design process. The differences between point design and set based design can be best understood visually. A key principle underlying set based design involves delaying design decision later in the design process in order to achieve optimal trade-offs by eliminating inferior or sub-optimal design alternatives. Although it may seem counter intuitive, while the design decisions are delayed set based design involves front end loading the design stages of the project to develop the design alternatives. The front end loading facilitates early learning, early identification of risks, and early mitigation of risks. A key success factor is having the discipline to identify all possible design alternatives up-front without allowing the design to move on with a favorite alternative. Creativity, innovation, and practicality underpin this step.

Pull Systems — Pull systems are an integral part of lean manufacturing, yet they are frequently misunderstood and are often considered to be hard to implement. One area of repeated struggle that I find is the proper connection of assembly processes with upstream batch processes, such as stamping, injection molding, paint, or a machining operation. There are three basic types of pull systems: replenishment pull, sequential pull, and mixed pull systems that have elements of the previous two combined.

Queueing Theory — Queueing theory is the mathematical study of waiting lines, or queues. In queueing theory, a model is constructed so that queue lengths and waiting time can be predicted. Queueing theory is generally considered a branch of operations research, because the results are often used when making business decisions about the resources needed to provide a service. Queueing theory has its origins in research done by Agner Krarup Erlang, who created models to describe the Copenhagen telephone exchange. The ideas have since seen applications in many areas including telecommunication, traffic engineering, computing and the design of factories, shops, offices and hospitals.

Motivation — Motivation is literally the desire to do things. It's the difference between waking up before dawn to pound the pavement and lazing around the house all day. It's the crucial element in setting and attaining goals. Research shows that you can influence your own levels of motivation and self-control. You simply have to figure out what you want, power through the pain period, and start being who you want to be. Motivation is a theoretical construct used to explain behavior. It represents the reasons for people's actions, desires, and needs. Motivation can also be defined as a person’s direction to behavior, or what causes a person to want to repeat a behavior.



Page 116

Slide 112

Slide 113-116

Measurement — Measurement is the assignment of a number to a characteristic of an object or event, which can then be compared with other objects or events.

The Poppendiecks created a unique model of waste know by the acronym TIMWOOD. It represents seven fundamental types of waste including:

Transportation – Each time a product is moved it stands the risk of being damaged, lost, or delayed.

Inventory – Raw materials, WIP, or finished goods represent capital outlays that have not yet produced an income.

Motion – Refers to the damage that the production process inflicts on the entity that creates the product.

Waiting – Whenever goods are not in transport or are not being processed, they are waiting.

Over-Processing – Occurs any time more work is done on a piece than is required by the customer.

Over-Production – Occurs when more product is produced than is required at a time by the customer.

Defects – Whenever they occur, extra costs are incurred in reworking the part, rescheduling production, etc.

Kanban The next methodology is Kanban. Kanban is a scheduling system for lean and just-in-time (JIT) production. It is also a system used to control the logistical chain from a production point of view, and is an inventory control system. The term Kanban literally means signboard or billboard in Japanese. One of the main benefits of Kanban is to establish an upper limit to the work in progress or WIP. Typically, Kanban is used in conjunction with other methods such as Scrum. It works by limiting the maximum stories in any one particular state or column of the team or Scrum Board at a time. Typically, Kanban uses a series of columns showing the value being added to work flowing from left to right. One key indicator of the success of traditional production scheduling is based on demand or what is called pushing. Pushing is the ability of the demand-forecast to produce work and push it to the next stage. Pushing often operates seemingly in ignorance of the other columns of the Team Board. Team members work to complete tasks as quickly as possible to move on to the next task. Eventually, bottlenecks appear as work piles up in some state (like QA or testing) where fewer resources are assigned.

Kanban, by contrast, is part of an approach where the "pull" comes from demand. Re-supply or production is determined according to the actual demand of the customer. In contexts where supply time is lengthy and demand is difficult to forecast, the best one can do is often to respond quickly to observed demand. This situation is exactly what a Kanban system accomplishes, in that it is used as a demand signal that immediately travels through the supply chain. This ensures that



Page 117

Slide 117

the intermediate stock held in the supply chain is better managed and is usually smaller. When the supply response is not quick enough to meet the actual demand fluctuations, thereby causing potential lost sales, stock building may be deemed more appropriate and is achieved by placing more Kanban in the system. Taiichi Ohno stated that, to be effective, Kanban must follow strict rules of use. Toyota, for example, has six simple rules. Close monitoring of these rules is a never-ending task, thereby ensuring that the Kanban does what is required. These rules include:

Later process picks up the number of items indicated by the Kanban at the earlier process.

Earlier process produces items in the quantity and sequence indicated by the Kanban.

No items are made or transported without a Kanban. Always attach a Kanban to the goods. Defective products are not sent on to the subsequent process. The result is

100% defect-free goods. Reducing the number of Kanban increases the sensitivity.

How does this look any different when implemented in Scrum? First, the Team Board has numerical values assigned to each column that appear in the title. These tell the team the maximum number of items that can be present in that column at any time. These values block additional work from being added when the maximum is achieved. Team members are then required to work together to reduce the count in these columns so more work can be added. The affect is to push work more quickly through the entire system, rather than just one stage.

When using Kanban for Agile Development, there are several rules that must be applied. These include:

Visualize the Workflow – Have some way to visualize the workflow. In Scrum, this is the Team or Scrum Board.

Limit WIP – Keep the amount of WIP low. Successful Agile Teams know it is about getting work completely through the process and not just one stage. The counts used for each column must balance the management of WIP and must keep all resources on the team busy.

Manage Flow – Track the flow through the system. In a Scrum project this is done using the Scrum or Team Board and the Daily Scrum meeting. It is where the Development Team talks about how they are progressing and discusses potential blockers.

Make Process Policies Explicit — What are the rules the Team must follow as they complete work? These rules must be explicitly, clearly, and concisely stated to prevent confusion.

Improve Collaboratively — The process is never perfect or complete. The Team must constantly work to improve the processes used. Agile



Page 118

Slide 118

Development makes this a core part of the practice by using regular intervals to examine the process and make necessary improvements.

Many organizations have so ingrained Kanban into their process that they cannot differentiate the basic methodology from Kanban. This is especially true for teams using Scrum. To help improve your understanding, let’s make some distinctions between Scrum and Kanban. As we go through these remember, we are comparing basic, by-the-book Scrum to Kanban.

Scrum uses a Team or Scrum Board to manage its Sprints. This Board is cleared and completely reset at the beginning of each Sprint when the Team takes a new set of User Stories from the Product Backlog. Kanban also uses a Team Board that is broken into columns representing the stages of work. However, Kanban does NOT use Sprints or Iterations. It uses a continuous flow of work with new work constantly being added when there is capacity.

The Scrum or Team Board typically has a number of columns. In the To-Dos column is work that needs to be started. In the Progress column is work currently being completed by the team. In the Validate column is work that is being tested or is undergoing quality assurance. In the Impeded column is work that is currently being blocked in some way. And lastly, in the Done column is work that is fully

completed and tested. Kanban Boards typically have more columns. Remember, a Kanban Board is NOT representing the work for a single iteration. It is representing the work for the entire project. Because of this, they add a far left column for the Backlog. Additional columns are then added for the planning stage of work. Kanban references a linear process model where work is analyzed, designed, built, tested and deployed. Scrum does not.

The final difference is that the Scrum Boards tend to change infrequently. Once the Development Team builds the Board, they do not typically add or delete columns. The tool is so simplistic that doing so seldom makes sense. Kanban Boards DO change frequently. A Kanban Board is supposed to reflect the process being used. As the process evolves and changes, the Board must change with it.



Page 119

Slide 120

In the real world, there is often little difference between these two as many teams start with a simple Scrum or Team Board and then evolve into using Kanban. This leads to them not really doing Scrum “by the book” any longer. As you study for the exam make sure you can distinguish between Scrum and Kanban, because the textbook differences might be very different from what your organization is currently doing.

To learn more about Kanban, the best resource is Kanban – Successful Evolutionary Change for Your Technology Business by David J. Andersson.

Test Your Assumptions So which Agile Methodology is best, or simply the right one for you? Scrum is the most popular throughout the United States. In the UK and in many parts of Europe it is DSDM. Famed Agilist Mike Cohn argues that many Agile Teams start out using Scrum and evolve into using Extreme Programming. So how do you know? For the PMI-ACP Exam this question doesn’t really matter. Most of the questions focus on either Scrum or Extreme Programming with a smattering of the others thrown in for good measure. However, in the real world, true professionals know several of these and can make sound decisions about which is best for a given situation. To help you with these scenarios here is some general guidance:

Scrum often represents the best starting point for those new to Agile Development. Its rules, roles and constructs are usually the easiest to teach and execute.

XP is all about testing. If the team is already experienced with Scrum or some other Agile Methodology, and is focused on improving product quality, this is a great choice. But remember that XP is truly ruthless in its testing mantra. If the team lacks the tools or skills in this area, XP won’t give you the tools but it will quickly point out the problem.

FDD offers teams the tools needed to improve their prototyping and modeling. It provides a risk management approach that is powerful and focused in a way that is ideal for projects working on bleeding edge products. If your team has no idea how to technically solve a problem, FDD might be the way to go.

DSDM offers suitability filters for how well a process fits a project. It is often used in conjunction with Scrum or Prince2. It provides a heavier strategic focus for teams that need to ensure the product of the project aligns with the overall strategy of the organization. It also provides some competition to our next topic, SAFe. Both represent higher-level models that are designed for multi-project, strategic environments.

Crystal works on projects of different sizes and complexities. To some extent, it is all over the map. Whereas the more popular methodologies like Scrum and XP strictly limit team size, Crystal scales and provides a framework where ever larger teams can continue to operate. If you have a team that cannot be broken into smaller units and you still want to use Agile, this might be the best choice.



Page 120

Kanban is best suited for modification and adaptation. If your process is unquestionably a “work in progress” Kanban might represent an excellent alternative. More often however, Kanban represent an add-on or an improvement to a methodology such as Scrum. Almost every Scrum Team will benefit from using Kanban as part of their Scrum process.

Regardless of the methodology you choose, Alistair Cockburn offers some excellent guidance in his Shu-Ha-Ri Model. This model applies to the implementation of any methodology. Cockburn argues that to succeed the team must go through an evolutionary process. The first stage of this process is the Shu stage. In this stage, the team religiously follows the rules without variance. Inexperienced teams often struggle with this stage. They will blame the process for the team’s poor performance, yet be unable to point to exactly which part of it is causing them to underperform. They will claim that the process is too rigid or makes little sense. Therein lies the key. When the team fails to fully understand a process, they cannot control its power and they cannot determine what changes will have the greatest impact. They simply don’t understand the process and cannot connect the dots. Before the team can make changes that have positive impact they must first be able to actually follow the process completely without variance. Only then can the move on to the Ha stage.

When the team moves into the Ha stage, they fully understand the process and how one action or inaction leads to a specific outcome. Because of this understanding the team is able to consciously make decisions to change the process in subtle ways. They begin to move away from the basic rules, but for very specific reasons and with an eye toward achieving very specific outcomes. Eventually, the team members become true experts in the process. They know it inside and out. But this stage often creates a problem. The team understands the process in great detail. And they have made all the minor changes they can to improve the process. But it is still imperfect. What can they do?

It is at this point the team enters the Ri stage. The team has become true masters of the process and can unconsciously find their own path. It is at this stage that they are allowed to alter the process in any way they see fit, because the team has the expertise to understand the organization, the process, and how change impacts their efforts. The team is so well versed that they can change the process to whatever extent they deem necessary—even to the point of creating an entirely new, previously unknown process.

Regardless of the methodology you choose, it is absolutely critical that you think about how the methodology and tools align to your organization. Questions like team size and project visibility should be paramount in this analysis, since not every methodology fits every organization or every project within an organization. Don’t make the mistake of just grabbing the first or most popular thing you see. It usually doesn’t end well.



Page 121

Slide 121

Slide 122-124

Scaling Agile Our discussions so far have centered on Scrum, XP, FDD, and a few other ideas that (with the exception of DSDM) take a small scale view. These tools are focused on maximizing the output of an iteration and a single team. This largely ignores the notion of a full project, a program, or the organizational portfolio of competing projects. In fact, if you read the Scrum Guide carefully you find that Ken Schwaber is so adverse to “Project Management” as he sees it, that the word “project” only appears once. The notion of thinking about the whole project, program, or portfolio does not exist in Scrum or XP. This brings us to RAD, or Rapid Application Development. RAD preceded Agile by about a decade. However, RAD is not a parent to Agile. In fact, Schwaber responds to RAD with the same vitriol that he expresses towards traditional project management or SAFe. Both RAD and Agile were created as reactions to perceived shortcomings with traditional software development management techniques. However, they are different. RAD is a prescriptive method for writing software that uses successive prototypes to elicit requirements and to refine the application. Agile, in the originally introduced form, is a philosophical position describing the difference between traditional approaches and the values that are focused on by agile practitioners. These Agile approaches are implemented in a wide range of ways.

Unfortunately, individual products or business problems do not exist in isolation. Sadly, many Agile implementations are derailed when the team must integrate within the greater environment. Suddenly, the demands of competing interests and limited time and/or money become compounded. SAFe or the Scaled Agile Framework, Nexus, LeSS, and Disciplined Agile Delivery or DAD are attempts to address this situation.

SAFe The authors and proponents of SAFe contend that it is used to scale Agile within large organizations. Agile thought leaders such as Ken Schwaber strongly disagree and believe that SAFe is an outshoot of RAD and that both are closely related to traditional waterfall development. Regardless of which side of this argument you find yourself, it is an important topic to understand.

Safe is different from scaling methods in that it was created and continues to be developed by a private, for-profit entity - Scaling Agile based in Boulder, Colorado. This factor means it is updated with a much higher frequency than the other scaling frameworks. As of this writing, SAFe is on version 5.0. Additionally, the current incarnation of SAFe extends well beyond the basics of project and program management to include areas such as DevOps, release management, team and technical agility, and several other concepts. However, our focus for this course will remain on the aspects tied to a project management.

Understanding SAFe begins with understanding its levels. SAFe’s first level is level I. This is the portfolio level. At the portfolio level, strategic themes are used



Page 122

Slide 124

to connect the portfolio of projects to the organizational strategic objectives. This level also requires that budgeting be completed for the entire program. Remember, programs represent groups of related projects that are managed in a coordinated way in order to obtain a shared value for the organization. In SAFe, each program is referred to as an Agile Release Train, or ART. Then, Epics are created to fund cross ART training or deliverables. SAFe makes use of Kanban at the portfolio level to represent Agile Release Trains.

At the Program level, or Level II of SAFe, ARTs are managed. Each ART is made up of between 50 and 125 people. Within each Train are groups of related project teams. Individual resources are not trapped. If they miss an Agile Release Train, they are able to catch the next one because they occur at regular intervals. In the Scaled Agile Framework the increments of a Release Train are called Program Increments or PIs. Each PI is made up of five timeboxed iterations by default. Each iteration is a two week Scrum Sprint. Four of these iterations are focused on the delivering features found on the Product Backlog, and one iteration is used for incremental planning. This single iteration allows the team to deal with unexpected issues or generate previously un-thought of creative solutions to issues. Through this process the team makes used of a session called the Inspect and Adapt Workshop which was designed to allow the entire ART to come together and improve the overall operation of the program.

A key difference between SAFe and Scrum is that SAFe requires an additional Backlog. It represents the overall program. Remember, within a Release Train it is likely that you will see multiple Scrum teams working on their individual projects that are tied to the overall program. Each of these teams has their own backlog used to track and manage the product of their project. The Program Backlog brings the separate backlogs together and can represent larger features. The Program Backlog is owned by the Product Manager. This person represents the overall business product from a non-technical perspective.

The Agile Release Train is guided by a Release Train Engineer (RTE) who acts as the program manager. Additionally, the various teams are supported by a Train System Architect who facilitates the process of developing infrastructure for future program increments. Imagine three, four, or five Scrum Teams who each have a backlog with four, two week iterations defined. As these teams work on their backlog there is an additional, very senior technical resource who works ahead of these teams so that when it is time for the next ART, the architecture and Program Backlog is defined and ready for the team to begin work. At this time any new resources can jump on the new release train and the process begins again.

The best way to understand SAFe is to imagine that your organization has four or five Scrum teams that are all tasked with completing different components or pieces of the same project. Ask yourself how those teams would share information and ensure that the output from their sprints would work together. Also think about who would own all the integration aspects from the different teams. This includes the integration testing as well as any code that must be written to make the combined components work.

To solve these problems SAFe focuses on four core values.



Page 123

Slide 126

Slide 127-129

Slide 128

Alignment — Communicate the mission by establishing and expressing the strategy and vision. Provide relevant briefings and participate in Program Increment (PI) planning and backlog review and preparation.

Build-In Quality — Demonstrate commitment to quality by refusing to accept or ship low quality work. Support investments in capacity planning to maintain and reduce technical debt.

Transparency — Visualize all relevant work. Take ownership and responsibility for errors and mistakes. Admit missteps and support others who acknowledge and learn from theirs. Never punish the messenger; instead, celebrate learning.

Code Quality — Many leaders participate specifically as Business Owners in prioritization, PI execution, and reflection. All leaders help adjust scope to assure demand matches capacity. They aggressively remove impediments and demotivators.

SAFe also focuses on what it describes as the seven competencies of a lean enterprise. These concepts extend beyond the arena of project management and are critical to successfully implementing SAFe. They include:

Lean agile leadership — Advancing and applying Lean-Agile leadership skills that drive and sustain organizational change by empowering individuals and teams to reach their highest potential

Team and technical agility – Driving team Agile behaviors as well as sound technical practices including Built-in Quality, Behavior-Driven Development (BDD), Agile testing, Test-Driven Development (TDD), and more.

Agile product delivery – Building high-performing teams-of-teams that use design thinking and customer-centricity to provide a continuous flow of valuable products using DevOps, the Continuous Delivery Pipeline, and Release on Demand.

Enterprise Solution Delivery – Building and sustaining the world’s largest software applications, networks, and cyber-physical solutions.

Lean portfolio management – Executing portfolio vision and strategy formulation, chartering portfolios, creating the Vision, Lean budgets and Guardrails, as well as portfolio prioritization, and roadmapping.

Organizational Agility – Aligning strategy and execution by applying Lean and systems thinking approaches to strategy and investment funding, Agile portfolio operations, and governance.

Continuous Learning Culture – Continually increasing knowledge, competence, and performance by becoming a learning organization committed to relentless improvement and innovation.

SAFe works off of a model referred to as the SAFe House of Lean which is designed to maximize the delivery of business value by focusing on four core



Page 124

Slide 130

Slide 132

Slide133-136

pillars that are supported by the clear underpinnings of agile leadership. These four pillars include:

Respect for people and culture

Flow

Innovation

Relentless improvement

SAFe also provides a specific transition and implementation model as the organization makes the move from a predictive model such as waterfall to SAFe. The ACP® Exam will not go into this level of detail so we largely ignore this information within this course. The exam might however ask questions about the SAFe Solution Roadmap which represents a layered approach to the long-term implementation of the overall solution.

This roadmap begins at the highest level with the solution roadmap where the team outlines the long-term vision of the to-be-created product. This includes the various program increments that are required to develop the product and then deploy it. Beneath this level are the individual PIs or Program Increments. The current program increment has the most detail while future increments contain less. Each PI is made up of five sprints or iterations. Each of these iterations has their own iteration plan. Finally, at the lowest level is the daily plan for what the team plans on completing on that individual day. This daily plan considers the various tasks the team must complete and how these tasks impact each other.

SAFe also provides a number of configurations. It is not necessary that you know these for the exam. This information is simply given to provide you with context.

Essential SAFe is the basic building block for all other SAFe configurations and is the simplest starting point for implementation. It brings the core competencies of Lean-Agile Leadership, Team and Technical Agility, and DevOps and Release on Demand to the enterprise.

Large Solution SAFe brings the Business Solutions and Lean Systems Engineering competency to those building the largest and most complex solutions. This configuration supports multiple Agile Release Trains (ARTs) and suppliers.



Page 125

Portfolio SAFe applies the Lean Portfolio Management competency to align portfolio execution to the enterprise strategy, and organizes development around the flow of value through one or more value streams.

Full SAFe is the most comprehensive version that integrates all five core competencies to support enterprises that build and maintain a portfolio of large, integrated solutions.

Each Program Increment begins with a Release Planning Meeting that includes all the individual project teams coming together. This is a face-to-face meeting with a standardized agenda that includes a presentation of the vision and team planning breakouts, and that requires each team to commit to both the program increment and the release objectives for the next PI timebox. This meeting is facilitated by the Release Train Engineer (RTE), and usually takes between one and a half to two days to complete. SAFe argues that Release Planning provides a number of critical benefits which include:

Face-to-face planning enables high bandwidth communication. Face-to-face communication is the most effective form of communication. It allows for a continuous exchange between the parties.

It helps build the social network that the ART depends upon. Many organizations struggle due to size. The larger the organization, the more people feel disconnected and isolated. Additionally, larger projects often struggle because of teammates missing key pieces of information.

It aligns the development team to the business team via Team and Program objectives and interaction with business owners.

It identifies dependencies and fosters cross-team and cross-program coordination.

It provides the opportunity for “Just the right amount” of architecture and UX guidance.

It matches demand to capacity and eliminates excess WIP.

SAFe is governed by nine principles that build on Lean, Systems Thinking, and Agile Development. In many respects these can be thought of as extension of the 12 Principles found in the Agile Manifesto. They include:

Take a Systems View – This is a fancy way of saying take a long view, or focus on the entire system and not just the area for which an individual team is responsible.

Understand the economics of the value chain – The idea expressed here is that resources must understand the basics of how the organization delivers value.



Page 126

Slide 139

Develop systems iteratively and incrementally – This is at the heart of all Agile development. It means develop small pieces of functionality, deliver it, then develop some more. At each iteration take time to evaluate and improve your processes.

Integrate and test frequently; adapt immediately – Teams must constantly test their work product and then integrate it into the greater whole. As they go the team will find mistakes and learn. They must immediately make changes to take into account this learning.

Manage risk, efficacy and predictability with a fast, synchronous learning cycle – This principle is all about the iterations and cycles used in methodologies like Scrum.

Limit work in process. Reduce batch sizes. Manage queue lengths – This principle takes us back to the Agile discussions of WIP. It represents a simple confirmation of this foundational principle.

Synchronize with cross-domain planning and collaboration – Successful programs require a higher level of planning than an individual project. Consider three to five Scrum teams each operating independently but delivering parts of a shared large project. To succeed, the various skills must talk to each other regularly.

Base milestones on objective evaluations of working systems – Just like all Agile concepts, this is about delivering working software.

Decentralize decision-making – The old Agile rule says you must take “IT” to the team. This means project leaders are no longer empowered to make key decisions on their own. The best decisions are made when the people who have to do the work are empowered to make the key decisions about what they must do.

Nexus Nexus is a scaling framework created and maintained by Ken Schwaber and scrum.org. This means it also is a scaling method tied to Scrum. The name “Nexus” is not an acronym. It is a term that has multiple meanings to practitioners of Scrum.

Nexus is a unit of development in Scaled Professional Scrum. Nexus is a framework consisting of roles, events, artifacts, and rules that bind

and weave together the work of approximately three to nine Scrum Teams working on a single Product Backlog to build and Integrated Increment that meets a goal.

Nexus is an exoskeleton that rest on top of multiple Scrum teams to create an Integrated Increment.

The best resource for learning Nexus is the Nexus Guide found on the scrum.org website: https://www.scrum.org/resources/scaling-scrum. It argues that the major difference between Scrum and Nexus is “that more attention is paid to – –



Page 127

Slide 140

Slide 141

Slide 142

dependencies and interoperation between Scrum Teams, delivering at least one ‘Done’ Integrated Increment every Sprint.”

The diagram above shows the Nexus framework within the basic Scrum process. It shows the added steps required to take a single team managing a single project to three to nine Scrum teams managing a much larger program.

Nexus uses the same roles as Scrum including the Scrum Master, the Product Owner, and the Development Team. Each of these roles should be easily recognizable to any practitioner of Scrum as they are largely unchanged. The Product Owner is responsible for managing the Product Backlog so the organization receives maximum value from each integrated increment. The Scrum Master has overall responsibility for ensuring the Nexus framework is understood and enacted. The Development Team does the work of the project as in a normal project. To these roles Nexus adds a new role called the Nexus Integration Team. This role includes the Product Owner of the large project, a single Scrum Master, and several Nexus Integration Team members. These team members are supposed to be skilled in the use of tools, practices and systems engineering. Their primary function is ensuring the project’s Scrum Teams understand and implement the practices and tools needed to detect dependencies, and frequently integrate all the artifacts to the Definition of Done. The Nexus Integration Team also provides coaching to the Scrum teams.

Nexus makes use of the same basic artifacts as Scrum. This includes the Product Vision, Product Backlog, and Teamboard. When using Nexus, the team makes use of a single Product Backlog for all Scrum Teams. This allows all the teams to have a consistent and transparent vision of the project. Nexus projects also make use of a series of what are called Nexus Events. These events are similar in nature to those found in Scrum, but provide scaling for the multi-team environment.

The first event is refining the Product Backlog. This is the process of decomposing the Product Backlog so that dependencies are first identified then



Page 128

Slide 143

Slide 144

Slide 145

either removed or minimized. This process also requires the team to refine the User Stories until they are small enough to be completed in a single sprint and defined well enough that the team can understand the tasks required to complete the Story. The step is completed with all members of all teams. Remember, in Nexus there is one master backlog viewable by all the Scrum Teams. However, each team also maintains their own Backlog which is a subset of the master.

The next step is Nexus Sprint Planning. In this step, representatives from each team come together to discuss and review the refined Product Backlog. This is done to ensure the Nexus fully understands the definition of done. The representatives then select Product Backlog items that each team will complete in the upcoming Sprint. The representatives then return to their respective teams and plan their own sprints. Part of this individual team planning process includes determining Sprint Goals that align with the overarching Nexus Sprint Goal. The team can now go through their normal Sprint planning process.

The third step in a Nexus process is to complete the development work. Here, the various Scrum Teams that are part of the Nexus frequently integrate their work into a common environment so it can be fully tested. Specifically, this process allows the Nexus to complete not only the unit tests, but also the integration tests.

Each day the team conducts the Nexus Daily Scrum where appropriate representatives from each Scrum Team meet daily to identify any integration issues. These issues must then be transferred back to each Teams Daily Scrum. Scrum Teams then use their Daily Scrums to plan the day, making sure to address the raised integration issues.

At the end of each Sprint a Nexus Sprint Review is held to demonstrate the created features and receive feedback. It is important that all the Scrum teams meet with the stakeholders to ensure each Team’s increment is inspected and reviewed. The entire Nexus also conducts Nexus Sprint Retrospective where the greater team shares common challenges and discusses common changes. Each Team then holds its own Sprint Retrospective. Through this Retrospective process the Teams must agree how to visualize and track the identified actions. Additionally, the Team must examine several other issues within the Retrospective process:

Whether or not any work was left undone and why. This issue is common in Scrum as the rules state that when a team finds they are unable to complete a User Story before the end of the Sprint they are to return the story to the Product Backlog. This commonly occurs especially at the beginning of a project when the team is least accurate at forecasting story size.

Did the Nexus generate any technical debt? Remember, technical debt often originates from the integration of Stories and takes time away from the team’s ability to produce more Stories.

Were all the artifacts, particularly code, frequently and successfully integrated? This is a question that address that specifically addresses how the team brings their components together similarly to technical debt. However, here we are looking for the Scrum Teams to integrate their components on a daily basis.



Page 129

Slide 147

Slides 148

Slide 149

Was the software successfully built, tested, and deployed often enough to prevent the overwhelming accumulation of unresolved dependencies?

Once the Reviews and Retrospectives are complete the process then begins again with a new Nexus Sprint Planning Meeting.

LeSS The next agile scaling method also is tied to Scrum. This method is called LeSS or Large-scale Scrum. It was originally created by Craig Larman and Bas Vodde, and provides two different frameworks depending on the size of your project. The first of these frameworks is simply referred to as Framework 1. It is designed to handle projects that include up to ten Scrum teams. The second framework is called Framework 2, and it is for larger organizations.

Because LeSS has its foundation in Scrum there are a number of commonalities between the two. Just as we saw in Nexus, Both LeSS and Scrum use a single Product Backlog. LeSS justifies this practice by arguing the project is about creating a single product or service and NOT a single team. Because there is a single Product Backlog for all the Scrum teams using LeSS, it stands to reason that there also is only one definition of done across all teams. Also much like Nexus, LeSS requires a single potentially shippable product increment at the end of each Sprint. LeSS also makes use of a single Product Owner. As has been previously discussed, the Product Owner is responsible for decisions concerning the Product Backlog. Both Scrum and LeSS require the teams be complete and cross-functional groups without any single-specialists. Finally, both LeSS and Scrum require the entire project be on the same Sprint. When you are thinking about a project with a single Scrum Team of three to six individuals this isn’t very significant. However, when we are discussing multiple Scrum Teams all working on a single project it is possible to have different Scrum Teams on different Sprints. LeSS doesn’t allow this.

There are also a number of differences between basic Scrum and LeSS. These differences begin with Sprint Planning. In LeSS Sprint Planning is broken into two parts. In the first part, a single Product Owner is joined by people from all the different Scrum Teams. In traditional Scrum there are only six plus or minus three people and not multiple teams. LeSS adds multiple teams to the process. Therefore they each must be represented at the planning meeting. In the first part of Sprint Planning, the team members decide how they will divide the Product Backlog items. Team members also discuss opportunities to find shared work and cooperate.

The second part of Sprint Planning on a LeSS project requires each Scrum Team to act independently in their own meeting. This is a traditional Sprint Planning Meeting. However, sometimes for simple coordination and learning two or more Teams may hold it in the same room.

LeSS also makes use of the Daily Scrum. Each Scrum Team holds their own Daily Scrum, but one team is allowed to observe another’s Daily Scrum to increase information sharing.



Page 130

Slide 150

Slide 151

Slide 152

There may be an optional and short overall Product Backlog Refinement (PBR) meeting that includes the one PO and people from all teams. Purpose is to decide which teams are likely to implement which items and therefore select those items for later in-depth single-team PBR. It is also a chance to increase alignment with the Product Owner and all teams.

The only requirement in LeSS is single-team PBR, the same as in one-team Scrum. But a common and useful variation is multi-team PBR, where two or more Teams are in the same room together, to increase learning and coordination.

In addition to the one Product Owner, the Sprint Review includes people from all teams, and relevant customers/users and other stakeholders. For the phase of inspecting the product increment and new items, consider a “bazaar” or “science fair” style: a large room with multiple areas, each staffed by team members, where the items developed by teams are shown and discussed.

LeSS makes us of an Overall Retrospective is a new meeting not found in one-team Scrum, and its purpose is to explore improving the overall system, rather than focusing on one Team. The maximum duration is 45 minutes per week of Sprint. It includes the Product Owner, Scrum Masters, and rotating representatives from each Team.

Disciplined Agile Delivery Disciplined Agile Delivery or DAD is a hybrid framework that is people-first, learning oriented approach to IT solution delivery. It makes use of Scrum, Agile Modeling, Extreme Programing, UP, Kanban, Lean Software Development, Outside In Development. DAD looks at the full, end-to-end delivery lifecycle from project initiation to solution delivery and provides technical practice advice like Extreme Programing does. It also provides modeling, documentation, and governance. DAD is less prescriptive than Scrum by being more goal-driven. It also provides significant advice and alternatives.

DAD divides projects into three phases: Inception, Construction, Transition, DAD begins by taking a slightly different approach to the Product Backlog. It argues that teams often must complete non-requirement related work such as take training, review products of other teams, address defects. These need to be on the backlog. Disciplined Agile also takes a risk-value approach. Common risks include the need to come to stakeholder consensus early in the project, or the need to prove that your architecture strategy, actually works. DAD teams look at their work item stack early in the project, typically during the Inception or iteration 0 to identify requirements which exhibit these technically risky features.

Disciplined Agile also demands the Team model a bit ahead. What if a work item is very complex, requiring a bit more thinking that what generally occurs in an iteration planning session? DAD teams adopt the Look-Ahead Modeling practice and look ahead an iteration or two and invest the time to explore complex upcoming items to reduce the overall project risk. Modeling a bit ahead is called backlog grooming in Scrum.

Perhaps the biggest difference between Disciplined Agile and the other scaling



Page 131

Slide 156

Slide 157

techniques we have discussed is found in the fact that DAD has several different lifecycle versions. These include:

Agile/Basic – Based on Scrum, but extended to provide a streamlined strategy from beginning to end.

Lean/Advanced – Based on Kanban. Continuous Delivery – Stable team based on Kanban and Lean. Exploratory/Lean Startup – Base on Lean Startup strategies The Disciplined Agile Delivery website describes two groups of roles with a significant larger number of them than frameworks such as Scrum. These groups include primary and secondary roles. Within the these groups we find the following roles:

Primary Roles

Stakeholder. A stakeholder is someone who is materially impacted by the outcome of the solution. In this regard, the stakeholder is clearly more than an end-user: A stakeholder could be a direct user, indirect user, manager of users, senior manager, operations staff member, the “gold owner” who funds the project, support (help desk) staff member, auditors, your program/portfolio manager, developers working on other systems that integrate or interact with the one under development, maintenance professionals potentially affected by the development and/or deployment of a software project. DAD teams will ideally work together with their stakeholders daily throughout the project.

Team Member. The role of team member focuses on producing the actual solution for stakeholders. Team members will perform testing, analysis, architecture, design, programming, planning, estimation, and many more activities as appropriate throughout the project. Note that not every team member will have every single one of these skills, at least not yet, but they will have a subset of them and they will strive to gain more skills over time. Team members are sometimes described by core agile methods as “developers” or simply as programmers. However, in DAD we recognize that not every team member necessarily writes code. Team members will identify tasks, estimate tasks, “sign-up” for tasks, perform the tasks, and track their status towards completion.

Team Lead. On agile projects the role of the traditional project manager changes substantially, and in fact the term project manager is now unfortunately frowned upon. The agile community has focused on project or team leadership over team management, observing that the best “managers” prioritize leadership over technical management issues such as planning and estimation. An important aspect of self-organizing teams is that the team lead facilitates or guides the team in performing technical management activities instead of taking on these responsibilities him or herself. The team lead is a servant-leader to the team, creating and maintaining the conditions that allow the team to be successful. The team lead is also an agile coach, helping to keep the team focused on delivering work items and fulfilling their iteration goals



Page 132

and commitments that they have made to the product owner. He or she acts as a true leader, facilitating communication, empowering them to self-optimize their processes, ensuring that the team has the resources that it needs, and removes any impediments to the team (issue resolution) in a timely manner. When teams are self organizing, effective leadership is crucial to your success.

Product Owner. In a system with hundreds or thousands of requirements it is often difficult to get answers to questions regarding the requirements. The product owner is the one individual on the team who speaks as the “one voice of the customer”. He or she represents the needs and desires of the stakeholder community to the agile delivery team. As such, he or she clarifies any details regarding the solution and is also responsible for maintaining a prioritized list of work items that the team will implement to deliver the solution. While the product owner may not be able to answer all questions, it is their responsibility to track down the answer in a timely manner so that the team can stay focused on their tasks. Having a product owner working closely with the team to answer any question about work items as they are being implemented substantially reduces the need for requirements, testing, and design documentation. You will of course still have need for deliverable documentation such as operations manuals, support manuals, and user guides to name a few. Each DAD team, or subteam in the case of large programmes organized into a team of teams, has a single product owner. A secondary goal for a product owner is to represent the work of the agile team to the stakeholder community. This includes arranging demonstrations of the solution as it evolves and communicating project status to key stakeholders.

Architecture Owner. Architecture is a key source of project risk and someone needs to be responsible for ensuring the team mitigates this risk. As a result the DAD framework explicitly includes Agile Modeling’s role of architecture owner. The architecture owner is the person who owns the architecture decisions for the team and who facilitates the creation and evolution of the overall solution design. The person in the role of team lead will often also be in the role of architecture owner on small teams. This isn’t always the case, particularly at scale, but it is very common for smaller agile teams. Although the architecture owner is typically the senior developer on the team – and sometimes may be known as the technical architect, software architect, or solution architect – it should be noted that this is not a hierarchical position into which other team members report. He or she is just like any other team member and is expected to sign-up and deliver work related to tasks like any other team member. Architecture owners should have a technical background and a solid understanding of the business domain.

Secondary Roles

Specialist. Although most agile team members are generalizing specialists, sometimes, particularly at scale, specialists are required. For example, on large teams or in complex domains one or more agile business analysts may join the team to help you to explore the requirements for what you’re building. On very large teams a program manager may be required to coordinate the team leads



Page 133

on various sub-teams. You will also see specialists on DAD teams when generalizing specialists aren’t available – when your organization is new to agile it may be staffed primarily with specialists who haven’t yet made the transition to generalizing specialists.

Domain Expert. The product owner represents a wide range of stakeholders, not just end users, so it isn’t reasonable to expect them to be experts in every nuance in your domain, something that is particularly true with complex domains. The product owner will sometimes bring in domain experts to work with the team, for example, a tax expert to explain the details of a requirement or the sponsoring executive to explain the vision for the project.

Technical Expert. Sometimes the team needs the help of technical experts, such as a build master to set up their build scripts, an agile database administrator to help design and test their database, a user experience (UX) expert to help design a usable interface, or a security expert to provide advice around writing a secure system. Technical experts are brought in on an as-needed, temporary basis to help the team overcome a difficult problem and to transfer their skills to one or more developers on the team. Technical experts are often working on other teams that are responsible for enterprise-level technical concerns or are simply specialists on loan to your team from other delivery teams.

Independent Tester. Although the majority of the testing is done by the people on the DAD team themselves, some DAD teams are supported by an independent test team working in parallel that validates their work throughout the lifecycle. This independent test team is typically needed for agility at scale situations within complex domains, using complex technology, or addressing regulatory compliance issues.

Integrator. For large DAD teams which have been organized into a team of sub-teams, the sub-teams are typically responsible for one or more subsystems or features. The larger the overall team, generally the larger and more complicated the system being built. In these situations, the overall team may require one or more people in the role of integrator responsible for building the entire system from its various subsystems. On smaller teams or in simpler situations the Architecture Owner is typically responsible for ensuing integration, a responsibility that is picked up by the integrator(s) for more complex environments. Integrators often work closely with the independent test team, if there is one, to perform system integration testing regularly throughout the project. This integrator role is typically only needed at scale for complex technical solutions.

On a DAD project, any given person will be in one or more roles, an individual can change their role(s) over time, and any given role will have zero or more people performing it at any given time. For example, Peter may be in the role of team member and architecture owner right now but step into the role of team lead next month when Carol, the existing team lead, goes on vacation.



Page 134

Slide 161

Slide 162

Roles are not positions, nor are they meant to be. For example, Jane may be in the role of stakeholder for your project but have the position of Chief Financial Officer (CFO) within your organization. In fact, although there may be hundreds of stakeholders of your project none of them is likely to have a position of “stakeholder.”

Agile deemphasizes specialized roles and considers all team members equal – everyone pitches in to deliver a working solution regardless of their job description. An implication of this is that with the exception of stakeholder everyone is effectively in the role of team member.

Traditional roles, such as business analyst or project manager, do not appear in DAD. The goals which people in traditional roles try to achieve, for example in the case of a business analyst to understand and communicate the stakeholder needs/intent for the solution, are still addressed in DAD but in different ways by different roles. There isn’t a perfect one-to-one match between any given traditional role and a DAD role, but as you will find in the Disciplined Agile Delivery book there are reasonable transition strategies. The critical thing for traditionalists to understand is that because the underlying paradigm and strategy has changed, they too must change to reflect the DAD approach.

Scrum of Scrums A technique to scale Scrum up to large groups (over a dozen people), consisting of dividing the groups into Agile teams of 5-10. Each daily scrum within a sub-team ends by designating one member as "ambassador" to participate in a daily meeting with ambassadors from other teams, called the Scrum of Scrums.

Depending on the context, ambassadors may be technical contributors, or each team's Scrum Master, or even managers of each team.

The Scrum of Scrums proceeds otherwise as a normal daily meeting, with ambassadors reporting completions, next steps and impediments on behalf of the teams they represent. Resolution of impediments is expected to focus on the challenges of coordination between the teams; solutions may entail agreeing to interfaces between teams, negotiating responsibility boundaries, etc.

The Scrum of Scrum will track these items via a backlog of its own, where each item contributes to improving between-team coordination. Some authors refer to Scrum of Scrums as Meta Scrum.

The PMO A PMO is a department within the organization that centralizes the management of projects. PMI® describes three types of PMOs that each have varying degrees of control and influence over the project. These include:

Supportive — These PMOs act as a consultative role. Their primary function is to provide things like templates, best practices, training, access to pertinent information, and most importantly lessons learned from previous projects. You should think of this type of PMO as a repository. This type PMO has very little power or control over the projects in the organization.



Page 135

Slide 163

Controlling — Controlling PMOs do NOT directly manage projects. However, this type of PMO mandates compliance to varying degrees. The PMO maintains this control by establishing project management frameworks and methodologies that must be adopted. It also requires the use of specific templates, forms, and tools.

Directive — Directive PMOs take the most direct and overt control of projects. Directive PMOs include the organization’s project managers who are assigned by and report to the PMO. In this form of a PMO a high degree of control is maintained.

When discussing a PMO realize that they can have oversight over the entire organization or a single area.

Remember, a PMO is not a person, but an organization or department. Most of this manual is focused on describing the role of the project manager, but the PMO is different. Here are some of the ways the PMO is different:

PMOs often have the power to terminate projects.

PMOs often have the power to provide resources to projects.

PMOs often manage the interdependencies between projects.

PMOs often monitor an individual projects’ compliance with organizational policies.

PMOs provide project management for the various projects within the organization and are responsible for the results of those projects.

PMOs provide tools, techniques, policies, methodologies, and templates for the organization to manage various projects.

PMOs provide guidance and support to the organization on how to manage projects. This includes providing training for the project managers on the processes and tools of project management.

PMOs often gather lessons learned and share the information throughout the organization.

PMOs often provide centralized communication about projects.

PMOs are often more heavily involved early in the project.

What is the Perfect Structure?

It’s time to get down to business and start learning the concepts of project management that you will need to pass the exam. We will begin with some basic foundational topics. The first of these topics is how to best structure your team and organization.

When considering organizational structure it is important to know that there are two forces that determine how to best group people. These forces are



Page 136

Slide 164-166 DIFFERENTIATION and INTEGRATION. According to http://Merriam-Webster.com, differentiation is the development from the one to the many, the simple to the complex, or the homogeneous to the heterogeneous. If you are like most readers you are now completely confused. Don’t be. Differentiation happens in any organization where a small group of people create a culture that is distinct from the larger group. This can be because of a shared knowledge, products, or geography. Integration is defined as the act or process or an instance of integrating: such as incorporation as equals into society or an organization of individuals of different groups. This definition is likely equally unhelpful. However, it too is a simple concept. Integration represents the force or power of bringing people together. Differentiation is a force that isolates people and groups. Integration is a force that brings them together. Together they create two forces that pull the organization in opposite directions. When discussing project management, these forces create a series of predictable organization types:

Organic or simple Functional Multi-divisional Matrix Projectized Virtual Hybrid PMO

This list represents a continuum moving from the project leader having no authority and the organization not showing any focus on the profession of project management to the project leader having significant authority and the organization seeing project management a critical business profession.

For the exam, it is important that you can determine the type of organization based upon the clues given in the question. These questions can be very easy if you just look for the key indicators:

The first clue is the title of the person serving the project management function. An expeditor or coordinator is someone with very little power. A project expeditor primarily acts as a communications coordinator and staff assistant. The project coordinator has limited power to make decisions and usually reports to a higher-level manager. A project manager has more power.

The second clue you should examine is who the project leader reports to. If they report to a functional manager it is likely the PM has little power and is therefore more of a functional organization. If the project leader reports to someone who is the leader of project managers such as in a PMO, the organization is more of a projectized organization.

The third clue to the organizational structure is how much time the various resources dedicate to each individual project. The more their time is split, the more the organization has a functional structure. The



Page 137

more the resources are dedicated to a single project, the higher the likelihood they are part of a projectized organization.

Let’s examine these organizational structures in detail.

Organic or Simple Organizations

The linear progression begins with the organic or simple structure. It is best exemplified by small, startup organizations where every member of the team has multiple roles and responsibilities. Typically, no one in the organization has a project management title. The project is often managed by the owner of the organization and there is no administrative support. From a purely project management perspective, this is the weakest organizational structure. It happens often because the organization is in its early formation stages and there is little structure for any department. Each member of the team is scrambling to cover multiple areas and any project management tools or expertise is purely happenstance. This is not necessarily a bad thing. Remember the organization is in its infancy and having a robust project management practice would be unrealistic at this point.

Functional Organizations

The next type of structure is the functional organization. A functional organization is one where the staff is organized by their job or function. Common functional departments include sales, engineering, marketing, accounting, or finance. In functional organizations, expertise — or drive for deep technical knowledge — is the dominant force. In these organizations, resources have one clear supervisor, typically referred to as the manager of the technical area. The manager then reports to the director of the area, who reports to the vice president of the area and so on. The number of layers in this hierarchy is largely driven by the size of the organization.



Page 138

Another key characteristic of a functional organization is that projects are only handled within the functional area. This is a highly localized approach to dealing with projects. Each resource and/or resource manager only cares about the project in terms of how it impacts their functional area. Little to no consideration is given to the areas of the project outside one’s individual silo. This aspect of a functional organization is usually the cause of significant criticism because it means that project stakeholders get passed from one resource to another without anyone taking general responsibility for the overall project.

Notice that the project leader is called an Expeditor or Project Coordinator. Also note that the project leader reports to one of the functional departments. Although it is difficult to tell, these two clues indicate that the project manager has almost no formal authority. They also indicate that the project leader serves more as an administrative assistant than anything else. However, a functional organization produces a number of advantages including:

Clear reporting relationships — Within a functional organization each resource knows very clearly who they report to because the organizational structure is based on vertical silos.

Highly specialized expertise — The vertical structure of functional organizations allows resources to develop deeper knowledge of the skill set that is targeted or described by the function. This can be contrasted to a non-functional organization, which requires resources to be stronger generalists.

Easier to manage — This advantage is very much an opinion. The argument is that it is easier because you only have to manage a single skill set and you manage within the framework of the vertical silo.

Homogeneous groups — Functional organizations, by definition, create homogeneous groups, where the members are alike or have similar skill sets. This advantage ties directly to making them easier to manage.

Drive for technical excellence — In a functional organization the resources in the individual silos are typically incentivized to achieve superior knowledge and performance in the technical aspects of their work.

Clear career path — When the organization is structured into functional silos the resources are presented with a well understood progression for their career. Often this means the individual starts out as a junior resource, then becomes a senior resource, then a manager or team leader, a senior manager, a director and finally the vice president of the silo.

High quality organizational knowledge — Within each individual silo the functional organizational structure makes it possible to develop deep technical knowledge because you have several resources with the same skill set all focused on being the best in that technical area.



Page 139

A functional organizational structure is not perfect. According to PMI® there are a number of disadvantages, or issues, with a functional organizational structure. These include the following:

Conflicting priorities from overlapping projects — Functional organizations often struggle to provide consistent visibility across all the silos of the organization. This can cause resources to become frustrated because they are asked to complete multiple tasks at the same time without prioritization.

Project boundaries are limited to one’s discipline — In a functional organization projects are typically only handled within the individual silo. This can create a number of problems including the development of incomplete solutions, incorrect solutions, expensive solutions, or significant post-project repairs.

Barrier to customer influence and satisfaction — Functional organizations often struggle to meet the needs of their stakeholders because they do not have a single individual who can act as a stakeholder, who has the authority to address issues, and who the team can approach with concerns. The stakeholders therefore end up having to go to each silo to deal with different issues.

Employee development opportunities are limited — In a functional organization the silo leaders are primarily focused on developing the core competencies of the silo. Skills that are perceived to be outside that silo are generally not supported.

Project Manager is dependent on personal influence — In a functional organization all (or almost all) of the organizational power is held by the functional managers. Project managers are generally perceived as administrative aids who report to functional managers. Therefore, they must rely on forms of personal influence such as being well-liked.

Hierarchical decision and communication processes — In a functional organization resources are organized into silos based upon their technical skills. Communication has to follow the chain of command up one structure and then across to the leader of another silo before filtering down to the technical resources in the other skill area.

Overwork technical issues vs. build to a standard — Because resources in a functional organization are organized according to technical skill, they often focus on building the perfect technical solution rather than simply the right solution.

Fosters part-time roles — In a functional organization resources are usually asked to serve as operational resources and work on multiple projects. As a general rule, resources only handle a project within their functional area. This often leads to resources that are less than 20% dedicated to a single project.



Page 140

If a functional organization is less than perfect, moving towards the opposite organizational structure might prove advantageous.

Projectized Organizations

The opposite extreme from the functional organization is the projectized organization. In a projectized organization the resources are organized based upon the projects to which they are assigned. Each resource is assigned to only one project and each team has all the resources the project requires for completion.

Projectized organizations present a number of key advantages. These advantages include:

Strong project manager role — It is important to remember you are studying for a certification managed by the world’s largest organization dedicated to the advancement of project management. As a general rule, things that make project managers stronger are perceived by PMI® to be good.

Full-time administrative staff with clear accountability — A key indication of a projectized organization is that the project manager is supported by a full-time administrative staff that reports directly to the project manager. This is an advantage for the project manager since it helps them achieve the desired project results.

Fosters collocation — Collocation means resources are physically located in the same facility. This is an advantage because it makes it easier to communicate with other resources and stakeholders on the project.

Improves focus —Improved focus on what? The overall project—as opposed to individual components of the project. This is a more holistic view.

Cost and performance tracking of projects — Many organizations struggle with tracking the real performance of their projects. Projectized organizations have an advantage in this area. Because the organization is structured around the various projects, it’s easier to determine the results of each team. In an organization where everyone is working on multiple projects simultaneously this is much more difficult.

Decision-making based on overall project view — The core premise of a projectized organization is that performance improves when each team member is focused on only one project. This concept extends to decision-making as well. When the entire team is focused on only a single project they are more likely to make good decisions.

Customer relationships tied to various projects — In a projectized organization the end customer is able to communicate with a single point of contact—the project manager—for all needs. This reduces the likelihood of miscommunication.



Page 141

However, projectized organizations are not perfect either. They suffers from a number of potential issues. These issues include the following:

Reduction of employees’ professional identity — Employees often associate themselves more with their level (such as senior engineer, director, or manager) rather than with the project to which they are assigned. In a functional organization this is perfectly aligned. However, in a projectized organization the focus is on the project, not one’s level, and therefore individuals can struggle to find their place.

Reduced focus on technical competence — This issue is similar to the reduction of professional identity. However, instead of the issue concerning one’s level within the organization, the primary issue is technical skill or role. This issue occurs when people view themselves according to their core skills or their roles, rather than according to the project to which they are assigned.

Leadership by the non-technically skilled — Often project managers do not come from a technical background. When the organization is projectized the position of project manager is seen as a technical expertise unto itself. Although the project manager is highly skilled in the processes, tools and techniques of project management, they do not necessarily know anything about the key fields of expertise that are required to actually execute the project. As a result, the technical resources may not always respect the project manager and therefore might treat them as administrators with little authority.

Focus on administrative work vs. technical work — A focus on the administrative work often stems from the leadership issue cited previously. Because the project leader does not come from a technical background, she might focus on the area where she feels most comfortable, which is often the administrative work of project management.

De-valuing of functional managers — In any organization there is only a limited amount of power. In a functional organization all the power resides with the functional managers at the expense of the project managers. In a projectized organization the exact opposite is true. The project managers hold the vast majority of power at the expense of the functional managers. As you can image, whoever lacks authority will feel devalued and frustrated.

Process vs. deliverable emphasis — A process versus deliverable emphasis is a fancy way of raising some of the same concerns held in the two previous bullet points. A projectized organization can struggle because it becomes too focused on the project management processes rather than the desired output.

Creates redundancy of efforts — In projectized organizations the focus is on the successful completion of the individual project. Each person is assigned to one and only one project. The result is a situation where no one is focused on evaluating the various projects against one another. In the end, the organization can end up with two “successful” projects where the only differences are minor and everyone feels the organization could have been better served if only one of the projects had been completed.



Page 142

Project end can be a traumatic event — In projectized organizations each resource is assigned to a single project. When a project ends the resources assigned to that initiative are potentially out of work. This can be a major concern for the resources and can cause a situation where projects never end, they just enter a new phase.

If both functional and projectized organizations are so significantly flawed we could be in a lot of trouble. Fortunately, most organizations attempt to find some middle ground between the two extremes. We refer to this middle ground as a matrix organization.

Matrix Organizations

Matrix organizations combine the elements of both functional and projectized organizations. The different weighting of functional and projectized characteristics allows matrix organizations to be categorized into three types: Weak, Balanced, and Strong. Often the easiest way to think of matrix structures is to imagine a linear continuum with the functional organization on the far left followed by the weak matrix, the balanced matrix, the strong matrix organization, and finally the projectized organization on the far right.

A Weak Matrix Organization

Often for the PMP® exam candidates are required to differentiate between the various types of organizations. For many, the most difficult two organizational types to tell apart are the functional and the weak matrix organizations. The differences between these two are often miniscule. In the functional organization the project manager has no authority because the functional manager has it all. In a weak matrix organization, the project manager has slightly more power—something incrementally higher than zero. In a weak matrix organization the title of the project manager is likely to be project coordinator. In a weak matrix organization the project manager will not have significant administrative support. The project resources will primarily be focused on their functional duties. The resources will also be assigned to multiple projects. The project manager in a weak matrix organization reports to a functional manager.



Page 143

A Balanced Matrix Organization The absolute middle in the linear continuum of structures is the balanced matrix organization. The balanced matrix attempts to take the best of both the functional and projectized organizational structures in equal proportions. The key way to recognize a balanced matrix organization is that the project leader is called a project manager, and everyone report to this person. In a balanced matrix organization, the project manager reports to a functional head. The balanced matrix organization is the only one where a titled project manager reports to a functional head. Balanced matrix structures pull resources from functional department and they receive a moderate amount of administrative support. However, resources are not fully dedicated to a single project.



Page 144

A Strong Matrix Organization

The last type of organization is the strong matrix. The strong matrix structure is most closely aligned to a projectized organization. This means the project manager has more power than in any other matrix structure. In a strong matrix organization the project managers are organized into a department of their own. This department is often referred to as a Project or Program Management Office or PMO. It is headed by a manager just like any of the other functional units. This fact serves to immediately elevate the power of project managers within the organization. In a strong matrix organization project management has at least an equal footing with all other functional departments. In a strong matrix organization the project manager has full time administrative support. However just as in all the other forms of matrix organizations, in a strong matrix structure the project resources are not dedicated to only one project. In many cases resources are assigned to multiple projects and also hold operational responsibility. What makes this structure unique is the fact that a single department owns process, methodology definition, and practice maintenance. It also allows for a single executive to own the entire portfolio of new initiatives within the organization.

Matrix Organization Advantages

Visible project objectives — Matrix organizations shift power from functional managers to project staff in order to increase the visibility of projects and to improve their performance.

Improved control of resources by project managers — Since project managers theoretically have more authority it stands to reason that they also have better control over project resources. This improved control happens at the expense of the authority of functional managers.

Rapid response to contingencies — If project managers have greater authority and are focused on the projects they own then they are more likely to see problems earlier in the lifecycle and therefore respond more quickly.

Greater support from functional managers — This is often the subject of debate. The theory is that because project managers have greater authority and visibility they receive greater support from the functional managers. The problem comes from the fact that the project managers have gained this authority and visibility often at the expense of those same functional managers.

Coordination of efforts across organization — As the organization gives more authority to project managers they become more effective at coordinating the various aspects of the project across the entire organization.

Remember, project managers provide a single point of focus for the project.

Project end is not a traumatic event — This advantage addresses one of the major concerns of a projectized organization. In projectized organizations the staff has no job when the project ends. This does not happen in functional organizations because the resources are part of their functional teams. Matrix



Page 145

organizations gain the advantage found in functional organizations through the hybrid model while also improving on project focus.

Strong technical base — This is another advantage shared with functional organizations. Because the functional organizations still exist in matrix structures, projects gain access to the strong technical knowledge provided by the hierarchical, skill-based functional organizations.

More effective dissemination of information — This advantage is also the subject of much debate. The theory is that because matrix organizations have both the vertical communication found in functional organizations and the horizontal communication found in projectized organizations the staff should have a lot more accurate information and should have a greater ability to quickly communicate with other project stakeholders. However, there is also a chance that all this communication will cause confusion.

Matrix organizations have a number of challenges as well.

Matrix Organization Issues

Project personnel report to more than one boss — This issue is often referred to as a “dotted line relationship.” In many cases, resources are forced to choose between conflicting instructions given to them by the project manager and the resource manager. In these situations the resource rarely wins.

Complex to monitor and control — As organizations become more complex with bidirectional leadership (both functional and project) the metrics used to monitor real performance become more complicated. As they become more complicated the probability of providing false indications of performance become greater.

Conflicts with resource allocation and project priorities — What should the resources be working on at any given moment? Functional managers often have responsibilities for operational efforts as well as project work. Their priorities are often very different from those of each project manager. This can lead to project work not getting done.

Potential for duplication of effort with “independent” projects — As the organization moves closer to the projectized structure, the tendency is to examine the team’s efforts based on the totality of the project. While this is good from a project management standpoint, it can create a blind spot by not comparing all projects. The result can be a portfolio with several similar products or services when only one was needed.

Power struggles and competition for scarce resources — In any



Page 146

organization there is competition for the limited resources available to complete work. However, in matrix organizations, that competition is heightened by the power struggle that can exist between project managers and functional managers.

Virtual / Hybrid / PMOs

At far end of this side of the continuum are the virtual, hybrid, and PMO organizations.

Virtual organizations are a new concept found in the 6th edition of the PMBOK® Guide. In a virtual organization, team members work is disparate locations and communicate through the use of advanced technology. In a virtual organization the project leader have low to moderate levels of authority. There is no typical of time put in by the project leader. Much of this is because resources work on multiple projects at the same time. Virtual organizations also have a wide range of administrative support structures.

Hybrid organizations represents a catchall group. A hybrid organization can be a mixture of all the other organizational structures. In each of the specific characteristics that describe structures a hybrid is described as mixed.

The final type of organizational structure is the PMO, and we will discuss it later in this course.

Regardless of the organizational structure, a few simple clues can help you answer likely exam questions quickly. Review the table below to ensure that you have a firm grasp on these keys. On the exam you are likely to experience a number of questions where the organizational type is not defined. When this happens, assume it is a matrix organization.



Page 147

Slide 166



Page 148

Exercise 4 -Agile Principle & Mindset Pt. II

Agile Principles & Mindset Part II Exam

1. The visualization for the DSDM lifecycle is sometimes referred to as the ___________?

A. Agile Triangle B. Cheese and Pizza Diagram C. The Agile DSDM Pyramid D. The Meat and Cheese Diagram

2. Which of the following is NOT a common objective of the feasibility phase found in DSDM?

A. To identify information used, created and updated by the proposed solution. B. To describe the organization and governance aspects of the project. C. To state first-cut estimates of timescale and costs for the project overall. D. To plan and resource the Foundations phase.

3. Which of the following is NOT a potential outcomes in DSDM from deployment?

A. All requirements have been satisfied. Hence, no further work is currently needed. B. Completion of state first-cut estimates of timescale and costs for the overall project. C. Features that were already planned for the next increment are now to be added, so the

process returns to exploration. D. The next increment will solely address areas of technical concern, so the process

returns to engineering.

4. Which of the following is NOT a prerequisite required for using the Dynamic Systems Development Method?

A. Acceptance of the Atern philosophy before starting work. B. Appropriate empowerment of the Solution Development Team. C. Commitment of senior business management to provide the necessary Business

Ambassador involvement. D. Access by the Business Team to the Solutions Development Team.

5. Within DSDM, which of the following roles is responsible for the business case?

A. Business Sponsor B. Business Visionary C. Project Manager D. Team Leader

6. Which DSDM role provides the business perspective for all decisions related to the way the solution’s fitness for business purpose is defined and implemented?

A. Business Sponsor B. Business Visionary C. Business Ambassador D. Team Leader

7. Who within a DSDM team is responsible for interpreting the needs of the Business Sponsor, communicating those to the team and, where appropriate, ensures they are properly represented in the business case?

A. The Business Sponsor B. The Business Visionary C. The Project Manager D. The Technical Coordinator



Page 149

8. Which of the following DSDM role works closely with the rest of the Solution Development Team, guides the evolution of the solution, bringing other users’ input and ideas to the project as required. This role is responsible for the day-to-day communication channels between the project and the business.

A. Business Sponsor B. Business Visionary C. Business Ambassador D. Team Leader

9. Which of the following is NOT one of the eight principles of DSDM?

A. Focus on the business need. B. Deliver on time. C. Build incrementally from firm foundations. D. Communicate vigorously and assume positive intent.

10. Your team is using DSDM and is using modeling and iterative development. The team is currently working out what needs to be done by whom to meet the current objective. In what stage of the iterative cycle is the team currently?

A. Identify B. Plan C. Evolve D. Review

11. Your team is using MoSCoW Prioritization to evaluate project requirements. Which of the following represents the W in MoSCoW?

A. Will have B. Want to have C. Won't have this time D. None of these apply as MoSCoW is not an acronym.

12. Within the DSDM model, which of the following stages accounts for the largest amount of time?

A. Investigation B. Refinement C. Consolidation D. Kick-off

13. Which of the following is not a core area of focus for Crystal?

A. Processes B. People C. Interaction D. Talents

14. Within Crystal, which color is used for teams of 7 to 20 people?

A. Crystal Clear B. Crystal Yellow C. Crystal Orange D. Crystal Maroon



Page 150

15. Which of the following is NOT a common practice or property found in Crystal?

A. Personal safety B. Reflective improvement C. Incremental delivery D. Close or Osmotic Communication

16. Which of the following is NOT a core principle that provides the foundation of Lean Software Development?

A. Eliminate waste B. Amplify learning C. Decide as late as possible D. Deliver as often as possible

17. Each of the following are keys to seeing the whole EXCEPT:

A. Defects accumulate during the development process. B. By decomposing big tasks into smaller ones and standardizing the stages of

development defect root causes can be found and eliminated. C. Be fair but decide quickly. D. Think big, act small, fail fast, learn rapidly.

18. Which of the following is one of the three types of deviation from optimal allocation of resources according to the Toyota Production System or TPS?

A. Mumu B. Muda C. Muki D. Moori

19. Which of the following teams is a lean-manufacturing method for analyzing the current state and designing a future state for the series of events that take a product or service from its beginning through to the customer?

A. Value stream mapping B. Product flow mapping C. Integration and value mapping D. State and design mapping

20. Which of the following is NOT a tool or Lean software practice emphasized by the Poppendiecks?

A. Seeing waste B. Value stream mapping C. Set based development D. Constraints management theory

21. According to the Poppendiecks' model, there are seven fundamental types of waste that includes each of the following EXCEPT:

A. Transportation B. Motion C. Missed production D. Over processing



Page 151

22. Which of the following statements concerning Kanban is NOT true?

A. Using Kanban does not require immediate changes to the team board. B. Kanban is part of an approach where the "pull" comes from demand. C. To be effective, Kanban must follow strict rules of use. D. Reducing the number of Kanban increases the sensitivity.

23. When using Kanban for Agile development, there are several rules that must be applied. Which of the following is NOT one of those rules?

A. Visualize the workflow B. Limit WIP C. Make process policies explicit D. Improve constantly

24. When evaluating which agile method is best which method represents the preferred starting point for those new to agile development where its rules, roles, and constructs are usually the easiest to teach and execute?

A. Scrum B. Extreme Programming C. Feature Driven Development D. Kanban

25. Which of the following is NOT a common framework used to scale agile beyond a single project?

A. SAFe B. NeXT C. DAD D. LeSS

26. A release train engineer is approached by a resource who missed the current ART and wants to be part of the team. What guidance should they provide?

A. Join the team at the next daily scrum and begin helping. B. They must wait for the next sprint to join the team. C. Join the team when the next release train is preparing to leave the station. D. Join another team until the next release.

27. Which of the following is a core value of SAFe?

A. Alignment B. Integration C. Continuous improvement D. Constant testing

28. SAFe is governed by nine principles that can be thought of as extensions of the 12 Principles found in the Agile Manifesto. Which of these principles represents the idea that resources must understand the basics of how and organization delivers business value?

A. Take a systems view. B. Manage risk, efficacy and predictability with fast, synchronous learning. C. Synchronize with cross-domain planning and collaboration. D. Understand the economics of the value chain.



Page 152

29. Which of the following is NOT fixed at project outset when using DSDM?

A. Cost B. Quality C. Scope D. Time

30. Which of the following is often used in conjunction with DSDM?

A. Scrum B. PMP C. FDD D. XP

31. Which of the following was DSDM specifically designed to be compatible with?

A. PMBOK® Guide B. ACP C. Extreme Programming D. Prince2

32. Which of the following terms is commonly used in conjunctions with DSDM that is central to its philosophy?

A. Atern B. Agile C. Complex D. Extreme

33. Which of the following is a prerequisite for the Dynamic Systems Development Methodology?

A. A development team that controls all aspects of the project process. B. Acceptance of the Agile Principles C. Acceptance of the Atern Philosophy D. A sponsor who will pay for DSDM

34. Which of the following is a prerequisite for DSDM?

A. Commitment of senior business management to provide the necessary team size. B. Commitment of senior business management to provide the necessary Business

Ambassador involvement. C. Commitment of the development to the technical solution. D. A focus on iterative delivery.

35. Which of the following is NOT a prerequisite for DSDM?

A. Access by the Solution Architect to business roles. B. Acceptance of the Atern Philosophy before starting work. C. Solution Development Team stability. D. A supportive commercial relationship.

36. When using DSDM, which of the following is NOT critical to achieving a solution that provides real business benefit?

A. By having key stakeholders understand the business objectives. B. By having key stakeholders empowered to an appropriate level. C. By having key stakeholders collaborate to deliver the right solution. D. By having key stakeholder agree to a timescale and accurate solution.



Page 153

37. Which of the following must the key stakeholders be to accept when using DSDM?

A. An incremental solution. B. A fit-for-purpose solution. C. A complete solution. D. A tested solution.

38. In DSDM and the Atern Team Model, who is NOT part of the Project Team?

A. The business visionary B. The business sponsor C. Business advisor(s) D. The technical coordinator

39. In DSDM and the Atern Team Model, who is NOT part of Solution Development?

A. Team leader B. Solution developer(s) C. Business ambassador(s) D. Technical coordinator

40. Which of the following roles is grouped as “OTHER” in the DSDM Atern Model?

A. Atern coach B. Project manager C. Business visionary D. Solution tester(s)

41. Which of the following is NOT one of the eight core DSDM principles?

A. Focus on the business need. B. Work in small teams. C. Deliver on time. D. Demonstrate control.

42. Which of the following is NOT one of the eight core DSDM principles?

A. Never compromise quality. B. Communicate continuously & clearly. C. The team must work together as one. D. Build incrementally from firm foundations.

43. Which of the following DSDM principle includes guaranteeing the minimum usable subset of features?

A. Demonstrate control. B. Deliver business value. C. Focus on the business need. D. Build incrementally from firm foundations.

44. Which of the following is NOT part of the DSDM principle of delivering on time?

A. Timebox the work B. Develop iteratively C. Focus on business priorities D. Always meet deadlines



Page 154

45. When discussing the DSDM principle of collaborate, which of the following is NOT true?

A. It is key to build the correct culture. B. You must involve the right stakeholders, at the right time, throughout the project. C. It is important to ensure that team members are empowered to make decisions for

those they represent without waiting for higher-level approval. D. You must actively involve the business representatives.

46. Which of the following is NOT a key to the DSDM principle of Never Compromising Quality?

A. Design document and test appropriately. B. Test early & continuously. C. Quality must be considered a variable. D. Set the level of quality at the beginning.

47. Which of the following is a key to the DSDM principle of building incrementally from firm foundations?

A. Strive for early delivery of business benefit where possible. B. Continually confirm the correct solution is being built. C. Formally re-assess priorities and ongoing project viability with each delivered

increment. D. All of the above

48. Which of the following DSDM core principles is defined as a focus on frequent delivery of products, with assumption that to deliver something “good enough” earlier is always better than to deliver everything “perfectly” in the end.

A. Collaborate B. Develop iteratively C. Never compromise quality D. Build incrementally from firm foundations

49. Which of the following is not part of the core DSDM principle where communication and cooperation among all project stakeholders is required to be efficient and effective?

A. Use facilitated workshops. B. Present iterations of the evolving solution early and often. C. Build customer feedback into each iteration to converge on an effective business

solution. D. Keep documentation lean & timely.

50. Which of the following is not part of the DSDM core principle of demonstrating control?

A. Present iterations of the evolving solution early and often. B. Measure progress through focus on delivery of products rather than completed

activities. C. Manage proactively. D. Evaluate continuing project viability based on the business objectives.

51. Which of the following does Alistair Cockburn define as a set of elements e.g. practices and tools?

A. Techniques B. Methodologies C. Policies D. Frameworks



Page 155

52. Which of the follow is a core focus of Crystal methods?

A. People B. Teams C. Community D. Talents

53. Which of the following Crystal methods would be best for a team with eight people on the team?

A. Crystal Clear B. Crystal Clean C. Crystal Yellow D. Crystal Magenta

54. Which of the following Crystal methods is best for projects that are ongoing?

A. Crystal Clear B. Crystal Orange Web C. Crystal Red D. Crystal Diamond

55. Which of the following is the heaviest Crystal method designed for the most mission critical projects?

A. Crystal Sapphire B. Crystal Red C. Crystal Maroon D. Crystal Diamond

56. Which of the following is NOT one of the common seven Crystal properties?

A. Reflective improvement B. Close or osmotic communication C. Personal safety D. Common retrospectives

57. Which of the following is a core part of Crystal’s concept of frequent delivery?

A. It is possible to have multiple iterations per release. B. Each release it two weeks in length. C. Each release focuses a single function of real value to the business. D. The business controls the features delivered in each iteration through systematic

retrospection.

58. Which of the following is NOT a core component of Crystal’s concept of reflective improvement?

A. Developers dedicate time to improving the development process. B. Reflection workshops are held every few weeks to help find processes that are

working & which ones need to be modified. C. Sprint Retrospectives are held at the end of each iteration to ensure the customer is

satisfied with the processes being used. D. Iteration helps determine if a process is working or not.



Page 156

59. Which of the following is a reason the Crystal methods recommend collocation of the team?

A. Developers do not need to break concentration to move somewhere else. B. Team size is easier to control which improves communication. C. It reduces project cost. D. Management function improves and overhead is reduced.

60. Which of the following core Crystal properties directs the team to use two hour periods where the developers have no interruptions and are assigned to the project for two consecutive days at a minimum?

A. Reflective Improvement B. Frequent Delivery C. Easy Access to Experts D. Focus

61. When defining Crystal’s core property of easy access to expert users, how often is it required to meet with the experts?

A. Once a week for two hours and be reachable by phone. B. Twice a week for one hour and be reachable by phone. C. Every other week for two hours and be reachable by phone. D. Three times a week and be reachable by phone.

62. Which of the following is NOT a LSD common example of waste?

A. Avoidable process repetition (often caused by insufficient testing). B. Bureaucracy. C. Defects accumulated during the development process. D. Slow internal communication.

63. Which of the following is a key element of LSD’s concept of empowering the team?

A. Encourage progress, catching errors, and removing impediments. B. The customer needs to have an overall experience of the system. This is called

perceived integrity. C. How it is being advertised, delivered, deployed, accessed, how intuitive is it to use,

what is its price, and how well does it solve problems. D. The customer provides stories based on need, the developer estimates time by story.

64. Which of the following is not one of Lean Software Development’s Seven Wastes?

A. Transportation B. Motion C. Under-processing D. Over-processing

65. Which of the following is one of the five core principles of Kanban?

A. Work collaboratively B. See the whole C. Improve incrementally D. Visualize the workflow

66. When comparing Scrum to Kanban, which of the following statements is true?

A. Kanban boards reset before each sprint. B. Kanban board columns change frequently. C. Teams rarely start with Scrum and add Kanban later. D. Scrum uses a continuous flow of work with new work added when there is capacity.



Page 157

67. Which of the following Agile methodologies is the most common Agile starting point?

A. Scrum B. Extreme Programming C. Kanban D. Crystal

68. Your project sponsor has given you latitude in the development methodology used for an upcoming project. However, you also know that testing the application will be critical, which of the following do you select?

A. Scrum B. Extreme Programming C. Feature Driven Development D. Kanban

69. When using SAFe, at what level is budgeting completed for each ART?

A. The organizational level B. The portfolio level C. The program level D. The team level

70. How many people are typically involved in an Agile Release Train?

A. 25-50 B. 50-75 C. 75-100 D. 50-125

71. How many iterations is the typical PI when using SAFe?

A. 3 B. 4 C. 5 D. 6

72. When using SAFe and within a PI, how many iterations are focused on delivering features in the backlog?

A. 2 B. 3 C. 4 D. 5

73. Within SAFe, what is the title given to the meeting where the team works to improve its process?

A. Retrospective B. Sprint review C. Inspect and adapt workshop D. Guided improvement session

74. Within SAFe, what is the title of the person who acts as the Program Manager?

A. Program Manager B. Agile Train Engineer C. Release Manager D. Release Train Engineer



Page 158

Agile Principles & Mindset Part II Exam

1. Answer B. LGd course manual p. 93 - The visualization for the DSDM lifecycle is sometimes referred to as the “Cheese and Pizza Diagram.” At the top of the diagram are the project’s upfront work of feasibility and foundation. This is where the team understands the nature of the business problem and determines the feasibility of the solution. Beginning with the Feasibility, this is all about the organization deciding whether a proposed project is viable both from a business AND a technical perspective by means of a high level investigation of the potential solutions, costs, and timeframes.

2. Answer A. LGd course manual p. 93 - DSDM Feasibility typically has six objectives that include: To establish whether there is a feasible solution to the business problem described in the Terms of Reference defined during Pre-Project; To identify the benefits likely to arise from the delivery of the proposed solution; To outline possible approaches for delivery, including strategies for sourcing the solution and project management; To describe the organization and governance aspects of the project; To state first-cut estimates of timescale and costs for the project overall; And to plan and resource the Foundations phase.

3. Answer B. LGd course manual p. 94 - There are four potential outcomes in DSDM from deployment. These include: All requirements have been satisfied. Hence, no further work is currently needed – and no returning arrow; A major change of scope was discovered during development that had to be ignored for the time being in order to deliver on the required date. This means returning to the foundations and taking the process on from there; Features that were already planned for the next increment are now to be added, so the process returns to exploration; And the next increment will solely address areas of technical concern, so the process returns to engineering.

4. Answer D. LGd course manual p. 94-95 - There are a number of prerequisites required for using the Dynamic Systems Development Method. These include: Acceptance of the Atern philosophy before starting work; Appropriate empowerment of the Solution Development Team; Commitment of senior business management to provide the necessary Business Ambassador involvement; Incremental delivery; Access by the Solution Development Team to business roles; Solution Development Team stability; Solution Development Team skills; Solution Development Team size; and a supportive commercial relationship.

5. Answer A. LGd course manual p. 96 - DSDM advocates 13 specific roles within a project. These roles have varying degrees of importance. However, a key differentiator of DSDM compared to other Agile Methodologies is how detailed these roles are and how much emphasis is placed on them. These roles include: Business Sponsor; Business Visionary; Project Manager; Technical Coordinator; Team Leader; Business Ambassador; Business Analyst; Solution Developer; Solution Tester; Business Advisor; Workshop Facilitator; Atern Coach; and Specialist Roles.

6. Answer C. LGd course manual p. 97 - The Business Ambassador generally comes from the business area being addressed and provides business-related information from the perspective of those who will ultimately make direct use of the solution. The role provides the business perspective for all decisions related to the way the solution’s fitness for business purpose is defined and implemented. Working closely with the rest of the Solution Development Team, the Business Ambassador guides the evolution of the solution, bringing other users’ input and ideas to the project as required. As a true ambassador, the role is responsible for the day-to-day communication channels between the project and the business. The Business Ambassador must have the desire, authority, responsibility and knowledge to be able to ensure that the right solution emerges to meet the business need. This does not necessarily imply a senior position within the organization, but a level of empowerment during the project to fulfil the role and an allocation of time to fully participate in the project as required.

7. Answer B. LGd course manual p. 96 — The Business Visionary is responsible for



Page 159

interpreting the needs of the Business Sponsor, communicating these to the team and, where appropriate, ensuring they are properly represented in the Business Case. The Business Visionary remains involved throughout the project providing the team with strategic direction and ensuring that the solution delivered will enable the benefits described in the Business Case to be achieved.

8. Answer C. LGd course manual p. 97 - The Business Ambassador generally comes from the business area being addressed and provides business-related information from the perspective of those who will ultimately make direct use of the solution. The role provides the business perspective for all decisions related to the way the solution’s fitness for business purpose is defined and implemented. Working closely with the rest of the Solution Development Team, the Business Ambassador guides the evolution of the solution, bringing other users’ input and ideas to the project as required. As a true ambassador, the role is responsible for the day-to-day communication channels between the project and the business. The Business Ambassador must have the desire, authority, responsibility and knowledge to be able to ensure that the right solution emerges to meet the business need. This does not necessarily imply a senior position within the organization, but a level of empowerment during the project to fulfil the role and an allocation of time to fully participate in the project as required.

9. Answer D. LGd course manual p. 99 - The Dynamic Systems Development Method is governed by eight principles. These principles establish the overarching rules every DSDM team must follow as they progress through the project. The eight principles of DSDM include: Focus on the business need; Deliver on time; Collaborate; Never compromise quality; Build incrementally from firm foundations; Develop iteratively; Communicate continously and clearly; and Demonstrate control.

10. Answer B. LGd course manual p. 102 - The Iterative Cycle is as follows: Identify — The team agree the objective of the next evolution of whatever is being developed at the moment; Plan — The team work out what needs to be done by whom to meet the current objective; Evolve — The planned activities take place in the agreed timescale; and Review — The results of the activities are checked to see if the objective has been achieved.

11. Answer C. LGd course manual p. 102 - In a DSDM project where time has been fixed, understanding the relative importance of things is vital to making progress and keeping to deadlines. Prioritization can be applied to requirements, tasks, products, use cases, user stories, acceptance criteria and tests. MoSCoW is a technique for helping to understand priorities. The letters stand for: Must Have; Should Have; Could Have; And won’t Have this time

12. Answer B. LGd course manual p. 103-104 - Every Timebox can be begins with a Kick-off and ending with a Close-out meeting. The Timebox itself comprises three main stages or Iterations – Investigation, Refinement, Consolidation. Each stage represents a pass through the Iterative Development cycle. The longest cycle is the refinement stage.

13. Answer A. LGd course manual p. 107 - The core areas of focus for Crystal include: People; Interaction; Community; Skills; Talents; and Communications.

14. Answer B. LGd course manual p.108 - Cockburn developed different methods within the Crystal family to suit projects of varying team size that naturally required different strategies to deliver business value. The family uses colors to denote the “weight” of the methodology being used. As the project becomes larger, with more team members and is more mission critical to the organization the appropriate version adds more process. Crystal Yellow is for 7 to 20 people.

15. Answer C. LGd course manual p. 108-110 - The seven common properties or practices of Crystal include: Frequent delivery, Reflective improvement, Close or osmotic communication, Personal safety, Focus, Easy access to expert users, and Automated tests, configuration management, frequent integration.



Page 160

16. Answer D. LGd course manual p. 110-114 - There are seven principles that provide the foundation of Lean Software Development. These principles include: Eliminate waste, Amplify learning, Decide as late as possible, Deliver as fast as possible, Empower the team, Build quality in, and See the whole.

17. Answer C. LGd course manual p. 114 - Only when all of the lean principles are implemented together, combined with strong "common sense" with respect to the working environment, is there a basis for success in software development. There are three keys to seeing the whole: Defects accumulate during the development process; By decomposing big tasks into smaller ones and standardizing the stages of development defect root causes can be found and eliminated; Think big, act small, fail fast, learn rapidly.

18. Answer B. LGd course manual p. 114 - Muda is a Japanese word meaning "futility; uselessness; idleness; superfluity; waste; wastage; wastefulness", and is a key concept in the Toyota Production System (TPS) as one of the three types of deviation from optimal allocation of resources (muda, mura, muri).

19. Answer A. LGd course manual p. 115 - Value stream mapping is a lean-management method for analyzing the current state and designing a future state for the series of events that take a product or service from its beginning through to the customer. At Toyota, it is known as "material and information flow mapping". It can be applied to nearly any value chain.

20. Answer D. LGd course manual p. 115-116 - The Poppendiecks describe a number of Lean Software Practices they call tools that vary slightly from their equivalents in Agile Software Development. These tools include: seeing waste; value stream mapping; set based development; pull systems; queueing theory; motivation; and measurement.

21. Answer C. LGd course manual p. 116 - The Poppendiecks created a unique model of waste know by the acronym TIMWOOD. It represented seven fundamental types of waste including: Transportation; Inventory; Motion; Waiting; Over-Processing; Over-Production; Defects

22. Answer A. LGd course manual p. 118 - Kanban, by contrast, is part of an approach where the "pull" comes from demand. Re-supply or production is determined according to the actual demand of the customer. In contexts where supply time is lengthy and demand is difficult to forecast, often, the best one can do is to respond quickly to observed demand. This situation is exactly what a Kanban system accomplishes, in that it is used as a demand signal that immediately travels through the supply chain. This ensures that intermediate stock held in the supply chain are better managed, and are usually smaller. Where the supply response is not quick enough to meet actual demand fluctuations, thereby causing potential lost sales, stock building may be deemed more appropriate, and is achieved by placing more Kanban in the system. Taiichi Ohno stated that, to be effective, Kanban must follow strict rules of use.

23. Answer D. LGd course manual p. 117-118 - When using Kanban for Agile Development, there are several rules that must be applied. These include: Visualize the workflow; Limit WIP; Manage flow; Manage process policies explicit; Improve collaboratively.

24. Answer A. LGd course manual p. 119-120 - Kanban, by contrast, is part of an approach where the "pull" comes from demand. Re-supply or production is determined according to the actual demand of the customer. In contexts where supply time is lengthy and demand is difficult.

25. Answer B. LGd course manual p. 121 - SAFe or the Scaled Agile Framework, Disciplined Agile Delivery or DAD, LeSS and Nexus all represent common tools for scaling agile.



Page 161

26. Answer C. LGd course manual p. 122 - The Agile Release Train is guided by a Release Train Engineer who acts as the program manager. Additionally, the various teams are supported by a Train System Architect who facilitates the process of developing infrastructure for future program increments. Imagine three, four or five Scrum Teams who each have a backlog with four two week iterations defined, as these teams work on their backlog there is an additional, very senior technical resource working ahead of these teams so that when it is time for the next ART the architecture and Program Backlog is defined and ready for the team to begin work. At this time any new resources can jump on the new release train and the process begins. Therefore, the best advice is join the team when the next release train is preparing to leave the station.

27. Answer A. LGd course manual p. 122 - SAFe focuses on four core values. These values include: Alignment is a position of agreement or alliance. Visibility or transparency; Program Execution — It is not enough for an individual team to perform well. That still allows for the overall program to fail. Success is defined by everyone focusing on the overall program; and Code Quality — The team must define what quality means for the program and then deliver that measure.

28. Answer D. LGd course manual p. 125-126 - SAFe is governed by nine principles that build on Lean, Systems Thinking, and Agile Development. In many respects these can be thought of as extension of the 12 Principles found in the Agile Manifesto. They include: Take a systems view; Understand the economics of the value chain; Develop systems iteratively and incrementally; Integrate and test frequently and adapt immediately; Manage risk, efficacy and predictability with fast, synchronous learning cycle; Limit work in process. Reduce batch sizes. Manage queue lengths; Synchronize with cross-domain planning and collaboration; Base milestones on objective evaluation of working systems; and Decentralize decision-making. Understand the economics of the value chain represents the idea that resources must understand the basics of how and organization delivers business value.

29. Answer C. LGd course manual p. 92 - DSDM is both iterative and incremental. This means it is just like every other Agile methodology. It fixes cost, quality, and time at the beginning of the project. This makes it somewhat unique. Most Agile methodologies play an interesting game with the traditional Triple Constraints of Project Management.

30. Answer A. LGd course manual p. 93 - DSDM is most often used to provide an overall project framework in conjunction with Scrum. DSDM advocates it is the ideal wrapper for more limited Agile frameworks, and DSDM provides the full project focus while a method like Scrum focuses on the product development process.

31. Answer D. LGd course manual p. 92 - DSDM was created in 1994 to add discipline to Rapid Application Development. It was originally designed It was originally designed to be compatible with both ISO 9000 and Prince2.

32. Answer A. LGd course manual p. 92 - DSDM has gone through a number iterations beginning with its first rebranding in 2007, when the name was changed to DSDM Atern. The addition of Atern was a reference to the Artic Tern, a collaborative bird that can travel distances and epitomized many parts of the method in its natural behavior such as prioritization and collaboration. In 2014, the framework was revised again and the name changed back to just DSDM. Today, DSDM is most often used to provide an overall project framework in conjunction with Scrum. DSDM advocates argue it is the ideal wrapper for more limited Agile frameworks. Advocates argue DSDM provides the full project focus while a method like Scrum focuses on the product development process.



Page 162

33. Answer C. LGd course manual p.94 - There are a number of prerequisites required for using the Dynamic Systems Development Method. One of these is the acceptance of the Atern philosophy before starting work. This philosophy is relatively simple. A project must be aligned to clearly defined strategic goals of the organization. The team must then focus on the early delivery of real benefits to the business. According to the philosophy, this is best achieved when key stakeholders understand the business objectives, are empowered to an appropriate level and collaborate to deliver the right solution. This solution must be delivered in the agreed timescale and according to the priorities set by the business.

34. Answer B. LGd course manual p.94-95 - There are a number of prerequisites required for using the Dynamic Systems Development Method. One of these is the commitment of senior business management to provide the necessary Business Ambassador involvement. Stakeholders are not allowed to assign work to the team and walk away from the project. It is assumed that a Business Ambassador will be involved daily with the project team.

35. Answer A. LGd course manual p.94-95 - There are a number of prerequisites required for using the Dynamic Systems Development Method. These include: Acceptance of the Atern philosophy before starting work; Appropriate empowerment of the Solution Development Team; Commitment of senior business management to provide the necessary Business Ambassador involvement; Incremental delivery; Access by the Solution Development Team to business roles; Solution Development Team stability; Solution Development Team skills; Solution Development Team size; And a supportive commercial relationship.

36. Answer D. LGd course manual p.95 - This philosophy is relatively simple. A project must be aligned to clearly defined strategic goals of the organization. The team must then focus on the early delivery of real benefits to the business. According to the philosophy, this is best achieved when key stakeholders understand the business objectives, are empowered to an appropriate level and collaborate to deliver the right solution. This solution must be delivered in the agreed timescale and according to the priorities set by the business. The stakeholders must be prepared to accept a fit-for-purpose solution. They must also be prepared to accept that change is inevitable as the team comes to understand more about the solution being delivered.

37. Answer B. LGd course manual p. 95 - The stakeholders must be prepared to accept a fit-for-purpose solution. They must also be prepared to accept that change is inevitable as the team comes to understand more about the solution being delivered.

38. Answer C. LGd course manual p. 96-98 - DSDM advocates 13 specific roles within a project. These roles have varying degrees of importance. However, a key differentiator of DSDM compared to other Agile Methodologies is how detailed these roles are and how much emphasis is placed on them. Atern identifies roles in three categories: Project, Solution Development and Other. The business interests are represented by the Business Sponsor, Business Visionary, Business Ambassador, Business Analyst and Business Advisor. The solution/technical interests are represented by the Technical Coordinator, Team Leader, Solution Developer and Solution Tester. Management and ‘other’ interests are represented by the Project Manager, Workshop Facilitator and Atern Coach. On an Atern Project, one role may be taken by several people, or one person may take several roles. The Business Advisor is ancillary to the project team.

39. Answer D. LGd course manual p. 96-98 - DSDM advocates 13 specific roles within a project. These roles have varying degrees of importance. However, a key differentiator of DSDM compared to other Agile Methodologies is how detailed these roles are and how much emphasis is placed on them. Atern identifies roles in three categories: Project, Solution Development and Other. The business interests are represented by the Business Sponsor, Business Visionary, Business Ambassador, Business Analyst and Business Advisor. The solution/technical interests are represented by the Technical Coordinator, Team Leader, Solution Developer and Solution Tester. Management and ‘other’ interests are represented by the Project Manager, Workshop Facilitator and Atern Coach. On an Atern Project, one role may be taken by several people, or one person may take several roles.



Page 163

40. Answer A. LGd course manual p.98 - DSDM advocates 13 specific roles within a project. These roles have varying degrees of importance. However, a key differentiator of DSDM compared to other Agile Methodologies is how detailed these roles are and how much emphasis is placed on them. Atern identifies roles in three categories: Project, Solution Development and Other. The business interests are represented by the Business Sponsor, Business Visionary, Business Ambassador, Business Analyst and Business Advisor. The solution/technical interests are represented by the Technical Coordinator, Team Leader, Solution Developer and Solution Tester. Management and ‘other’ interests are represented by the Project Manager, Workshop Facilitator and Atern Coach. On an Atern Project, one role may be taken by several people, or one person may take several roles.

41. Answer B. LGd course manual p. 99-101 - The Dynamic Systems Development Method is governed by eight principles. These principles establish the overarching rules every DSDM team must follow as they progress through the project. The eight principles of DSDM include: Focus on the business need; Deliver on time; Collaborate; Never compromise quality; Build incrementally from firm foundations; Develop iteratively; Communicate continuously and clearly; and demonstrate control.

42. Answer C. LGd course manual p. 99-101 - The Dynamic Systems Development Method is governed by eight principles. These principles establish the overarching rules every DSDM team must follow as they progress through the project. The eight principles of DSDM include: Focus on the business need; Deliver on time; Collaborate; Never compromise quality; Build incrementally from firm foundations; Develop iteratively; Communicate continuously and clearly; and demonstrate control.

43. Answer C. LGd course manual p. 99 - Focus on the business need — The main acceptance criteria for every project is delivering something that addresses the defined business need. This principle includes several components: Clearly define the scope of the system; Understand the true business priorities; Establish a sound business case; Seek continuous business sponsorship and commitment; Guarantee the minimum usable subset of features.

44. Answer B. LGd course manual p. 100 - I am sure that this is news, but delivering on time is kind of a big deal. There are many situations where delivering a project late can undermine the very reason for doing the project in the first place. DSDM focuses the team on this principle by: Timebox project work. This means that the end date of each iteration is fixed. Focus on business priorities. Technology is not an end unto itself. The product of the project must serve a business need And, always hit deadlines. This should be obvious, but it doesn’t happen very often.

45. Answer A. LGd course manual p. 99 - Decisions must be made with users and developers working together quickly. When a team works collaboratively they almost always outperform groups of individuals working independently. Components of collaborate include: Involve the right stakeholders, at the right time, throughout the project; Ensure that the members of the team are empowered to make decisions on behalf of those they represent without waiting for higher-level approval; Actively involve the business representatives and build a one-team culture.



Page 164

46. Answer C. LGd course manual p. 99 - Never compromise quality - The level of quality must agreed upon at the beginning of the project. Quality cannot be a variable thing. The measure of quality must be quantitative and objective so that both the business and the development team can agree when the features that are part of the minimum usable subset is complete. In order to achieve this result the team must: Set the level of quality at the beginning. Make sure everyone involved in the project understands what success looks like and how it will be measured. Once missed, expectation can lead to disaster. The components of never compromising on quality include: Ensure that quality does NOT become a variable. Quality must be binary. It cannot be a sliding scale. The team must have a clear cutoff; Design, document, & test appropriately. The team must use the appropriate level of design, testing and documentation for the complexity and importance of the project; Build in quality by constant review. Every Agile project makes use of an iterative process. These loops allow the team to constantly evaluate their output to ensure it correctly meets the quality standards; Test early and continuously; and testing cannot be something done only at the end of the project. The team must test early to catch errors when they are small and never assume they have tested enough.

47. Answer D. LGd course manual p. 100 - Incremental delivery provides a number of advantages. An easy way to understand incrementalism is to think about bite-sized chunks. It is much easier to swallow a small bite as opposed to a large one. It also give you confidence that you actually like what you are eating. It is the same for the customer of a software project. Constantly seeing working software confirms the team is building what they want gives them confidence in the team. It also provides a primary point of feedback for the team. Finally, when these increments are regularly deployed, the organization gains early business value. Keys to this principle include: The team striving for early delivery of business benefit wherever possible; The team continually confirming the correct solution is being built; And formally re-assess priorities and ongoing project viability with each delivered increment.

48. Answer B. LGd course manual p. 100 - As we have already learned, iterative development is very closely related to incremental development. Both are also key to Agile. Iterative development is a fancy way of saying short, repeating or looping cycles. The premise is that rarely does a team get things perfect the first time. In most cases, the team needs several cycles with repeated feedback from the customer to get it right.

49. Answer C. LGd course manual p. 98-101 - One of the biggest causes of project failure is poor communication. DSDM uses a variety of techniques to improve overall communication for both teams and individuals. DSDM focuses the team on the value of human interaction through the Daily Standups, Facilitated Workshops, and clearly defined roles and user involvement. The extensive use of modelling and prototyping help to ensure the product of the project is available for early scrutiny. This principle requires the team: Run daily team stand-up sessions; Use facilitated workshops; Use rich communication techniques such as modelling and prototyping; Present iterations of the evolving solution early and often; Keep documentation lean and timely; Manage stakeholder expectations throughout the project; and encourage informal, face-to-face communication at all levels.

50. Answer A. LGd course manual p. 101 - A DSDM team needs to be proactive when monitoring and controlling progress in line with the Foundations Phase products, especially the Business Case. You need to be able to prove you are in control. In order to fulfil this principle, Atern teams, especially the Project Manager and Team Leader, will: Use an appropriate level of formality for tracking and reporting; Make plans and progress visible to all; Measure progress through focus on delivery of products rather than completed activities; Manage proactively; and evaluate continuing project viability based on the business objectives.

51. Answer B. LGd course manual p.107 - Crystal is usually described as a “light-weight methodology”. The use of the word Crystal comes from the gemstone where, in software terms, the faces are a different view on the “underlying core” of principles and values. The faces are a representation of techniques, tools, standards and roles. The methodology tends to avoid any strict or rigid processes found in other methodologies.



Page 165

52. Answer A. LGd course manual p. 107 - Cockburn define the core areas of focus for Crystal. These are as follows: People, Interaction, Community, Skills, Talents, Communications.

53. Answer C. LGd course manual p. 108 - The table at the bottom of the page defines the team size for each version of Crystal: 2-6 people Crystal Clear; 7-20 people Crystal Yellow; 10-40 people Crystal Orange; Crystal Orange Web; Up to 80 people Crystal Red; Then Crystal Maroon; Crystal Diamond; Crystal Sapphire.

54. Answer B. LGd course manual p. 108 - The table at the bottom of the page defines the team size for each version of Crystal: 2-6 people Crystal Clear; 7-20 people Crystal Yellow; 10-40 people Crystal Orange; Crystal Orange Web; Up to 80 people Crystal Red; Then Crystal Maroon; Crystal Diamond; Crystal Sapphire.

55. Answer A. LGd course manual p. 108 - The table at the bottom of the page defines the team size for each version of Crystal: 2-6 people Crystal Clear; 7-20 people Crystal Yellow; 10-40 people Crystal Orange; Crystal Orange Web; Up to 80 people Crystal Red; Then Crystal Maroon; Crystal Diamond; Crystal Sapphire.

56. Answer D. LGd course manual p.108-110 -The various versions of Crystal share seven common properties or practices. Like the other Agile methodologies we have already covered, these can be thought of as general rules Crystal expects to be followed. These properties include: Frequent delivery; Reflective improvement; Close or osmotic communication; Personal safety; Focus; Easy access to expert users; Automated tests, configuration management and frequent integration.

57. Answer A. LGd course manual p. 108 - Frequent delivery is the regular releasing of iterations of the software program. This idea comes from the 12 Principles of Agile Development. Designers and developers decide what features to include in each release and they design and test for each release. With Crystal Methods, iterations are to be released in short iterations with the timescale being somewhere between weekly to quarterly. By releasing iterations, stakeholders are able to spot problems earlier in the project which saves a lot of hassle later on. Another point on this is that if the end users decide that the project does not do things the way they’d like it to be done, then steps can be taken to resolve this before it is too late. With Crystal Methods, there can be more than one iteration in a release. This is because it may not be feasible to release every iteration, so a collection of iterations are gathered and delivered in a single release.

58. Answer C. LGd course manual p. 109 - Reflective improvement involves the Development Team periodically taking a break from regular coding efforts to focus on finding ways to improve their processes. Iterations help with this by providing feedback on whether or not the current process is working. Crystal Methods, uses Reflection Workshops that meet every couple of weeks. These workshops focus on finding processes that are and are not working well then helping the team to modify those processes so they improve.

59. Answer A. LGd course manual p. 109 - With regards to larger teams (over 8 or so), where distraction can arise, Close Communication is used. The team must be in the same room for this to work. This is because if the developer has to break concentration to move somewhere else to ask a question then his or her thought process will is often lost. By using this type of communication, information flows quickly throughout the team. Questions can be rapidly answered and all the team members know what is going on as well as having the ability to correct any misconceptions that may arise. By listening to the others in the team, a developer can pick up on what the others are doing, gain experience and develop new ideas. Developers working near each other can help with problems that the other is encountering. Communication overhead is greatly reduced by using this type of communication. The need for email updates, extra documentation, etc. is lowered. By having the team together, each member knows what the others are doing so they should be able to take over their teammate's parts of the project as required.



Page 166

60. Answer D. LGd course manual p.109 - Focus in crystal refers to two things; firstly focusing on an individual task in a project for enough time that progress will be made and secondly, it refers to the direction of which the project is heading. With the first, the flow of progress is taken into account while thinking of issues that affect it such as interruptions, meetings, long questions, phone call, etc. It can take a while to get back into the flow again so this delays completion of the current task. Crystal defines two rules for dealing with issues that may interrupt focus. One is to set a two-hour period where the developer is to have no interruptions. The other one is to assign a developer to a project for at least two days before being switched to another project. With the second meaning of focus, issues such as definition of goals are discussed. The definitions should be clear and the developers should know exactly what the goals of the project are. The project leader should prioritize the goals which will allow developers to focus on particular areas.

61. Answer B. LGd course manual p. 110 - Easy access to expert users involves the developers working with a person of expertise in the project area so that the expert can answers any questions, suggest solutions to problems, etc. The expert user should be an actual/real-life user and not just a tester from the development team. The more involved the expert user is (in practical terms), the better since they would have more hands-on experience. The more time that the expert user can give will greatly help the overall project but this is not always feasible. There should be a minimum of a once a week, two-hour meeting with the expert user, and the ability to make phone calls to the expert user too.

62. Answer C. LGd course manual p. 110 & 114 - The Lean Philosophy regards everything not adding value to the customer as MUDA or waste. This waste comes in several forms: Unnecessary code and functionality; Delay in the software development process; Unclear requirements; Avoidable process repetition (often caused by insufficient testing); Bureaucracy; And slow internal communication.

63. Answer A. LGd course manual 112 - The Lean approach focuses on the simple rule, find good people and then trust them to get the job done. Good managers encourage, remove impediments and avoid micro-managing. The developers should be given access to the customer; the team leader should provide support and help in difficult situations, as well as ensure that skepticism does not ruin the team’s spirit. The most effective teams use a Work-Out Technique when the managers do NOT tell workers how to do their job. The guidelines include: Find good people and let them do their own job; Encourage progress, catching errors, and removing impediments; Discourage micro management; People are more than just resources. They require motivation and a higher purpose; and the developer should be given access to the customer.

64. Answer C. LGd course manual p. 116 - The Lean Philosophy regards everything not adding value to the customer as MUDA or waste. This waste comes in several forms: Unnecessary code and functionality; Delay in the software development process; Unclear requirements; Avoidable process repetition (often caused by insufficient testing); Bureaucracy; and slow internal communication.

65. Answer D. LGd course manual p. 117-118 - When using Kanban for Agile Development, there are several rules that must be applied. These include: Visualize the workflow; Limit WIP; Manage flow; Make process policies explicit; and Improve collaboratively.

66. Answer B. LGd course manual p. 118 - Scrum Boards tend to change infrequently. Once the Development Team builds the Board they do not typically add or delete columns. The tool is so simplistic that doing so seldom makes sense. Kanban Boards DO change frequently. A Kanban Board is supposed to reflect the process being used. As the process evolves and changes the Board must change with it.

67. Answer A. LGd course manual p. 119 - Scrum often represents the best starting point for those new to Agile Development. Its rules, roles and constructs are usually the easiest to teach and execute.



Page 167

68. Answer B. LGd course manual p. 119 - XP is all about testing. If the team is already experienced with Scrum or some other Agile Methodology and is focused on improving product quality this is a great choice, but remember XP is truly ruthless in its testing mantra. If the team lacks the tools or skills in this area XP won’t give you the tools, but it will quickly point out the problem.

69. Answer B. LGd course manual p.122 - SAFe begins with level I. This is the portfolio level. At the portfolio level, strategic themes are used to connect the portfolio of projects to the organizational strategic objectives. This level also requires budgeting be completed for the entire program. Remember, programs represent groups of related projects managed in a coordinated way to obtain a shared value for the organization. Each program is referred to as an Agile Release Train or ART in SAFe. Then, Epics are created to fund cross ART training or deliverables. SAFe makes use of Kanban at the portfolio level to represent Agile Release Trains.

70. Answer D. LGd course manual p. 122 - Each ART is made up of between 50 and 125 people. Within each Train are groups of related project teams. Individual resources are not trapped, if they miss an Agile Release Train they are able to catch the next one because they occur at regular intervals.

71. Answer C. LGd course manual p.122 - In the SAFe the increments of a Release Train are called Program Increments or PIs. Each PI is made up of five timeboxed iterations by default. The length of time these iterations take is dependent on the methodology used by the team specifically executing the project.

72. Answer C. LGd course manual p. 122 - Four of these iterations are focused on the delivering features found on the Product Backlog, and one iteration is used for incremental planning. This single iteration allows the team to deal with unexpected issues or generate previously un-thought of creative solutions to issues.

73. Answer C. LGd course manual p. 122 - 4 of these iterations focus on the delivering features found on the Product Backlog, & one iteration is used for incremental planning. This single iteration allows the team to deal with unexpected issues or generate previously un-thought of creative solutions to issues. Through this process the team makes used of a session called the Inspect and Adapt Workshop designed to allow the entire ART to come together and improve the overall operation of the program.

74. Answer D. LGd course manual p.122 - The Agile Release Teach is guided by a Release Train Engineer who acts as the program manager.

Chapter 5 — Value-Driven Delivery


Page 168

Slide 168

Slide 169

Page 168

Value Driven Delivery Value Driven Delivery Overview Value-Driven Delivery is what every project is really all about, but before we get into the details of this domain, let’s spend a few minutes discussing the fourteen specific tasks defined in the domain. These tasks are broken into four groups: defining positive value; avoiding potential downsides; prioritization; and incremental development. Here are the tasks for these groups.

Define Positive Value

Define the deliverables by identifying units that can be produced incrementally in a way that will maximize their value to stakeholders and simultaneously minimize non-value added work.

Refine requirements by reaching a consensus on the acceptance criteria for features on a just-in-time basis in order to deliver value.

Select and tailor the team’s process based on project and organizational characteristics, as well as on the team’s experience in order to optimize value delivery.

Avoid Potential Downsides

Plan for small releasable increments of features by organizing requirements into minimally marketable features/minimally viable products in order to allow for the early recognition and delivery of value.

Limit the increment size and increase the frequency of reviews with appropriate stakeholders in order to identify and respond to risks early and at minimal cost.

Solicit customer and user feedback by reviewing increments often in order to confirm and enhance business value.

Prioritization

Prioritize the units of work through collaboration with stakeholders in order to optimize the value of the deliverables.

Perform frequent review and maintenance of the work results by prioritizing and maintaining the internal quality in order to reduce the overall cost of incremental development.

Continuously identify and prioritize the environmental, operational, and infrastructure factors in order to improve the quality and value of the deliverables.

Incremental Development

Conduct operational reviews and/or have periodic checkpoints with stakeholders in order to obtain feedback and corrections to the work in progress and planned work.



Page 169

Slide 170

Slide 171-173

Balance the development of deliverable units and the risk reduction efforts by incorporating both value producing and risk reducing work into the backlog, in order to maximize the total value proposition over time.

Re-prioritize requirements periodically in order to reflect changes in the environment and stakeholder needs or preferences in order to maximize the value.

Elicit and prioritize relevant non-functional requirements (such as operations and security) by considering the environment in which the solution will be used in order to minimize the probability of failure.

Conduct frequent reviews of work products by performing inspections, reviews, and/or testing in order to identify and incorporate improvements into the overall process and in the product or service.

Value-Driven Delivery is a common battle cry in many forms of Agile Development. It represents the simple idea that every project has at its center a responsibility to deliver real business value, but Agile carries this simple idea one step further by also contending that it is critical that a project deliver the most important features first while also considering technical dependencies and risks. The key to this is remembering why projects are initiated in the first place.

Projects are undertaken to generate some type of business value, be it to produce a benefit, product, or service. Even safety and regulatory compliance projects can be expressed in terms of business value by considering the business risk and impact of not undertaking them. If obtaining some value is the reason for doing projects, then value driven delivery is the focus of the project throughout the course of the planning, execution, and control processes. Value-Driven Delivery represents the big picture view. It means wearing of the sponsor’s hat when making decisions. When the project leader and the team assume this viewpoint, they gain the opportunity to incorporate unique technical insights—such as technical dependencies or risk reduction steps—into the selection of features for a release that the sponsor may not be aware of. Value Driven Delivery remains a guiding vision for much local decision making so that choices maximize the value delivered to the business or customer.

Assessing Business Value So how does a team determine business value? There are actually more ways than you might think—so many in fact that a single book couldn’t cover them all well. The challenge is that most of the ways to determine value are highly subjective and personal to the individual stakeholder. Such diversity makes it almost impossible for a project team to succeed. Therefore, it is important that some kind of boundaries and definitions are applied before moving forward. Within these boundaries there are two ways to determine business value. They are as follows:

Benefit measurement methods — These are comparative tools used to look at one potential project versus another. They include peer reviews, scoring models, and economic models, all of which will be described in detail in just a few moments.



Page 170

Future Value Formula

Present Value Formula

Constrained optimization methods — These represent advanced mathematical models that are used to calculate project value. Methods included in this class are linear, integer, dynamic and multi-objective programming.

As was mentioned above, there are a number of economic models with which you must be comfortable. They include:

Payback Period — The payback period represents the amount of time (typically expressed in months) until the amount invested to complete the project is returned in profit. That point is referred to as the break even point.

Future Value — The future value represents the value of an investment at some future point based upon a provided interest rate. Very few, if any, test candidates have to calculate the future value, but understanding it is necessary to answer some of the comparative questions you might see. It is defined by the formula:

FV = PV * (1 + i)n

where PV = Present Value, i = Interest Rate and n = Term in Question

Present Value — The present value, or discounting, refers to a future value that has been discounted to express it in today’s currency. For example, imagine you had $100 buried in a coffee can in your backyard. Twenty-five years later you dig up the coffee can and find the $100 bill. Does it still have the same purchasing power? Absolutely not! Inflation has made that $100 worth significantly less. This equation also is not often seen on the exam, but it is necessary to understand the next formula. The equation for the present value is:

PV = FV / (1 + i)n

where FV = Future Value, i = Interest Rate, and n = Term in question

Net Present Value (NPV) — The net present value is almost identical to the present value. In the present value calculation you discount the value (which typically represents a revenue stream) to account for inflation or some other similar rate. Net present value does the same thing, but it also takes into consideration the money that must be spent to complete the project over time. To do so, it costs the present value from the net costs to obtain the NPV.

Internal Rate of Return (IRR) — If you have followed these equations carefully, you might have noticed the variables in each are largely the same. In addition, each equation assumes that the term and interest rates are provided. In an internal rate of return equation, it is the interest rate that must be determined. Unfortunately, there is no simple equation to calculate the internal rate of return. To solve for the IRR you must use the NPV calculation and select the middle most interest rate of the four potential answers. You are looking for an interest rate which produces an NPV of zero. Based upon the result from the first calculation you can determine if you need a larger or



Page 171

Slide 174

smaller value. You should not have to calculate the NPV more than twice to determine the correct IRR.

Benefit / Cost Ratio (BCR or BCI) — Most people are used to talking about a cost / benefit ratio and this is the same thing. The only difference is that the benefits are always placed in the numerator while the costs are placed in the denominator. This is done so that any value greater than one is good.

Depreciation — Calculations are used to reduce the value of a large asset primarily for tax purposes. It represents the wearing out of equipment. Although possible, it is unusual to select a project based upon depreciation. The four most common methods of depreciation are discussed later in this course.

Opportunity Cost — Opportunity cost is the value of the next highest alternative—assuming the alternatives are mutually exclusive. It defines what you are giving up by making the choice.

Sunk Costs — Sunk costs represents the money that has already been spent on the project. It cannot be recovered. You should never make a project decision based upon sunk costs because it could be an instance of good money following bad.

Economic Value Added (EVA) — This concept rarely appears on the exam. It references whether or not the project returns more value to the organization than it costs to produce.

Working Capital — Working Capital is an accounting term defined as the current assets minus the current liabilities. It shows how much money the organization has to invest in projects.

Law of Diminishing Returns — The Law of Diminishing Returns argues that with every process you reach a point where adding one more dollar of cost will not add an equal return of value. When increasing the costs by a dollar does not provide at least a dollar return, you should not invest any more.

For the exam, it is important that you understand WHEN these tools are used to maximize value to the organization. The good news, is that these terms are not nearly as important as they are for the PMP® Exam. When discussing Agile Development, a much greater focus is placed on the fundamental concept of value and the notion that everyone must plan value into the project beginning with the process of chartering the project.

The Charter & Value Chartering exists in Agile projects. However, many Agilists would argue they are not the same. The Agilist contends that a charter in an Agile project is different because it is shorter, typically a single page. In a practical sense this view is often true, but not because there are any rules in the PMBOK Guide® or any other resource that dictates how long the charter should be. In the real world, many organizations create incredibly longwinded charters with page after page of



Page 172

Slide 175

Slide 176

requirements in hopes of dealing with all the scope change they usually experience. Usually, this effort fails and they end up throwing most of this work out and feeling frustrated. The earlier discussion of the Five Line covers this area.

Value Stream Mapping The next tool central to Agile Development is Value Stream Mapping. This tool was also discussed previously, but let’s now go into greater detail. Remember, Value Stream Mapping is a lean management technique for analyzing the current and future state for the series of events that tracks a specific product or service from beginning to end. It is a visual technique that uses something called a “Visual Map.” The process of Value Stream Mapping consists of six steps. These steps include:

Identify the product or service that you are analyzing.

Create a value stream map of the current process that identifies the steps, queues, delays, and information flows.

Review the map to find delays, waste and constraints.

Create a new value stream map of the desired future state of the process, one that is optimized to remove or reduce delays, waste and constraints.

Develop a roadmap for creating the optimized state.

Plan to revisit the process in the future to continually improve.

The process begins with the team having a specific product or service that requires mapping. The image shows the first five steps in this process as swim lanes. At the top, the process to be mapped is relatively simple. You and a friend wants to eat cake. The next step in the process requires you and your friend to define all the

Value Add

Non-Value Add

1 Minute 2 Minutes 2 Minutes 2 Minutes 10 Minutes

4 Minutes 6 Minutes 15 Minutes 5 Minutes



Page 173

Total Cycle Time Formula

Slide 177

steps involved in obtaining and eating the cake. In this case the process is relatively simple. First, you must go to the local bakery and select a cake from the display of cakes in the case. You then must go to the counter and ask for that cake before taking it to the checkout counter or line. Once you have taken the cake home it must be unpacked and sliced before you and your friend can enjoy it together.

The next step of the process requires you to examine this process and determine which steps create delays or constraints in the process. As we examine the cake eating process, we find two possible constraints: the baker and the sales person are both limiting factors. The assumption here is there is only one of each. In addition, we add a potential loop between the bakery counter and the cake selection process. Next you need to define which of these steps add value and which do not. In addition to categorizing the tasks, it is important to define how much time each step takes. At this point, you now have the image at the bottom.

The next step is that you must examine the process and decide how to reduce the overall time the process takes. After all, you want to eat the cake as quickly as possible! Notice that the non-value added step—where the product (the cake) is transferred from one station to the next—takes the most time. This is often the case. Your job is then to reduce the amount of time the non-value added steps take to have the greatest impact. You end this process by creating an optimized map showing the desired process. Both you and your friend continue the process of reducing the non-value added steps until you achieve the optimized state.

A big part of Value Stream Mapping is calculating something called Total Cycle Time. Total Cycle Time represents all the processes, steps, machine work and anything else through which a product must pass before it is considered “finished.” It is often broken into several different types of time, including the following:

Manual Cycle Time — The time spent loading, unloading, flipping or turning parts, and adding components to parts while remaining in the same machine or process.

Machine Cycle Time — The processing time of a specific machine as it works on a part.

Auto Cycle Time — The time a machine runs unaided (automatically) without manual intervention.

Overall Cycle Time — The complete time it takes to produce a single unit. This term is usually used when speaking of a single machine or process.

Mathematically, the Total Cycle Time or TCT is defined as the Value Added Time + Non-Value Added Time. For the example in the image shown previously the TCT would be as follows:

TCT = (1+2+2+2+10) + (4+6+15+5) = 47 Minutes

In addition to the Total Cycle Time, you must be prepared to calculate the Process Cycle Efficiency. This represents the Value Added Time divided by the Total Cycle Time. According to Six Sigma, a lean process is one in which the Value



Page 174

Slide 180

Slide 181

Added Time is 25% or more of the total time in the process. If we return to our example, we see that the Value Added Time is 17 minutes and the Total Cycle Time is 47 minutes. Therefore, our formula is:

PCE = 17/47 = 36%

In the last chapter, Muda (waste) was described along with Poppendieck’s TIMWOOD acronym, which is used to remember the seven forms of waste. In some of their other writing these same forms of waste are presented in another form. Most of these are the same, so if you are confused simply focus on the ones found in TIMWOOD. For the sake of completeness, however, here are their seven forms of waste translated from Lean Manufacturing to software development:

Partially Done Work — Work started but not completed. Partially done work can entropy. Examples include code waiting for testing or features waiting for development.

Extra Processes — Extra work that does not add value. Examples include unused documentation or unnecessary approvals.

Extra Features — Features that are not required, or are thought of as “nice-to-haves.” Examples include Gold Plating or cool technology features.

Task Switching — Multi-tasking between several different projects when there are context-switching penalties. A common example occurs when people are asked to work on multiple projects at the same time.

Waiting — Waiting occurs when there are delays as a result of reviews and approvals. Examples include waiting for prototype reviews or waiting for document approvals.

Motion — The effort required to communicate or to move information or deliverables from one group to another. If teams are not co-located, this effort may need to be greater. The most common examples are distributed, non-collocated teams or handoffs.

Defects — Defects cover a wide range of issues such as incorrect documents or software that must be fixed. Common examples are seen in requirements defects and software bugs.

Prioritization When the team is focused on Value-Driven Delivery it has a customer valued prioritization. This means working on the things that yield the greatest return for the customer. The primary tool used by the team differs based on the Agile methodology being used. When using Scrum, the primary tool is the Product Backlog. In Feature Driven Development it is the Feature List. For DSDM it is the Prioritized Requirements List.

The key is finding a tool or mechanism that the team can use to determine what is really important to the customer when they say that everything is a requirement. A common technique already described in this course is the MoSCoW Prioritization



Page 175

Slide 183

Scheme where the acronym stands for Must Have, Should Have, Could Have and Would Like to Have, But Not At This Time. Other common techniques used in Agile Development include:

Monopoly Money — The team assembles a group of customers and gives each an equal amount of pretend money equal to the project budget. Customers are then asked to spend their money any way they want understanding that features will be prioritized based on those that have the most money. This is considered a relative prioritization technique.

100-Point Method — This technique is similar to Monopoly Money. However, instead of pretend money customers are give 100 points to spend any way they want. This is also a relative prioritization technique and different only in that the customer has exactly 100 points to spend. It can be combined with Monopoly Money by giving the customer exactly 100 pretend dollars to spend. Leffingwell and Widrig argue for the inclusion of the 100-Point Method when working with Use Cases.

Dot Voting / Multi-Voting — This technique is a simple modification of the previous two. Instead of pretend money the customer is given a set number of colored stickie dots. Each person is given an equal number of dots and the features are then listed on a board or poster. Customers get to place their dots on the features they desire and then all the features are ranked based on the number of dots awarded to each.

CARVER — This is an acronym that stands for Criticality, Accessibility, Return, Vulnerability, Effect, and Recognizability. Relative to the objective and/or mission of the project.

Criticality – How important is this to be done upfront?

Accessibility – Can work begin on it immediately? Or does work on this depend on other work/skills being completed first?

Return – ROI / NPV / IRR Vulnerability – How easy is it to achieve the desired results?

Effect – What are the effects on the project? Does it help to move towards the overall goal of the project?

Recognizability – Have the goals been clearly identified?

Kano Analysis — Perhaps the most important of these tools is a Kano Analysis. It represents a customer satisfaction and product development theory first developed in 1984, by Professor Noriaki Kano. It was originally designed to classify customer preferences into the following three categories:

Performance Needs – These requirements can both satisfy and dissatisfy customers. They are at the top of the customer’s list of concerns. Customers will talk about them readily when asked what is important. You must choose these correctly.



Page 176

Basic Needs – Having these requirements will NOT result in customer satisfaction, but NOT having them will result in dissatisfaction. Customers don’t give these items a thought unless they are absent. They are sometimes referred to as MUST HAVES.

Excitement Needs – Customers are delighted when these are delivered, but their absence doesn’t cause dissatisfaction. They are often called UNIQUE SELLING or VALUE PROPOSITIONS.

The three categories of customer preferences are used to graph customer satisfaction across a two axis graph. The Y, or vertical axis represents how satisfied the customer is because of the feature, while the X, or horizontal axis represents how well the feature fulfilled a customer need and/or was implemented.

Kano Analysis visually presents a significant issue for most teams. Professor Kano argued that as time passes, features that were once considered a innovation that delighted gradually become an expected basic need. This constantly pushes successful teams further to the graph’s right as they must continually deliver the next big feature or have their project judged a failure. Examples of this idea can be found all around us. In heavy manufacturing, you need look no further than the automotive industry. When was the last time you purchased a car without intermittent windshield wipers, power windows or locks? What about safety systems such as collision avoidance? Ten or fifteen years ago these were all either completely non-existent or only available on the most expensive cars. Next consider your cell phone. In the last ten years we have moved from monochrome screens on phones that have very little functionality beyond making calls to full fledged hand held digital devices with high definition color screens that are capable of showing movies and running the most advanced applications—including a voice activated personal assistant. Imagine where we will be in another decade as the features that make us oh and ah today become passé.

Requirements Prioritization Model — Each feature is rated by benefits for having, not having, cost of producing, risks, etc., and a score is calculated using a weighting formula predefined by the team. This method allows the team to value certain items as having greater importance by increasing their

Slide 184

Slide 185



Page 177

Slide 190

weighting in the formula. Commonly, the scores range from one to nine. This model was originally created by Karl Wiegers.

Relative Prioritization or Ranking — This is perhaps the most common and the easiest technique. It is simply an ordered list of all the User Stories or features to be completed with the first being the highest priority and the last being the lowest priority. When new features are added to the list, they must be compared in terms of their priority in comparison to all the features already on the list. The team can use any of the other techniques defined here to assist in this process, but the key is that they always focus on answering one question: Which items on the current list are more important than this one?

Before the team can go too far in prioritizing all the features to be delivered, they must first define the Minimally Marketable Features or MMF. This is a critical concept in Agile Development. It represents the minimal functionality set, a fancy way of saying a group of User Stories or a package of features that delivers the fewest number of features that someone would be willing to pay money to obtain. These represent distinct and deliverable features of the system that provide significant value to the customer (e.g. it can be sold and immediately used). These features are chosen for implementation after a value prioritization exercises and can instantly reap a return on investment.

Story Maps Story Maps present a visual way of seeing all the features in a project. It is typically read along two axes. Time is represented along the X-axis with columns often placed for releases or iterations on smaller projects. The Y-axis is used to represent how important the User Story is to the customer. At the top are the most important stories, referred to as the product backbone or the MMF. Below that



Page 178

appears the walking skeleton, and then you find more and more optional features. The key to remember when discussing a Story Map is that it maps all the User Stories and all the sprints or releases and shows the priorities and the expected sequence.

Risk Our next topic is project risk. So, what is risk? And what is so different about PMI’s view of project risks from what you are most likely used to? PMI® defines a risk as an uncertain event or condition that—if realized—has a positive or negative impact on at least one of the project’s objectives (such as time, cost, scope or quality). The big difference is that according to PMI®, risks include good things as well as bad. Risks are simply unknown events which might happen. The goal of Risk Management is to increase the probability and impact of positive risks and decrease the probability and impact of negative risks, while realizing that risks often have more than one cause and more than one impact. Project Risk Management is absolutely critical to a project’s success because it impacts every other knowledge area. Risks can occur anywhere at any time and successful Agilists know they must effectively manage the risks in order to deliver results.

The definition of a risk gets more complicated, however. Not only are there two types of risks, good and bad, but also there are two further categories within each of these. Risks are categorized as Known Unknowns and Unknown Unknowns. Are you confused yet? Don’t be. An unknown is just something that might happen. Its result could be good or bad. The real question is do you know it’s a possibility or not? If the possible future event is visible to you (i.e. you know at least that it might happen) we say that is a known unknown. If the risk is something which is not visible to you or you do not know about it, we say it is an unknown unknown. So what is the big deal about this distinction? Known unknowns can be planned for and can be the responsibility of the project manager. Unknown unknowns cannot be planned for and therefore they require management reserves or general contingency. Up to 90% of the risks on a project fall into the known unknown category and can be identified, investigated and planned for. Also remember the fundamental concept that negative risks are anti-value.

Before discussing the processes involved with the Risk Management Knowledge Area a few terms must be defined. They are as follows:

Risk Tolerance — Risk tolerance is the amount of risk a person or a group of people are willing to accept. It is the project manager’s responsibility to ensure that the project operates within the risk tolerance of the sponsor and the key stakeholders.

Risk Averse — Someone who is risk adverse has a low risk tolerance. A sponsor or key stakeholder who is risk adverse can significantly impact the delivery of a project by limiting the choices that the project manager and team may make to achieve the desired project results.

Risk Factors — Risk factors are drivers or descriptors of a project risk. The key risk factors are largely common sense and are listed on the next page.

Slide 191-192



Page 179

Slide 193-195

Probability and Impact — Probability defines how likely the risk is to occur. Impact defines the result of the risk. Typically, project risks are scored using a Probability and Impact (PI) Score which will be described later in this chapter.

The range of possible outcomes — Many risks have more than one possible outcome. Understanding that range can be an important element in successfully managing the project risk and delivering the project.

Expected timing in the project life-cycle — When a risks occurs it can have a significant impact on the overall success of the project. For example, many risks that occur early in the project are easier to overcome than those which occur late in the timeline.

If you are already a PMP® or have studied for the exam, many of these terms are familiar. That is because they are the same and have the same meaning when talking about Agile Development. Risk exists regardless of methodology used to execute the project. However, the way the team responds to those risks changes when using Agile. Here are some common types of specific project risks and how Agile differentiates itself from linear approaches to achieve its results.

Schedule Risks – In linear lifecycles it can be a long time before a product is ready for release. In Agile this is generally a shorter period of time, sometimes a few weeks. This serves to reduce project risk because the customer receives the most important features very early on in the process. As the project comes to its deadline, the team is typically working to deliver far less important features that in many cases could be excluded if required without impacting business value. This places the customer in a position to decide whether or not they want the desired features without loosing any critical value.

Budget Risks – Agile estimates are no more accurate than others, but their inaccuracy is easier to manage. Agile Development argues that project estimating is an inexact science at best. Even the most experienced project resources and leaders can only hope for the accuracy of their estimates within a range. Yet, most projects are driven from exacting estimates and end with frustrated customers. Agilists never claim to do a better job at estimating. Instead, they claim that work in smaller chunks are easier to estimate and show smaller variances. thus making the impact of those variances also smaller, and thereby allowing the team the ability to recover more quickly and deliver business value.

Cancellation Risk – Linear methodology projects tend to be cancelled late. This occurs because Waterfall projects work from a Big Bang Theory. This is when all the value and functionality is delivered only at the very end of the project. All the features are bundled together. This means all the critical features are tied to the unimportant ones. The team is given no time to evolve and learn as they go through the project, since reflection only happens at the very end. This helps them on the next project but does little to ensure success on the current one. Because of this, the sponsors and customers of Waterfall projects also do not get a chance to learn and adjust the project as the go along. It can therefor be late in the cycle when lots of things have changed and when



Page 180

they now have a product that no longer fits with where the organization is going or one that significantly under delivers due to the change in climate. In these cases, the best choice is often to cancel the project. Agile projects are also occasionally cancelled, but cancellation happens earlier in the process. This is because the team is able to produce the most important features early and show these results to the customer. When they fail to meet the business need, or when the strategy of the organization changes, everyone is much quicker to recognize it, and can simply cancel the project at the end of a sprint.

Scope Creep – In a predictive lifecycle, a project’s scope can be increased without anything being removed. The backlog forces hard decisions. The issue of Scope Creep is one of much debate between linear method proponents and those supporting Agile. According to proponents of Waterfall development (Yes, there are still many out there.) Waterfall has an advantage in the prevention of Scope Creep by defining all the scope of the project up front during the Analysis and Design phases. They then argue that this allows the Waterfall project to “lock down” the project’s scope and prevent scope creep, or the never ending adding of scope to a project without regard to cost and schedule implications. The supporters of Waterfall Development further contend that this is better than Agile because Agile Development projects often struggle because the customer is allowed to constantly add requirements to the project’s scope. This, they argue, is what leads most Agile projects to overrun both their schedule and budget. The Agilist argues that this situation is an illusion. They counter that Waterfall projects rarely succeed in locking down the scope. What usually happens is that the team faces the same challenges that an Agile project faces whenever more and better information is discovered about the needs of the business. The difference, Agilists contend, is that Waterfall is specifically designed to resist change, whereas Agile Development is designed to harness that change and therefore create a better product for the customer. The use of Agile Development changes the fundamental dynamic of scope management by making the customer prioritize the features and constantly re-evaluate what is in and out.

Requirements Error – Linear projects specify requirements long before they are delivered. An incorrect requirement can generate significant effort before the error is discovered. By working in short iterations, and by requiring the team to deliver a working product that is fully tested at the end of every iteration, the team is far more likely to catch these errors when the are small and there has been little investment in their creation. This means it is easier for the team and customer to change when they are required to based on new information. And, lots of little changes can have a big impact over time.

Technology Risks – Many projects require unproven technologies. Predictive methodologies extends the time it takes to discover failed technology. In contrast, Agile allows for rapid discovery. Agile Development works in short iterations allowing for reflection. This allows the team and the customer to examine the results of each iteration. This is especially important when working with a new technology. It allows the team to learn about the new technology and to share that information within the team and with the



Page 181

Slide 196

customer. This allows the team to quickly learn about the technology and adapt as needed, thereby reducing the overall risk to the project.

Security Risks – Waterfall projects often take significant time before system security can be tested. Agile projects, on the other hand, test security quickly, often and at regular intervals. Remember, every iteration is required to produce fully tested, working product. This includes the product’s security. Because the product is tested at every iteration, problems with security are discovered early and can be fixed when they are small and before they critically damage the project.

PDCA If you are a student of project management and the myriad of methodologies used to deliver business results, you have likely noticed that most development methodologies are either four or five steps. Why the consistency? It is because all development methodologies find their roots in Dr. Edward Deming’s PDCA Cycle. Although Deming always referred to it as the “Shewhart Cycle.” The original Shewhart Cycle was called the Shewhart Learning and Improvement Cycle. It combined the disciplines of management thinking and statistical analysis. By constantly evaluating management policies and procedures the team is able to make continuous improvements. Deming marketed this cycle to the masses and although he always gave credit to his colleague Walter Shewhart, it quickly came to bear his name. The cycle is used to make changes that lead to continuous quality improvement. This is a never ending process. After the easy low cost changes are made (after the low hanging fruit is harvested), the cycle process is repeated for another step, task, or process in the microsystem or system. After a period of time, other changes may result in the original process having an opportunity for improvement again.

Shewhart published numerous articles (many of which were in the Bell System Technical Journal) and two books: “Economic Control of Quality of Manufactured Product” in 1931 and “Statistical Method from the Viewpoint of Quality Control” in 1939 (reprinted in 1986). He was also the first editor of the John Wiley and Sons “Mathematical Statistics Series,” and he continued to serve in this capacity for more than 20 years. Shewhart served as a consultant in the War Department during World War II and the resultant American War Standards helped in the productivity efforts.

The process is made up of four stages Plan, Do, Check and Act.



Page 182

Plan — Establish the objectives and the processes necessary to deliver results in accordance with the expected output (the target or goals). When possible, start on a small scale to test possible effects. The completeness and accuracy of the output expectations will also be part of the targeted improvement.

Do — Implement the plan, execute the process, and make the product. Collect data for charting and analysis in the following "CHECK" and "ACT" steps.

Check — Study the actual results (measured and collected in "DO" above) and compare against the expected results (targets or goals from the "PLAN"). Look for deviation in the implementation of the plan. Also look for the appropriateness and completeness of the plan to enable the execution, i.e., "Do." Charting data can make it much easier to see trends over several PDCA cycles and to convert the collected data into information. Information is what you need for the next step, "ACT."

Act — If the CHECK shows that the PLAN that was implemented in DO is an improvement to the prior standard (baseline), then that becomes the new standard (baseline) for how the organization should ACT going forward (new standards are enACTed). If the CHECK shows that the PLAN that was implemented in DO is not an improvement, then the existing standard (baseline) will remain in place. In either case, if the CHECK showed something different than expected (whether better or worse), then there is some more learning to be done. That suggests the potential for future PDCA cycles. Note that some who teach PDCA assert that the ACT involves making adjustments or corrective actions. Generally, however, it would be counter to PDCA thinking to propose and decide upon alternative changes without using a proper PLAN phase, or to make them the new standard (baseline) without going through DO and CHECK steps.

Expected Monetary Value & Decision Trees Expected Monetary Value (EMV) is a modeling technique to forecast future events that are uncertain based upon probabilities. EMV is often associated with Decision Trees which provide a visual representation of the probabilities for the purpose of decision making. To better understand EMV let’s examine a simple scenario. Imagine you have a project that, based upon your subject matter expert’s judgment, has a pessimistic cost of $300,000, a likely cost of $225,000, and an optimistic cost of $150,000. Your subject matter expert also informs you that they believe the project has a 30% chance of achieving the pessimistic result, a 50% chance of achieving the likely cost, and a 20% chance of achieving the optimistic cost result. How must should you plan on the project costing? The answer is $232,500 as the table shows. But, how did we come up with that answer?

First, the probabilities for a series of mutually exclusive options must

Cost Probability Product

Optimistic Outcome $150,000 .20 $30,000

Likely Outcome $225,000 .50 $112,000

Pessimistic Outcome $300,000 .30 $90,000

$232,500

Slide 197



Page 183

Slide 198

sum to 100%. What does this mean? In our example, it is impossible to have both the optimistic and pessimistic options at the same time. It is a case of one or the other, and if you add the probabilities you will see they sum to 100%. To illustrate further, imagine having three tasks on a project (A, B, and C). A has a 36% chance of costing X. B has a 49% chance of costing Y, and C has a 68% chance of costing Z. Why don’t the percentages sum to 100%? The answer is that A, B, and C are not mutually exclusive options. You have to do all three tasks on the project. To calculate the EMV for each row, simply multiply the variable (in this case cost) by the probability to achieve the product column, and then add the results together. This provides the cumulative result. This basic model can be extended into a graphical representation using Decision Trees.

Decision Trees provide a visual methodology to calculate outcomes that involve a chance event. They show the implications of each of the available choices and incorporate cost, probability, and results. Imagine that you are part of a project and have a choice to make. In the choice you can either be conservative or aggressive, but regardless of your decision there is some chance event which might impact the project. The above image shows this simple example. If you choose to be aggressive and the chance event happens there is a 60% chance you will profit significantly from the decision and make $250,000. However, if you are aggressive and the chance event happens there is also a 40% chance you will loose $100,000. Alternatively, if you choose to be conservative and the chance event happens there is an 80% chance you will gain $20,000 and a 20% chance you will loose $45,000. What should you do? The answer is found by calculating the expected monetary value exactly as before. The only difference here is the fact that you have two trees, or sets of options that each sum to 100%. Notice how the two branches within the aggressive choice sum to 100% and the two options within the conservative choice also sum to 100%. Each branch is complete. Therefore, you must multiply the rows as before but only add the results within each choice. This causes you to get a result of $110,000 for the aggressive choice and $71,000 for the conservative choice making the aggressive choice the preferred option by $29,000.

The concept of Decision Trees can be extended one step further by including the costs of the initiative as when examining a build-versus-buy decision.

Imagine you have been asked to lead a project to give your organization a new

Chance Event

Chance Event

Choice Event

60%

40%

20%

80%

$250K

-$100K

-$45K

100K

$150K

-$40K

-$9K

$80K

Probability Outcome EMV

Conservative EMV = $71,000

Aggressive EMV = $110,000



Page 184

capability. To deliver the project you must either build a new software application or buy an existing one. If you build the application internally it is significantly more likely to meet the organization’s needs. If you buy an Off-The-Shelf (OTS) package it will cost less. No matter what decision you make there is a chance people will love it and there is a chance people will hate it. What do you do?

A great way to solve this problem is to use Decision Tree Modeling in conjunction with Expected Monetary Value. Examine the image on the this page to see a scenario using these techniques. The image is broken into columns. The first column is the pre-decision point and should be ignored. Column A shows the costs of the two choices. Because they are expenses, or outflows of capital for the organization, the values are both negative ($-250K and $-350K). Column B shows the probability of getting the outcome should the choice (either OTS or Develop) be made and the result, or payout, from making that choice. Column C shows the net outcome which is the outcome from column B minus the cost of making that choice (Column A). Column D takes the net outcome from Column C and multiplies it by the probability to have that outcome found in Column B. The final outcome for each choice is derived by summing the two possible outcomes for each branch. In Image 100, the best choice is the OTS Option because it has a payout of $72.5K versus the Develop Option which only has a value of $66K.

Agile Development manages risk by integrating risk items into the product backlog. This is accomplished by combining Expected Monetary Value with the Backlog. Begin by calculating the EMV for each prioritized risk item. Then resort the risks by the EMV. Finally, insert the risks into the Backlog treating them as another Product Backlog Item with all the items prioritized by cost.

OTS or Develop

OTS $72.5K

Develop $66K

OTS

Develop

-$250K

-$350K

Well Received

Well Received

Well Received

Well Received

$195K

-$123K

$128K

-$61.5K

65% $550K

35% -$100K

85% $500K

15% -$60K

$300K

-$350K

$150K

-$410K

A. Cost of Choice

B. Probability &

Outcome

C. Outcome Minus Cost

E. Final Result

D. Net (C) Times

Probability

Slide 199



Page 185

Exercise 5 — EMV

Expected Monetary Value

You have been asked to establish an estimated project cost using Expected Monetary Value (EMV). If the project has a best case estimate of $10,000 with a probability of 20%, a most likely case estimate of $12,000 with a probability of 50%, and a worst case estimate of $14,400 with a probability of 30% what is the EMV for the project?

A. $12,320 B. $12,400 C. $13,010 D. $13,260

2. You have been asked to establish an estimated project cost using Expected Monetary Value (EMV). If the project has a best case estimate of $15,000 with a probability of 30%, a most likely case estimate of $19,500 with a probability of 50%, and a worst case estimate of $26,325 with a probability of 20% what is the EMV for the project?

A. $19.190 B. $19,515 C. $20,110 D. $20,350


A. $30.190 B. $31,560 C. $32,219 D. $33,350


A. $55,975 B. $56,550 C. $57,125 D. $57,875


A. $86.756 B. $87,247 C. $87,691 D. $88,121


A. $35,121 B. $35,628 C. $36,222 D. $36,92



Page 186


A. $41,652 B. $42,111 C. $42,984 D. $43,596


A. $23,950 B. $24,220 C. $24,880 D. $25,200


A. $6,161 B. $6,437 C. $6,918 D. $7,020


A. $8,919 B. $9,126 C. $9,415 D. $9,783

11. You are asked to choose between two projects, A or B, based on the highest gain (or the lowest loss). Project A will cost $650,000 and B will cost $467,000. There is a 56% chance that project A will be successful, which will result in a gain of $1,800,000. If project A fails there will be a loss of $900,000. There is a 67% chance project B will be successful, and that will result in a $950,000 gain. If Project B fails there will be a loss of $670,000. Based on this information, what is the value of the best alternative?

A. $-38,000 B. $38,000 C. $-51,600 D. $51,600

12. You are asked to choose between two projects, A or B, based on the highest gain (or the lowest

loss). Project A will cost $300,000 and B will cost $255,000. There is a 67% chance that project A will be successful, which will result in a gain of $650,000. If project A fails there will be a loss of $310,000. There is a 58% chance project B will be successful, and that will result in a $650,000 gain. If Project B fails there will be a loss of $225,000. Based on this information, what is the value of the best alternative?

A. $60,700 B. $27,500 C. $33,200 D. $51,600



Page 187

13. You are asked to choose between two projects, A or B, based on the highest gain (or the lowest loss). Project A will cost $288,000 and B will cost $225,500. There is a 61% chance that project A will be successful, which will result in a gain of $650,000. If project A fails there will be a loss of $287,000. There is a 57% chance project B will be successful, and that will result in a $560,000 gain. If Project B fails there will be a loss of $225,000. Based on this information, what is the value of the best alternative?

A. $6,480 B. $-3,050 C. $3,200 D. $-3,430

14. You are asked to choose between two projects, A or B, based on the highest gain (or the lowest loss). Project A will cost $663,500 and B will cost $589,000. There is a 66% chance that project A will be successful, which will result in a gain of $1,399,000. If project A fails there will be a loss of $663,500. There is a 69% chance project B will be successful, and that will result in a $1,005,000 gain. If Project B fails there will be a loss of $225,000. Based on this information, what is the value of the best alternative?

A. $34,250 B. $34,700 C. $68,950 D. $68,525


A. $320,895 B. $618,395 C. $297,500 D. $648,716


A. $5,500 B. $15,600 C. $10,550 D. $21,525


A. $703,200 B. $425,230 C. $277,970 D. $256,990



Page 188


A. $79,788 B. $29,788 C. $27,970 D. $50,000


A. $14,390 B. $19,780 C. $25,620 D. $40,010


A. $7,300 B. $8,075 C. $11,650 D. $15,375

21. You are asked to choose between two projects, A or B, based on the highest gain (or the lowest loss). Project A will cost $500 and B will cost $750. There is a 65% chance that project A will be successful, which will result in a gain of $2,500. If project A fails there will be a loss of $1,650. There is a 59% chance project B will be successful, and that will result in a $3,000 gain. If Project B fails there will be a loss of $1,750. Based on this information, what is the value of the best alternative?

A. $303 B. $548 C. $641 D. $850


A. $115,960 B. $119,300 C. $123,930 D. $243,230

Expected Monetary Value and Decision Tree Answers 1: A; 2: B; 3: C; 4: D; 5: A; 6: B; 7: C; 8: D; 9: A; 10: C; 11: A; 12: C; 13: B; 14: B; 15: A; 16: C; 17: B; 18: D; 19: C; 20: B; 21: B; 22: C



Page 189

Slide 203

Slide 204

Slide 205

Slide 206-207

Agile Contracting

One of the greatest areas of frustration for most Agilists occurs when they have to deal with contracts. Traditional contracts simply don’t work in Agile Development. The reason is that traditional contracting attempts to fix scope and cost. Buyers want to know exactly what they are paying for and exactly what it will cost to produce. This is a very reasonable expectation if we are talking about some kind of commodity. But the products of software projects are not commodities. This simple fact means that the contracting method used on most projects—a contracting type called Firm Fixed Price—leads to significant problems for the teams and to disappointments for the customer. Because of the contract, the team must resist changes to scope and delivery and stick to exactly what is stated in the agreement. As new information appears that impacts these requirements, the team is prevented from responding to the change even when it means there is no dramatic increase to cost and schedule. Agile Development takes a different tact when it comes to contracting. Agile Contracting fixes the time and cost legs of the triangle while leaving the scope side flexible. Agile Development then requires the prioritization of the features and allows the customer to make decisions about the scope. This inversion of the triangle priorities ensures that the customer has greater control of the product, at least theoretically. Accomplishing this requires much greater communication between the customer and team to prevent surprises.

The various Agile Methodologies take different approaches to contracting. The Dynamic Systems Development Method focuses on making sure that the product or service of the project is fit for the business purpose, and in passing its tests rather than matching specifications.

Jeff Sutherland, one of the originators of Scrum uses the phase, “money for nothing and change for free” to describe his notion of Agile Contracting. In this notion, the customer is allowed to terminate the project early and has the flexibility to make changes. Sutherland’s idea uses a standard Firm Fixed Price Contract, but adds time and materials for additional work, plus a “change for free” clause. The customer works with the team on every iteration using the Scrum process—this means daily.

Another Agile contract concept, originally created by Thorup and Jensen, is the Graduated Fixed Price Contract. In this type of Agile Contract both parties accept some of the risk. It uses an hourly rate calculation for the project work. The basic idea is that this creates incentives for performing. The team gets to charge more per hour the earlier they deliver the work. Imagine a simple agreement where the customer agrees to pay the performing organization $200 an hour if they deliver the full product early, $180 an hour if they deliver on time, and $160 an hour if they deliver late. This type of schedule dramatically increases the profit margin for early delivery and reduces it for late performance.

Another Agile Contracting concept is the Fixed Price Work Package. In this model, the features or work of the project is estimated at the PBI or feature level and the customer pays by the feature delivered. The seller is allowed to



Page 190

re-estimate any remaining work packages or PBIs on the Backlog as the project progresses. This model allows the customer to focus on obtaining the greatest value by constantly reprioritizing the Backlog as the team works.

Odds and Ends of Value-Driven Delivery

Many students of Agile Development spend so much time getting caught up in the “us versus them” of agile development versus traditional project management argument that they lose sight of a number of key questions. One of those questions is why don’t Agile Methods make use of tools like Gantt Charts or Microsoft Project? The truth is that the traditional tools for project management can be used in Agile Development, but with care. Most Agile authors recommend staying away from them, however, because they create some natural barriers to success. First, many of these tools provide exact answers, like a specific number or value. This creates the perception of a level of data accuracy that simply does not exist. These tools can also make customers believe they do not need to interact with the team because the think they are “involved” in the project via some tool. A key element of Agile Development is the involvement of the customer with the team. No tool can take the place of real engagement.

Our next concepts center on something called Little’s Law. To understand Little’s Law, it is important that you understand the definition of Cycle Time. Cycle Time represents how long the customer must wait before receiving any benefit from the features created. Little’s Law states that Cycle Time is proportional to the size of the queue, or how much Work in Progress the team has. This concept is displayed using a Cumulative Flow Chart. The CFC is a two-line chart where the X-axis is used to represent time. The Y-Axis represents a count of project features. The team plots two lines on this chart. The first line represents features that have started. The second line represents PBIs or features that have finished. Each feature appears once in each line horizontally apart from each other. The distance between each occurrence on the horizontal (X) axis represents the amount of time between when a feature is started and when it is completed. This is called the Cycle Time. Drawing a straight line vertically represents the amount of work in progress at a specific point in time. The objective of every team is to have these two lines as close together as possible. Such a line would represents a project in which takes very little time to complete each feature and which never has many PBIs in progress at any single point.

Another key tool of Value-Driven Delivery is the demonstration. A demonstration is where the team displays the features they have built to the customer, to display the new capability. Demonstrations are critical to confirming successful delivery of the various features. It is where the team learns about the differences between what the customer asked for, how the team interpreted that request, and what was built. It also allows the customer to compare the difference between what they

Cycle Time

WIP

Slide 208

Slide 209

Slide 210



Page 191

said and what they intended. The process of demonstrations provides an opportunity for the customer and team to define new functionality and adjust existing features to better meet the business need.

Finally, we have the acronym IKIWISI. It stands for an old truism from many customers. It means I’ll Know It When I See It, and points to the common problem many development teams face. Sometimes the customer doesn’t know or fully understand what they want in terms of the features of the product until they see it. Only by touching and using a product can they understand its characteristics and fully understand how they would use it. In these situations, Agile has a decided advantage over traditional methods of managing a project because of the use of short iterations that allow the team to regularly present work to the customer for review and discussion.

Earned Value Management (EVM)

As was previously stated, the primary focus of the control costs process is Earned Value Management (EVM). For many PMI-ACP® candidates, Earned Value is the most difficult concept to master. It also seems very out of place. After all, many argue, isn’t Earned Value a technique used by the most structured, process driven, linear projects? The answer is that Earned Value IS a technique created by the most linear, traditional organizations. EVMS has its roots in industrial manufacturing at the turn of the 20th century, based largely on the principle of "earned time" popularized by Frank and Lillian Gilbreth. Eventually, it took root in the United States Department of Defense (DoD) in the 1960s. The original concept was called PERT/COST, but it was considered overly burdensome (and therefore not very adaptable) by contractors who were mandated to use it. Because of this, many variations of it began to proliferate among DoD procurement programs. In 1967, the DoD established a criterion-based approach, using a set of 35 criteria, called the Cost/Schedule Control Systems Criteria (C/SCSC). In the 1970s and early 1980s, a subculture of C/SCSC analysis grew, but the technique was often ignored or was even actively resisted by project managers in both government and industry. C/SCSC was often considered a financial control tool that could be delegated to analytical specialists. In 1979, EVM was introduced to the architecture and engineering industry in a Public Works Magazine article by David Burstein, a project manager with a national engineering firm. This technique has been taught ever since as part of the project management training program presented by PSMJ Resources, an international training and consulting firm that specializes in the engineering and architecture industry.

To pass the exam, you must know all the equations of EVM, as well as understand the reasoning behind when and where to use the calculations. To better comprehend EVM, let’s first take a step back.

Many basic project management courses teach the importance of the triple constraints in project management. These constraints are time, costs, and scope/quality. It is often said that project management is largely about managing the trade-offs between these three. However, the concept of a series of trade-offs creates a significant problem. How does a project manager evaluate the trade-offs



Page 192

between time and costs, or between time and scope, or between scope and costs? If you are like many project managers, the answer is easy, you simply ask your stakeholders right? Wrong! If you ask your stakeholders to provide the analysis of the trade-offs you are trapped into using highly subjective measures and will fail every time. A key goal of successful project management is finding quantifiable, objective measures of success and progress. Do you see the trap yet? Let’s take a look at a simple example to make it more clear. What is the most common measure of time? Hours, days, weeks or months, right? What is the most common measure of cost? Dollars, or whatever is your national currency. Finally, how do you measure scope/quality? Be careful because this question often tricks people who go too quickly. The primary measure of scope/quality is deliverables or features. Now bring these three together. How would you evaluate the trade-off between two weeks, five features and $10,000? Remember, the correct answer is not ask your stakeholders. The correct answer is: You can’t! Each person you ask would likely give you a different answer. This simple example brings us to Earned Value Management.

At its heart, Earned Value Management is all about providing a quantitative, objective method to measure the performance of variables which are naturally disparate so that the trade-offs can be easily understood. Earned Value has become increasingly popular because it focuses on using this information to provide future predictability and can be very accurate even early in a project. Successfully learning Earned Value Management requires that you to focus on the three variables that form the triangle: time, cost and scope/quality. EVM uses different terms for these variables, however, so don’t get confused. Remember to stay focused on what the variables really are.

To explain Earned Value and its calculations more fully, we will use a chart and a table. We begin with a slightly more sophisticated version of the cost baseline examined previously in this chapter. The image below shows the Cumulative

Slide 211



Page 193

Cost Curve. The first thing you may notice is the large number of acronyms. Do not worry. With a little practice these will become second nature. The horizontal axis of the chart represents time as a continuum. The vertical axis represents the cumulative dollars for the project. Notice that there is also a vertical bar showing where the project is currently. Below the other acronyms are defined.

BAC — The Budget At Completion. This is the total budget for the project. It is the single number used to answer the question how much money was this project supposed to cost in total?

Remaining Work — This is exactly what it sounds like it is. It represents the work than is still left to be accomplished. It is calculated with the formula BAC-EV.

ETC — The Estimate To Complete. This is the number that answers the question how much MORE money do we think the project is really going to cost. There are several different calculations that may be used to calculate ETC.

Critical Ratio — The Critical Ratio is the CPI * SPI. It provides a quick, single number review of project performance.

PV — The Planned Value is the first of the three major variables. It represents the time side of the triangle in the triple constraints. The transition from days to dollars is made through the budget. A key aspect of any budget is when the money is spent. We can therefore argue that the $1,000 that was planned to be spent in a given week is equal to that week. This allows us to now go through the analysis using the $1,000 instead of always referring back to the one week. The Planned Value provides the baseline against which all comparisons are made. In a perfectly run project both the AC and EV lines appear exactly on top of the PV line. Also notice that the BAC is at the end of the PV line at a point where it has flattened out. This flattening occurs because the project reached its total budget without being completed so time continues but the PV line remains flat. The PV is another way of saying the cost baseline or budget. It also can be used to represent the amount of work to be completed in any period.

AC — The Actual Costs is the easiest of the Earned Value variables. It represent the actual money spent on the project.

EV — The Earned Value is often the most difficult variable for exam candidates to learn. However, it is also the most important of the three major variables (AC, EV and PV) because all the major calculations begin with the Earned Value. The Earned Value represents the scope side of the triple constraints. It is the amount of work product that has been produced by the project. The trick is converting work into dollars, but the major requirement to accomplishing this feat has already been achieved. The key element to reporting progress using Earned Value is that progress must be reported at the work package level of the WBS. Once the initial budget for a work package is established, so is its value because they are the same thing. If you planned on



Page 194

spending $1,000 in total on a work package then the work package is worth $1,000. If you are 50% done with the work package you have earned $500 in value. Finally, a work package can NEVER be worth more than you planned on it costing to produce.

EAC — The Estimate at Completion is one of three forecasts that is calculated using the three base variables (AC, EV and PV). It answers the question how much in TOTAL are we now expecting the project to cost. It includes an estimate of the remaining work costs (ETC) and the already accrued actual costs.

The discipline of Earned Value is rooted in four calculations which are found in in the calculations bulleted below. Beneath the bulleted equations is the image of a table that is the most powerful tool I know of to learn Earned Value. Begin by noticing that the three major Earned Value variables discussed above (AC, EV and PV) appear at the top of the graphic in alphabetical order. All of the calculations begin in the middle with the Earned Value (the name of the technique) and work outward. On the far left are two variables that begin with the letter C. These variables measure cost performance. On the far right side are two variables which begin with the letter S. These measure schedule performance. The two letter calculations (CV and SV) are variances which show the actual over or under performance in currency terms. The three letter calculations (CPI and SPI) are performance indexes which measure the variances as a percentage. As you will see, the Performance Indexes are usually more valuable than the variances. The four basic Earned Value equations defined are:

CV = EV — AC

CPI = EV / AC

SV = EV — PV

SPI = EV / PV

To read these calculations, an exam candidate only needs to remember a few simple rules. These rules are:

Slide 212



Page 195

Slide 213

If it is a two letter abbreviation, the target is zero.

CV or SV > 0 is under budget

CV or SV = 0 is right on budget

CV or SV < 0 is over budget

If it is a three letter abbreviation, the target is one.

CPI or SPI > 1 is under budget

CPI or SPI = 1 is right on budget

CPI or SPI < 1 is over budget

Let’s take a more detailed look at these rules to better understand how they work. If the project has a Cost Variance of -$12,345, this is bad because it is less than zero. It indicates to the project manager they are over budget. A CV of zero means the project is right on budget. A CV of greater than zero means the project is under budget by the value of the CV. Replace the Cost Variance with the Schedule Variance (SV) and the statements still hold true. A Schedule Variance less than zero means the project is behind schedule, a value of exactly zero means the project is on schedule, and a schedule variance greater than zero means the project is ahead of schedule.

The CPI and the SPI are usually more valuable to the project manager, and are read using a target value of one because any number divided by itself equals one. The CPI, or Cost Performance Index is calculated by taking the Earned Value and dividing it by the Actual Costs. If a value of one is the result, the project is exactly on budget. If the value is greater than one the project is under budget. If the result is less than one the project is over budget. In the case of both indexes, the proximity to one has great significance because the one is synonymous with 100%. Hence, a CPI of .91 means the project is 9% over budget (100% - 91% = 9%). Likewise, a CPI of 1.06 means the project is 6% under budget. The same logic works for the Schedule Performance Index. An SPI of .88 means the project is 12% behind schedule. An SPI of 1.04 means the project is 4% ahead of schedule. Both of these statistics are incredibly useful in telling the project manager where the project is right now. However, neither tells the PM how the project is going to end. To provide that information, the PM must turn to the Earned Value forecasting measures.

Earned Value Forecasting

There are three primary forecast values that a project manager might need to calculate on any project—and with each value there are multiple methods to obtain an answer. For the certification exam it is very important that you understand each of these methods and know when each should be used.

ETC — Estimate to Complete answers the question how much MORE money is the project going to take to complete. There are four methods which may be used to calculate ETC. Each method is based upon a different assumption. These include:



Page 196

ETC based on new estimate — There is no formula if the Estimate to Complete is being based upon an entirely new estimate. The project manager and the team simply develop a new estimate. This method is used whenever the original estimate is believed to be flawed beyond recovery. This method is not often found on the exam (beyond the term and explanation) because it is impossible to develop a mathematical question when the new estimate is developed by an external process.

ETC based on atypical variances — Atypical variances means the variances are not commonly occurring. For the project manager, it means whatever caused the variances is not expected to continue, and future forecasts can be based on whatever the original budget was. The formula for an ETC with atypical variances is ETC = BAC-EV. If you examine the definitions provided a few pages earlier, you will notice this is the same equation to define the remaining work. It is a fancy way of saying you will produce the remaining work for exactly what you said it would cost. This equation might be on the exam, but it is not likely. Watch for the phase “atypical variances” on the exam to clue you in.

ETC based on typical variances — An Estimate to Complete based upon typical variances is the most common ETC seen on the exam. It assumes that whatever has been the rate of progress will continue in the future. In most cases it means that whatever has been causing you problems will keep causing you problems. The formula to calculate the ETC using typical variances is ETC = (BAC-EV)/CPI. Notice that this equation also makes use of the mathematical expression for the remaining work (BAC-EV), but that it has been factored by the actual performance rate.

ETC based on both the CPI & SPI — The final method for calculating the Estimate to Complete makes use of both the Cost Performance Index and the Schedule Performance Index. This method assumes both a negative cost performance to-date and requirement to hit a specific target date. This method is most commonly used when the project schedule is a driving force impacting the ETC. The formula to calculate the ETC using both the CPI and SPI is ETC = (BAC-EV)/(CPI*SPI). This formula makes use of the mathematical expression for remaining work (BAC-EV) and the Critical Ratio (CPI*SPI).

The next set of calculations used the same four ETC calculations’ underlying assumptions and simply adds the actual costs-to-date to them and thereby creates the Estimate At Completion or EAC. The EAC answers the question how much in TOTAL will the project cost. The calculations for EAC are:

EAC using a new estimate — As with the ETC, this calculation is unlikely to be on the exam past a definitional question, because it is impossible to develop a mathematical question when the formula is based outside the question parameters. The formula for the EAC when an entirely new ETC is developed is EAC = AC + ETC.

EAC assuming atypical variances — The second possible calculation for Estimate at Completion takes the remaining current budget and adds it to the

Slide 214



Page 197

Slide 215

TCPI Formulas

Schedule Formulas

actual costs to-date. It assumes that whatever has been causing problems on the project will not continue to do so in the future. As with the ETC, this method assumes atypical variances. The formula for the atypical variance EAC is EAC = AC + (BAC-EV).

EAC Assuming typical variances — The EAC method that assumes typical variances makes use of the Cost Performance Index (CPI) to factor the remaining work based on actual project cost performance, and then adds the costs to date. It assumes the rate of cost performance achieved to date will remain consistent in the future. The formula for EAC assuming typical variances is EAC = AC + ((BAC-EV)/CPI).

EAC using both CPI & SPI — The EAC using the Critical Ratio (CPI*SPI) makes the same assumption as the ETC using the Critical Ratio—that it is critical to hit a specific schedule target that has been previously defined. The formula for the EAC using the Critical Ratio is EAC = AC + ((BAC-EV)/(CPI*SPI)).

The final cost forecast calculation you must learn for the ACP® exam is the To-Complete Performance Index or TCPI. The TCPI is a calculated projection of the cost performance which must be achieved on the remaining work to hit a desired target. In the simplest terms, the TCPI is the remaining work divided by the remaining funds. Typically, the EAC target is either the BAC or a new EAC. The TCPI is often used when the original budget is recognized as unrealistic and a new EAC is developed. The formula for the TCPI when the goal is to hit the original budget is:

(BAC-EV) / (BAC-AC)

If the goal is to achieve a new target based upon a specified EAC the formula for TCPI is:

TCPI = (BAC - EV) / (EAC - AC)

In addition to the Earned Value Management calculations specified (which target project costs) Earned Value provides calculations that address forecasting the project schedule. In the PMBOK® Guide these calculations are discussed in the Time Management Knowledge Area, but we list them here to consolidate all the Earned Value discussion to a single location. The two equations used to forecast schedule in Earned Value Management are:

Schedule Est. = Original Project Duration / SPI (This is often used as a minimum schedule estimate)

Schedule Est. = Original Project Duration / (CPI * SPI) (This is often used as the maximum schedule estimate to allow for a range)

The last calculation and definition you must know for the exam is Variance at Completion or VAC. VAC is defined as how much over or under budget the project will be at the end. The formula used to calculate VAC is:

BAC—EAC



Page 198

The early Agile writing argued that it was impossible—and in fact undesirable—to use Earned Value as a reporting and tracking tool with Agile projects. However, more recent writings have revisited this topics and have consistently proven that not only is it possible to use EVMS and Agile together, but it also presents a valuable combination in many cases.

There are only a few things required to use Earned Value. Most importantly, the project must be broken into work packages against which the project can be tracked. Work Packages represent discrete pieces of functionality or features that are largely independent from the others. In other words they can be thought of as User Stories or PBIs on the Product Backlog. As soon as you realize that PBIs and Work Packages can be the same thing, a number of problems are solved. Now the team can use a Work Breakdown Structure or WBS to visualize the project— although in Agile this is called a Feature Breakdown Structure because of the many biases that. Each of the packages must have an estimate assigned to it, and the team must track how much time is spent working on it. All of these requirements are easily accomplished within an Agile environment. Therefore, Earned Value can be used with Agile.

Here are some other resources you can review to gain a better understanding of using Earned Value in an Agile Environment:

http://www.methodsandtools.com/archive/archive.php?id=61

https://www.solutionsiq.com/docs/earned-value-analysis-in-scrum-projects-wp.pdf

http://www.agilekiwi.com/EarnedValueForAgileProjects.pdf

https://fcw.com/articles/2011/01/17/home-page-tech-briefing-agile-evm.aspx?sc_lang=en



Page 199

Exercise 6 —Earned Value

Earned Value

1. Which of the following represents the budgeted cost for the work scheduled?

A. Actual cost B. Planned value C. Earned value D. Estimate at completion

2. Which of the following represents the budgeted amount for the work completed?

A. Planned value B. Actual costs C. Estimate to completion D. Earned value

3. Which of the following represents the total cost incurred in accomplishing work on the scheduled activity during a specific time period?

A. Actual costs B. Summary costs C. Earned value D. Planned value

4. Which of the following variables represents the amount of additional money that needs to be spent to complete the project?

A. EAC B. ETC C. CPI D. SPI

5. Which of the following variables represents the total amount of money that is estimated to be spent when the project is completed?

A. ETC B. CPI C. EAC D. SPI

6. Which of the following variables represents the formula: Earned Value minus Actual Costs?

A. CV B. CPI C. SV D. SPI



Page 200

7. Which of the following variables represents the formula: Earned Value minus Planned Value?

A. SPI B. CV C. CPI D. SV

8. Which of the following variables represents the formula: Earned Value divided by Actual Costs?

A. CV B. SPI C. SV D. CPI

9. Which of the following variables is represented by the formula: Earned Value divided by the Planned Value?

A. SPI B. SV C. CPI D. CV

10. Which of the following is used to forecast project costs at completion?

A. CPI B. SPI C. Cumulative CPI D. Cumulative SPI

11. Which of the following is used to display earned value data over time?

A. A Gantt chart B. An S-curve C. An EV table D. A cost and schedule baseline chart

12. Your boss enters your office and asks for the cost variance on your project that has an AC of $225, a PV of $200, and an EV of $180. What value do you provide them?

A. -45 B. -20 C. 0.80 D. 0.90



Page 201


A. -30 B. 0.95 C. 0.92 D. -20


A. 10 B. 5 C. 1.11 D. 1.25

15. Your boss enters your office and asks for the schedule variance on your project that has an AC of $45, a PV of $40, and an EV of $50. What value do you provide them?

A. 10 B. 5 C. 1.11 D. 1.25

Earned Value Answers 1: B; 2: A; 3: A; 4: B; 5: C; 6: A; 7: D; 8: D; 9: A; 10: C; 11: B; 12: A; 13: D; 14: B; 15: A



Page 202

Other Agile Tracking Tools

Although Earned Value is a powerful tool you can use to track the performance of an Agile project, it is definitely not the most common or popular. More often than not, Agile projects use a combination of two graphic representations of project performance. These come in the form of two charts. The first chart is called a Burndown Chart. A Burndown is a simple vertical bar chart read from left to right. Each day, the team produces a bar that represents all the Story Points still incomplete in the sprint. Theoretically, each day should see fewer points remaining. This is not always the case, however. Sometimes a team member is blocked from completing a task or User Story. When this happens those points remain incomplete from the previous day. Additionally, there are occasions where team members learn new information about a story. This can impact the number of Story Points assigned to a particular story and thereby increase the number of points remaining in the sprint.

In the original Scrum Guide, it specified each sprint as being 30 days in length. As has already been described that over the years this rule has changed so that today most Scrum Sprints are two to six weeks in length. However, the chart that appears below still follows the original rules and shows a sprint of 30-days in length. If you look carefully, though, you will notice that the chart is showing 39-days along the X-axis. How is this possible? Don’t our rules clearly state that once the sprint length for the project is determined it does not change? That is absolutely correct and that is the point. Our chart is showing that this sprint has a problem.

To understand this problem we have to be able to calculate the team’s rate of productivity and know the remaining number of Story Points. This is a pretty easy calculation. All that is required is to take the number of Story Points completed

Slide 216



Page 203

and divide that by the number of days completed in the sprint. In the case of the example Burndown Chart, we are shown a productivity rate of 50 Story Points per day. The problem is that this rate of productivity means the team must work until day 39 to complete all the work currently in the sprint. The next logical question is, of course, what rate of productivity would the team need to complete all the work? This is calculated by taking the remaining Story Points and dividing it by the number of days remaining in the sprint. In this case, the chart displays this information for us, and shows us that we would need to complete the remaining work at a rate of 90 Story Points per day. This rate is almost twice what the team is currently able to produce, and is likely not very realistic. Unfortunately, the team is going to have to make some hard choices about what they CAN complete in the current sprint. Some stories will have to be pushed back to the Product Backlog to be completed in a future sprint. This process is actually quite typical, and represents how Scrum is supposed to work. The good news is that after a few sprints the team will better understand the rate at which they are able to produce work. Additionally, this rate tends to stabilize with time. It is therefore highly unusual for a team to see a productivity range of more than five to ten percent from one sprint to the next—and the widest variances occur very early in the project. This rate is called the team’s VELOCITY, and is a key measure of the performance of an Agile team.

When we talk about velocity it is important to recognize that it is a variable that cannot be used to compare one Agile team with another because the value of a Story Point differs from one team to another. One team might be working to complete 400 Story Points in the current sprint, while another is working on 2,000 Story Points. There is no guarantee that 2,000 points represents more work or value than 400 points. Therefore, velocity should only be used as a comparison measure within each discrete team.

The final graphic we will discuss in this chapter is the Burn Up Chart. This chart is used to show the world when the fully completed product will be released. Remember, the Burndown Chart was used to show performance in a individual sprint. The Burn Up Chart is used to show the team’s performance across all the sprints combined. It is constructed using the same two initial axes. Time appears on the X-axis and productivity or features appear on the Y-axis. There are some differences between the two charts, however, as you can see by examining the example on the opposite page. Those differences begin with the absence of any bars to represent remaining Stories. Instead, the Burn Up Chart focuses on two sets of lines. The first line to examine is the horizontal arrow that appears near the top of the chart. This line represents the total number of stories that require completion to finish the project. This line is initially flat because it represents the absence of any change in project scope. However, in the real world this line often changes in an upward direction as the customer adds more scope to the project, or as the team discovers that other important features were missed.

The second line in our Burn Up Chart represents work or Stories that have been completed. This line appears as a diagonal line starting in the lower left corner of the chart that progresses upward and to the right until it intersects the line that represents the total number of stories in the project. In the real world, teams often



Page 204

see this line slowly shift further to the right when it takes longer than forecasted to complete required work. This usually occurs at the same time that more stories are added to the Backlog—making the top horizontal line shift upward. The goal of the team is to have these two lines intersect, because this means that all the work in the project is complete. Shifting these two lines causes that intersection to occur further to the right, meaning it is happening later that forecasted. Teams use this chart to show everyone interested in the project when it is forecasted to be complete, and to allow customers to make adjustments to project’s scope based on this information.

These two charts represent two key INFORMATION RADIATORS used in Agile projects and are usually displayed just outside or in the project’s Team Room.

Before progressing to the next chapter on Stakeholder Engagement complete the quiz that follows. Make sure you score at least 90% before you continue.

Slide 217



Page 205

Exercise 7 — Value-Driven Delivery

Value-Driven Delivery 1. After reviewing a series of tasks being completed by the team, you determine the team is

focusing on defining positive value. Which of the listed tasks does NOT belong in that determination?

A. Define deliverables by identifying units that can be produced incrementally to maximize stakeholders value minimize non-value added work.

B. Refine requirements by gaining consensus on the acceptance criteria for features on a just-in-time basis in order to deliver value.

C. Select and tailor the team’s process based on project and organizational characteristics as well as team experience to optimize value delivery.

D. Plan for small increments by organizing requirements into the MMF/MVP in order to allow for the early recognition and delivery of value.

2. You and a coworker are arguing about the advantages of using Agile development. Which of the following might you list as a key advantage?

A. Small releasable increments that offer early recognition and delivery of value. B. An increased number of increments that ensure the team identifies and responds to

risks early. C. Obtain more frequent customer feedback through retrospective reviews at the end of

each iteration. D. Prioritization of business value through constant delivery of small increments.

3. Which of the following statements concerning value driven delivery is NOT true?

A. Agile's notion of value driven delivery says that every project has at its center a responsibility to deliver real business value.

B. Agile believes it is critical that the project delivers the most important features first while also considering technical dependencies and risks.

C. Value-driven delivery represents the big picture view, the wearing of the sponsor’s hat when making decisions.

D. Value driven delivery is the focus of the project once it reaches execution processes.

4. The team is working to determine the business value for the project all of the following EXCEPT ________________ represent techniques the team might use.

A. Benefit measurement methods. B. Constrained optimization methods. C. Both A and B are used to determine business value. D. None of the above are used to determine business value.

5. Linear programming is an example of what type of project selection tool?

A. Regression analysis B. Benefit cost measurement C. Quantitative scoring D. Constrained optimization

6. Your company is evaluating three different projects, but can do only one. Project A has an NPV of $120,000 and will take 6 years to complete. Project B will take 3 years and has and NPV of $91,500 and Project C has an NPV of $83,000. Based on this information, which project would you pick?

A. Project A B. Project B C. Project C D. There is not enough information to determine.



Page 206

7. What is the Present Value of a project that is forecasted to have a future value of $1,020.87 USD in five years assuming an 8% rate of return?

A. $1,750 B. $875.23 C. $1,250 D. $694.78

8. What is the Present Value of a project that is forecasted to have a future value of $18,782.87 USD in three years assuming an 10% rate of return?

A. $20,000.00 B. $17,075.33 C. $15,523.03 D. $14,111.84

9. What is the future value of a project believed to have a present value of $19,000 USD if you assume a four year term and a three percent rate of return?

A. $20,793.41 B. $21,384.67 C. $22,621.83 D. $23,112.14

10. What is the future value of a project believed to have a present value of $16,000 USD if you assume a three year term and a 10.25 percent rate of return?

A. $21,441.53 B. $22,375.14 C. $23,648.16 D. $24,110.13

11. Which of the following terms represents the calculation used to determine the value of a project in today's dollars minus its costs and is used for comparative purposes?

A. Future value B. Present value C. Net present value D. Internal rate of return

12. When determining the business value of a project, which of the following terms represents the money or value the organization receives back as a measure against its investment?

A. Future value B. Present value C. Net present value D. Internal rate of return

13. You have been asked to choose one of three projects. Project A has an NPV of U.S. $17,000. Project B has an NPV of U.S. $32,000. And Project C has an NPV of U.S. $39,000. What is the opportunity cost of selecting Project B?

A. U.S. $39,000 B. U.S. $32,000 C. U.S. $17,000 D. U.S. $7,000



Page 207

14. You have been asked to choose one of three projects. Project A has an NPV of U.S. $17,000. Project B has an NPV of U.S. $32,000. And Project C has an NPV of U.S. $39,000. What is the opportunity cost of selecting Project B?

A. U.S. $39,000 B. U.S. $32,000 C. U.S. $17,000 D. U.S. $7,000

15. The team has just finished developing a roadmap for the optimized state as part of a value stream mapping exercise. What should you do next?

A. Review the map to find delays, waste and constraints. B. Create a new value stream map of the desired future state of the process, optimized to

remove or reduce delays, waste and constraints. C. Plan to revisit the process in the future to continually improve. D. Identify the product or service that you are analyzing.

16. A important part of value stream mapping is calculating something called _______.

A. Mission critical time B. Total cycle time C. Total project time D. Total time

17. Mathematically, Total Cycle Time is defined by which of the following equations?

A. Value Added Time + Non-Value Added Time = TCT B. Overall Cycle Time + Non-Value Added Time = TCT C. Value Added Time - Non-Value Added Time = TCT D. Overall Cycle Time - Non-Value Added Time = TCT

18. Mathematically, the Process Cycle Efficiency is defined by which of the following equations?

A. Total Cycle Time / Value Added Time B. Value Added Time/ Overall Cycle Time C. Overall Cycle Time / Total Cycle Time D. Value Added Time / Total Cycle Time

19. Which of the following are NOT part of Taiichi Ohno's acronym TIMWOOD?

A. Transportation B. Waiting C. Income D. Overproduction

20. Which of the following is NOT an Agile prioritization technique?

A. Monopoly Money B. Moscow Mule C. Dot Voting D. CARVER

21. When Professor Noriaki Kano created his customer satisfaction and product development theory, which of the following was one of his categories of customer preferences?

A. Technical needs B. Sponsor needs C. Excitement needs D. Fundamental needs



Page 208

22. Which of the following prioritization techniques rates each feature by benefits for having, not having, cost of producing, risks, etc., and a score is calculated using a weighting formula predefined by the team?

A. Requirements prioritization model B. Relative prioritization model C. CARVER D. Kano analysis

23. Which of the following represents the group of User Stories that delivers the fewest number of features that someone would be willing to pay money to obtain?

A. Base feature set B. Baseline feature set C. Minimally marketable features D. Minimum viable product

24. A member of your team suggests the use of a Story Map to improve the team's project understanding. Which of the following best describes the purpose of a Story Map?

A. Story Maps present a visual way of seeing all the features in a project. B. Story Maps present a visual method for understanding the business need. C. Story Maps present a basic chronology of the project. D. Story Maps present a basic understanding of the project justification.

25. Within a Story Map where would you find the product backbone or MMF?

A. The MMF or product backbone is not located on a Story Map. B. The MMF or product backbone is located on the left of the Story Map. C. The MMF or product backbone is located on the bottom of the Story Map. D. The MMF or product backbone is located on the top of the Story Map.

26. When dealing with project risks, which of the following account for up to 90% of the risks the team might encounter?

A. Known unknowns B. Unknown unknowns C. Critical risks D. Unbudgeted risks

27. When dealing with project risk on an Agile project, which of the following statements is NOT true?

A. Agile projects typically have shorter timelines before a product is ready for release. B. Customers receive the most important features first thereby reducing risk. C. At the latter stages of the project the customer often must decide to continue the

project or lose less important features. D. At the end of the project the customer decides whether or not to accept all the

features.

28. If the project has a best case estimate of U.S. $10,000 with a probability of 20%, a most likely case estimate of U.S. $12,000 with a probability of 50%, and a worst case estimate of U.S. $14,400 with a probability of 30% what is the EMV for the project?

A. U.S. $12,320 B. U.S. $12,400 C. U.S. $13,010 D. U.S. $13,260



Page 209


A. U.S. $19.190 B. U.S. $19,515 C. U.S. $20,110 D. U.S. $20,350


A. U.S. $30.190 B. U.S. $31,560 C. U.S. $32,219 D. U.S. $33,350

31. You must choose between projects A or B. A will cost $650K & B will cost $467K. There is a 56% chance that A will be successful, with a gain of $1,800K. If A fails there it loses $900K. There is a 67% B will be successful, with a gain of $950K. If B fails it loses $670K. What is the value of the best alternative?

A. U.S. $-38,000 B. U.S. $38,000 C. U.S. $-51,600 D. U.S. $51,600

32. A will cost $54K & B will cost $90K. There is a 54% chance that project A will be successful, and have a $206,540 gain. If A fails it will have a loss of $90.5K. There is a 61% B will be successful and have a $269K gain. If B fails there will be a loss of $118K. Which do you choose?

A. Project A B. Project B C. The projects offer the same valuation. D. There is not enough information to determine.

33. A will cost U.S. $300K & B will cost $255K. There is a 67% chance A will be successful & result in a $650K gain. If A fails there will be a loss of $310K. There is a 58% B will be successful, and that will result in a $650K gain. If B fails there will be a loss of $225K. What is the value of the best alternative?

A. U.S. $60,700 B. U.S. $27,500 C. U.S. $33,200 D. U.S. $51,600

34. Most Agile methodologies flex which leg of the project management triangle?

A. Time B. Cost C. Quality D. Scope



Page 210

35. Which of the following Agile methodologies uses the concept of "money for nothing and change for free" as a basis for contracting?

A. Scrum B. DSDM C. Feature Driven Development D. Extreme Programming

36. Little's Law states that cycle time is proportional to what?

A. The size of the queue. B. The work in progress. C. The size of the team. D. The length of the schedule.

37. In which area does the acronym IKIWISI MOST apply?

A. Time B. Cost C. Scope D. Quality



Page 211

Value-Driven Delivery Answers 1. Answer D. LGd course manual p. 167 - The tasks found in the Define positive value group

include: Define deliverables by identifying units that can be produced incrementally in order to maximize their value to stakeholders while minimizing non-value added work; Refine requirements by gaining consensus on the acceptance criteria for features on a just-in-time basis in order to deliver value; Select and tailor the team’s process based on project and organizational characteristics as well as team experience in order to optimize value delivery.

2. Answer A. LGd course manual p. 167 - Be careful here as several items are close to true, but the Value Driven Delivery area lists three specific tasks Agile uses to avoid potential downsides: Plan for small releasable increments by organizing requirements into MMF/MVP in order to allow for the early recognition and delivery of value. Limit increment size and increase review frequency with appropriate stakeholders in order to identify and respond to risks early on and at minimal cost. Solicit customer and user feedback by reviewing increments often in order to confirm and enhance business value.

3. Answer D. LGd course manual p. 168 - Agile carries this simple idea one step further by also contending that it is critical that project deliver the most important features first while also considering technical dependencies and risks. Key is remembering why projects are initiated in the first place. Projects are undertaken to generate some type of business value, be it to produce a benefit, product or service. Even safety and regulatory compliance projects can be expressed in terms of business value by considering the business risk and impact of not undertaking them. If value then is the reason for doing projects, value driven delivery is the focus of the project throughout the project planning, execution, and control processes. Value-Driven Delivery represents the big picture view, the wearing of the sponsor’s hat when making decisions.

4. Answer C. LGd course manual p. 168-170 - There are two ways to determine business value. These include: benefit measurement methods and constrained optimization methods.

5. Answer D. LGd course manual p. 168-170 - Constrained optimization methods represent advanced mathematical models used to calculate project value. Methods included in this class are linear, integer, dynamic and multi-objective programming.

6. Answer A. LGd course manual p. 168-170 - The years are irrelevant to this question as the whole point of NPV is to convert the project value into today’s dollars. In this case project A is the correct choice with an NPV of $120,000.

7. Answer D. LGd course manual p. 169 - The Present Value, or discounting, refers to a Future Value that has been discounted to express it in today’s currency. For example, imagine you had U.S. $100 buried in a coffee can in your backyard. Twenty-five years later you dig up the coffee can and find the U.S. $100 bill. Does it still have the same purchasing power? Absolutely not! Inflation has made that U.S. $100 worth significantly less. This equation also is not often seen on the exam, but it is necessary to understand the next formula. The equation for the Present Value is: PV = FV / (1 + i)n

8. Answer D. LGd course manual p. 169 - The Present Value, or discounting, refers to a Future Value that has been discounted to express it in today’s currency. For example, imagine you had U.S. $100 buried in a coffee can in your backyard. Twenty-five years later you dig up the coffee can and find the U.S. $100 bill. Does it still have the same purchasing power? Absolutely not! Inflation has made that U.S. $100 worth significantly less. This equation also is not often seen on the exam, but it is necessary to understand the next formula. The equation for the Present Value is: PV = FV / (1 + i)n

9. Answer B. LGd course manual p. 169 - The Future Value represents the value of an investment at some future point based upon a provided interest rate. Very few, if any, test candidates have to calculate the future value, but understanding it is necessary to answer comparative questions you might see. It is defined by the formula: FV = PV * (1 + i)n



Page 212

10. Answer A. LGd course manual p. 169 - The Future Value represents the value of an investment at some future point based upon a provided interest rate. Very few, if any, test candidates have to calculate the future value, but understanding it is necessary to answer comparative questions you might see. It is defined by the formula: FV = PV * (1 + i)n

11. Answer C. LGd course manual p. 169 - The Net Present Value is almost identical to the present value. In the Present Value calculation you discount the value, typically representing a revenue stream, to account for inflation or some other similar rate. Net Present Value does the same thing, but it also takes into consideration the money that must be spent to complete the project over time. To do so it costs the Present Value from the net costs to obtain the NPV.

12. Answer D. LGd course manual p. 169 - In an Internal Rate of Return equation, it is the interest rate that must be determined. Unfortunately, there is no simple equation to calculate the internal rate of return. To solve for the IRR you must use the NPV calculation and select the middle most interest rate of the four potential answers. You are looking for an interest rate which produces an NPV of zero. Based upon the result from the first calculation you can determine if you need a larger or smaller value. You should not have to calculate the NPV more than twice to determine the correct IRR.

13. Answer A. LGd course manual p. 170 - Opportunity cost is the value of the next highest alternative assuming the alternatives are mutually exclusive. It defines what you are giving up by making the choice. In this case, the correct answer is U.S. $39,000.

14. Answer B. LGd course manual p. 171 - Value Stream Mapping is a lean management technique for analyzing the current and future state for the series of events that tracks a specific product or service from beginning to end. It is a visual technique that uses something called a “Visual Map” The process of Value Stream Mapping consists of six steps. These steps include: Identify the product or service that you are analyzing; Create a value stream map of the current process, identifying steps, queues, delays, & information flows; Review the map to find delays, waste & constraints; Create a new value stream map of the desired future state of the process, optimized to remove or reduce delays, waste & constraints; Develop a roadmap for creating the optimized state; and plan to revisit the process in the future to continually improve.

15. Answer C. LGd course manual p. 171 - Value Stream Mapping is a lean management technique for analyzing the current and future state for the series of events that tracks a specific product or service from beginning to end. It is a visual technique that uses something called a “Visual Map” The process of Value Stream Mapping consists of six steps. These steps include: Identify the product or service that you are analyzing; Create a value stream map of the current process, identifying steps, queues, delays, & information flows; Review the map to find delays, waste & constraints; Create a new value stream map of the desired future state of the process, optimized to remove or reduce delays, waste & constraints; Develop a roadmap for creating the optimized state; and plan to revisit the process in the future to continually improve.

16. Answer B. LGd course manual p. 172 - A big part of Value Stream Mapping is calculating something called Total Cycle Time. Total Cycle Time represents all the processes, steps, machine work and anything else through which a product must pass before it is considered “finished”. It is often broken into several different types of time including: Manual Cycle Time, Machine Cycle Time, Auto Cycle Time, and Overall Cycle Time.

17. Answer A. LGd course manual p. 172 - Mathematically, the Total Cycle Time or TCT is defined as the Value Added Time + Non-Value Added Time.

18. Answer D. LGd course manual p. 173 - In addition to the Total Cycle Time, you must be prepared to calculate the Process Cycle Efficiency which represents the Value Added Time divided by the Total Cycle Time. According to Six Sigma, a lean process is one in which the Value Added time in the process is 25% or more of the total time in the process.



Page 213

19. Answer C. LGd course manual p. 173 - Here are the TIMWOOD seven forms of waste translated from Lean Manufacturing to software development: Partially Done Work; Extra Processes; Extra Features; Task Switching; Waiting; Motion; and Defects.

20. Answer B. LGd course manual p. 173-175 - When the team is focused on Value-Driven Delivery it has a customer valued prioritization. This means working on the things that yield the greatest return for the customer. The primary tool used by the team differs based on the Agile methodology being used. Techniques include MoSCoW Prioritization Scheme; Monopoly Money; 100-Point Method; Dot Voting / Multi-Voting; CARVER; Kano Analysis; Requirements Prioritization Model; and Relative Prioritization or Ranking.

21. Answer C. LGd course manual p. 174-175 - Kano Analysis represents a customer satisfaction and product development theory first developed in 1984 by Professor Noriaki Kano, and was originally designed to classify customer preferences into three categories: Performance Needs; Basic Needs; and Excitement Needs.

22. Answer B. LGd course manual p. 176 - In the Requirements prioritization model each feature is rated by benefits for having, not having, cost of producing, risks, etc., and a score is calculated using a weighting formula predefined by the team. This method allows the team to value certain items as having greater importance by increasing their weighting in the formula. Commonly, the scores range from one to nine. This model was originally created by Karl Wiegers.

23. Answer C. LGd course manual p. 176 - The Minimally Marketable Features or MMF represents the minimal functionality set, a fancy way of saying a group of User Stories or package of features, that delivers the fewest number of features that someone would be willing to pay money to obtain. These represent distinct, and deliverable features of the system that provide significant value to the customer.

24. Answer A. LGd course manual p. 176 - Story Maps present a visual way of seeing all the features in a project. It is typically read along two axis. Time is represented along the X-axis with columns often placed for releases or iterations on smaller projects. The Y-axis is used to represent how important the User Story is to the customer. At the top are the most important Stories, referred to as the product backbone or the MMF. Below that appears the walking skeleton and then more and more optional features.

25. Answer D. LGd course manual p. 176 - Story Maps present a visual way of seeing all the features in a project. It is typically read along two axis. Time is represented along the X-axis with columns often placed for releases or iterations on smaller projects. The Y-axis is used to represent how important the User Story is to the customer. At the top are the most important Stories, referred to as the product backbone or the MMF. Below that appears the walking skeleton and then more and more optional features.

26. Answer A. LGd course manual p. 177 - Unknown unknowns cannot be planned for and require management reserves or general contingency. Up to 90% of the risks on a project fall into the known unknown category and can be identified.

27. Answer D. LGd course manual p. 178-179 - In waterfall it can be a long time before a product is ready for release. In Agile this can be shorter, sometimes only a few weeks. This serves to reduce project risk because the customer receives the most important features very early on in the process. As the project comes to its deadline the team is typically working to deliver far less important features that in many cases could be excluded if required without impacting business value. This puts the customer in a position to make the decision as to whether or not they want the desired features without of loosing the critical value.

28. Answer A. LGd course manual p. 181-183 - To get the correct answer you must first realize you are dealing with three mutually exclusive options. You cannot simultaneously have the best and worst case scenarios. Therefore, your probabilities must sum to 100%. Use the calculation probability * result for each case and then add the results together to get the EMV.



Page 214

29. Answer B. LGd course manual p. 181-183 - To get the correct answer you must first realize you are dealing with three mutually exclusive options. You cannot simultaneously have the best and worst case scenarios. Therefore, your probabilities must sum to 100%. Use the calculation probability * result for each case and then add the results together to get the EMV.

30. Answer C. LGd course manual p. 181-183 - To get the correct answer you must first realize you are dealing with three mutually exclusive options. You cannot simultaneously have the best and worst case scenarios. Therefore, your probabilities must sum to 100%. Use the calculation probability * result for each case and then add the results together to get the EMV.

31. Answer A. LGd course manual p. 181-183 - To answer this question you must calculate the expected monetary value of each choice using the decision tree model found in your LGd training guide and then compare the options. Whichever option has the greatest value is the one you should choose.

32. Answer B. LGd course manual p. 181-183 - To answer this question you must calculate the expected monetary value of each choice using the decision tree model found in your LGd training guide and then compare the options. Whichever option has the greatest value is the one you should choose.

33. Answer C. LGd course manual p. 181-183 - To answer this question you must calculate the expected monetary value of each choice using the decision tree model found in your LGd training guide and then compare the options. Whichever option has the greatest value is the one you should choose.

34. Answer D. LGd course manual p. 188 - Agile Contracting fixes the time and cost legs of the triangle while leaving the scope leg flexible. Agile Development then requires the prioritization of the features and the customer to make decisions about the scope. This inversion of the triangle priorities ensures the customer has greater control of the product, at least theoretically, but it requires much greater communication between the customer and team to prevent surprises.

35. Answer A. LGd course manual p. 188 - Jeff Sutherland, one of the originators of Scrum uses the phase, “money for nothing and change for free” to describe his notion of Agile Contracting. In this notion, the customer is allowed to terminate the project early and has the flexibility to make changes. His idea uses a standard Firm Fixed Price Contract, but adds time and materials for and additional work plus a change for free clause the customer works with the team on every iteration using the Scrum process. This means daily.

36. Answer A. LGd course manual p. 189 - Cycle Time represents how long the customer must wait before receiving any benefit from the features created. Little’s Law states that Cycle Time is proportional to the size of the queue, or how much Work in Progress the team has. This concept is displayed using a Cumulative Flow Chart.

37. Answer C. LGd course manual p. 190 - IKIWISI stands for an old truism from many customers. It means I’ll Know It When I See It, and points to the common problem many development teams face. Sometimes the customer doesn’t know or fully understand what they want in terms of the features of the product until they see it. Only by touching and using a product can they understand its characteristics and fully understand how they would use it.

Chapter 6 — Stakeholder Engagement


Page 215

Slide 219

Page 215

Stakeholder Engagement Stakeholder Engagement Overview Stakeholder engagement is all about determining who your stakeholders are, getting them involved in the project, and then keeping them involved at the right level until the project is completed. Agile Development places a much higher requirement for stakeholder involvement than most project leaders have experienced. There are no rules that make this a fact. Instead, teams and stakeholders get comfortable out of force of habit. Both sides get used to the stakeholder providing basic requirements and then walking away from the project until it nears completion and/or is struggling. The team often becomes so comfortable with the lack of involvement that they begin to not only expect it, but demand it. Any involvement by the customer is seen as an intrusion or distraction and something to be avoided. Agile Development does not fight against the rules so much as it runs opposite of the most common real world practices. Agile Development argues that stakeholders must be involved in every aspect of the project, every day.

Stakeholder Engagement Domain Tasks The Stakeholder Engagement Domain focuses on nine specific tasks broken into three groups. These groups describe the three most important aspects of working with project stakeholders.

Stakeholder Engagement

Identify and engage effective and empowered business stakeholders through periodic reviews in order to ensure that the team is knowledgeable about the stakeholder’s interests, needs, and expectations.

Identify and engage all stakeholders (current and future) by promoting knowledge sharing early on and throughout the project in order to ensure the unimpeded flow of information and value throughout the lifespan of the project.

Ensure Stakeholder Involvement

Establish stakeholder relationships by forming a working agreement among key stakeholders in order to promote participation and effective collaboration.

Maintain proper stakeholder involvement by continually assessing changes in the project and the organization in order to ensure that new stakeholders are appropriately engaged.

Establish collaborative behaviors among the members of the organization by fostering group decision making and conflict resolution in order to improve decision quality and reduce the time required to make decisions.



Page 216

Slide 220

Slide 221-222

Manage Stakeholder Expectations

Establish a shared vision of the various project increments (products, deliverables, releases, iterations) by developing a high level vision and supporting objectives in order to align with the stakeholder’s expectations and build trust.

Establish and maintain a shared understanding of success criteria, deliverables, and acceptable trade-offs by facilitating a common awareness among stakeholders in order to align expectations and build trust.

Provide transparency regarding work status by communicating team progress, work quality, impediments, and risks in order to help the primary stakeholders make informed decisions.

Provide forecasts at a level of detail that balances the need for certainty and the benefits of adaptability in order to help stakeholders plan effectively.

Defining Stakeholders Depending on the resource you are studying, there are a wide number of definitions that exist for project stakeholders. Some authors define stakeholders as the individual or individuals that pay for the project. Others define the stakeholders as the people who actually use the product or service of the project. In between these definitions are a variety of combinations that further serves to confuse everyone involved. To ensure clear understanding, we will use PMI’s definition of a stakeholder. According to PMI, a stakeholder is anyone with a vested interest in the project. That interest can be positive or negative. Based on this definition, there are a lot of people who represent potential stakeholders on any project. The table below shows some of the potential stakeholders for a typical project. There are many other potential stakeholders not listed in the table. As a project leader and facilitator part of your job is helping the team work with the project stakeholders. This includes determining who those stakeholders are, maintaining their involvement throughout the project, and working to ensure that their interests are actively managed. When analyzing stakeholders in an Agile environment, it is key that the team has a clear understanding of the customer’s Definition of Done or DoD. This is a critical Agile phrase. It represents the core success criteria. It must be quantitative and objective. To ensure the team delivers on the DoD the team must constantly ensure that they show the customer progress

Your Boss Shareholders The Government

Senior Executives Alliance Partners Trade Associations

Coworkers Suppliers The Press

Stakeholder Examples

Your Team Lenders Interest Groups

Customers Analysts The Public

Prospects Future Employees The Community

Your Family Users Sponsors



Page 217

Slide 223

Slide 224

and capabilities regarding the product or service of the project. This is all about transparency. Teams that are perceived to be transparent typically receive better support and participation from their stakeholders. Another aspect of this transparency is the ability to have candid discussions about all aspects of the project. This is especially important when dealing with product capabilities, estimates, and projections of future capabilities or needs. This need for transparency drives many of the tools the Agilist uses to ensure project success. The first of these tools are wireframes.

Wireframes Wireframes are a quick, cheap and simple tool. In Agile parlance we refer to tools like these as low fidelity. They represent rough representations of the systems that help the team validate key concepts early in the design process. Simply put, wireframes are used for quick mockups of screens and interfaces typically used with thin client and client server technology. Wireframes represent a visual tool to present information to stakeholders. By using programs like Word, Dreamweaver or Photoshop, a team is able to quickly create a picture of key screens so the customer can see how key components are positioned. By generating such images, the team and customer can have tangible conversations about how things look, and about the basic workflow of the system. The image to the right presents a sample wireframe. The image shows a screen that could easily be created in less than 10 minutes using almost any tool including physical pen and paper. If the developer takes the extra step of using software, it allows the team to instantly move components around as part of a live meeting with the customer.

Personas Another common tool used in Agile Development are Personas. Personas are written descriptions of system users. They are referred to as archetypal descriptions of a standard user of the system. In this case, the archetype refers to a specific sample user that has characteristics that are typical for the system users. A persona is NOT a real person. They represents someone who could be real. But the archetypal descriptions are grounded in reality. They are used to help the team focus on who the system’s users are or the users they really want. One of the key



Page 218

Slide 225

Slide 226

aspects of the persona is the fact that it is both tangible and actionable. This means that the development team can easily picture the person to which the persona refers—as if they are standing right in front of them. It also means the team understands how to build an application for that person. Additionally, personas are goal oriented. It does not help the team to create a bunch of fictional characters—albeit realistic ones—that they must review. Each persona has a reason for existing. They must highlight or represent some key category of user that the product or the service of the project is likely to encounter. Personas create a powerful likeness of a user that allows the developer to build functionality around the personas’ needs. However, this tool does not replace requirements. Instead, it is a tool to augment the developer’s understanding of those requirements, but in a way that emphasizes the user’s experience.

Personas were first introduced by Alan Cooper for software development projects. He argues that software must be designed for a specific person. In this way, personas differ from Use Cases. For example, the team might describe a specific class of customer—say, retirees—who prefer not to bank using the internet, telephone or ATM. They prefer to walk into the branch and work with a person they can see and with whom they can build a relationship. This is a class of user that can be described using a Use Case, but in order to present all the potential circumstances these retirees might face, the team needs some examples. That is where a persona comes into play. In most cases, testing requires the team to build multiple personas as test cases. To help you better understand personas lets flesh out our retiree example with a complete persona.

Sixty-seven year-old Frances Miller is the mother of four children and the grandmother of twelve. She lives in her own home, bakes a pie once a week so that she has something to serve for Sunday visitors (usually one of her children and their immediate family) and has two cats. The cats' names are Fred and Wilma, names given to them by four-year old grandson Bobby. She likes to knit and do needlework, which she either gives away as presents to her family or donates to the annual sale to raise money for the church she belongs to. Every morning she goes for a one hour walk along the lakefront when the weather is good. On bad days she'll go with her neighbor to the local mall where a group of senior citizens "Mall Stroll" each morning before sitting down at one of the restaurants for coffee or tea. For breakfast Frances prefers a cup of Earl Grey tea and two slices of whole-wheat toast with her own home-made preserves. Lunch is typically a bowl of soup or a sandwich. Then she'll have the opposite for dinner. She is a middle-class retiree living on a fixed income and has been a widow for ten years. Her mortgage has been paid off and she has one credit card which she seldom uses. She has been a customer of the bank for 57 years. She has never used an automated teller machine (ATM) and never intends to. She has no patience for phone banking and does not own a computer. Every Monday at 10:30 am she will visit her local bank branch to withdraw enough cash for the week. She prefers to talk with Selma the branch manager or with Robert, a CSR who was a high-school friend of her oldest son.



Page 219

Slide 227

Slide 228

Slide 230

As you read through Frances Miller’s persona did your mind paint a vivid image of what she looks like and who she is? If you were a developer tasked with creating the next version of the bank’s primary internet banking information, how would having that vivid impression of the life of more than 20% of the bank’s current portfolio impact the decisions you make about the application? For example, would you be more or less willing to spend a significant amount of money on application development knowing such a large percentage of your user base would never use the application? Or, does it make sense at all to have Francis as one of your test cases for the developers? These kinds of questions are critical because Personas provide valuable insights for the team.

User Stories Another common tool used in many forms of Agile Development is the User Story. Originally created as the primary vehicle for defining features or Work Packages in Scrum, User Stories represent features that have been written from the perspective of the end user. Each Story represents a single row or item in the Product Backlog. Hence, they are sometimes referred to as Product Backlog Items or PBIs. Because the User Stories represent the primary vehicle for defining the features on a project, there must be some way of creating estimates at the Story level. When creating estimates for User Stories, the primary tool is the Story Point. However, a Story Point does not answer the question of exactly when the feature will be completed. It is slightly more complicated that that. Earlier we discussed how Agilists argue that one of the greatest failings of linear methodologies is the inaccuracies of their estimates. Although there is no rule requiring an exact estimate—in fact it is quite the opposite—the tendency is for every project manager to end up with a series of single number estimates for which they are held accountable. The standards found in the PMBOK® Guide argue for a range of plus or minus ten percent, but this almost never happens. This inaccuracy leads to all kinds of problems including things like teams working impossible hours to hit unrealistic deadlines, stakeholders having unrealistic expectations, and disappoint in the teams inability to ever hit a deadline. Instead, Agilists argue that the very process causes many of these problems—the problem is not the intent of those using them. Therefore, Agile Development takes a different tact. Story Points represent a loose amalgamation of complexity and time, and each project has a unique scale. User Stories always appear in the form of “As a ROLE, I need to FUNCTION so that I may SUCCESS CRITERIA. This single sentence (or sometimes pair of sentences) may appear to be incredibly simplistic, but they are very powerful. User Stories are always written in the language of the business because they providing a primary bridging tool between developers and the customer. Additionally, each Story must provide an acceptance criteria and must be testable.

User Stories provide a number of key advantages over other methods. Most important of these is the fact that User Stories are very incomplete in terms of the specifics that would allow a developer to actually build the feature. User Stories tend to make developers feel very anxious because of the absence of the data that is needed to create the required functionality. This fact forces the developer and



Page 220

Slide 231

Slide 232

customer to actually talk. This usually means regular face-to-face interactions. But the absence of too much detail is seen by Agilists as an advantage. Having or attempting to have too much detail in the early stages of the project often causes the team to focus on features and/or requirements that change or disappear as the project progresses. When this happens in non-Agile projects it often causes costs to dramatically increase without providing any benefit. By avoiding detail, the team is better able to adapt and change the requirements as the project progresses. Finally, User Stories simply acknowledge the fact that all requirements are not known at the beginning of the project. Requirements, the Agilist contends, are amorphous and are often poorly understood or even completely misunderstood in the early phases of the project.

There are a number of acronyms used to describe User Stories. The first of these are the three C’s of User Stories. These focus in on the three critical aspects of a User Story. The three C’s include the following:

The Card — This brief written description must have meaning to both the team and the product owner. It is the bridge between the developer and customer.

The Conversation — This is the most important part. The card is not enough to write code. The card leads to a conversation that will ensure understanding.

The Confirmation — This is the success criteria. It gives us the high-level criteria against which the resulting feature will be tested.

The next major acronym used in the description of User Stories is based on a simple statement, you must INVEST in your stories. INVEST represents six facets of project that every Agilist must consider to get the most out of User Stories. The six facets are as follows:

Independent – From other stories. Each User Story needs to be independent from the other Stories in the Backlog. The Story must represent independent functionality that can be defined by the customer.

Negotiable – Not set in stone. Features are not absolute, but the business need is. This is an important distinction. The team must have the latitude to find the best solution.

Valuable – Don’t do it if it’s not necessary. Each User Story must provide real value to the business. If it doesn’t add value, why would the customer want the team to build it.

Estimatable – You must be able to come up with realistic numbers. This item often is confusing to a lot of Agile students. After all, didn’t we just discuss the fact that Agile Development takes a very different tact about estimating?

Small – Size matters! One of the keys to Agile’s success is that it cuts the project into smaller pieces, and small pieces are easier to manage that larger items. If mistakes are made, they are simpler to manage.



Page 221

Slide 233

Slide 234

Testable – You must be able to prove it works. This one is straight forward. Agile strongly promotes transparency. How can the team be transparent if they are not willing to prove that the product or service they are creating actually works as advertised?

Another form of User Stories is the format known as Given, When, Then. This format is used for non-functional or system-based stories. Here is an example of the Given, When, Then format:

Given that the account is valid and the account has a MovieCredit balance of greater than 0,

When the user redeems credit for a movie,

Then issue the movie and reduce the user’s MovieCredit balance.

Definition of Done On several occasions throughout this course we have already mentioned the importance of the Agile method for defining project success, the Definition of Done. However, at this time we need to examine it in greater detail. The Definition of Done states that before anything can truly be declared complete, it must be designed, coded and fully tested. Each of these steps represent small incremental steps necessary in any software project. Some students of Agile Development miss these and believe that somehow Agile skips these all important pieces of the puzzle, but they are there.

Tested — This piece is first and it demands that all the unit, integration and customer tests be completed before a package is declared complete. To call the work complete, it is not enough for the developer to complete the code and their individual unit tests. All levels of testing must be completed, including having the customer complete their own testing.

Coded — A feature cannot be considered complete until ALL the features are built. For many students, such a statement seems obvious. But what happens in the real-world is often very different. There are many software applications that struggle because developers built part of a function and promised to come back to finish the rest of it. Coded is a black or white standard. The feature is either complete or it isn’t.

Designed — The code must be fully refactored to the team’s satisfaction. Refactoring consists of improving the internal structure of an existing program's source code, while preserving its external behavior. The noun "refactoring" refers to one particular behavior-preserving transformation, such as "Extract Method" or "Introduce Parameter." Refactoring does not mean simply rewriting code, fixing bugs or improving observable aspects of software such as its interface. Refactoring that is done in the absence of safeguards against introducing defects (i.e. violating the "behavior preserving" condition) is risky. Safeguards include aids to regression testing, which includes automated unit tests or automated acceptance tests. It also includes aids to formal reasoning such as type systems. According to the Agile



Page 222

Alliance, refactoring is done to provide the project with a number of key benefits including:

Refactoring improves objective attributes of code (length, duplication, coupling and cohesion, cyclomatic complexity) that correlate with ease of maintenance.

Refactoring helps code understanding.

Refactoring encourages each developer to think about and understand key design decisions in the context of collective code ownership.

Refactoring favors the emergence of reusable design elements (such as design patterns) and code modules.

There are a number of signs that a team is using refactoring within a project. They may keep version control records such as CVS or Git Logs that have entries labeled Refactoring or the code modifications corresponding to such entries may specifically be verified to be behavior neutral.

The Agile Alliance further describes three levels of skill for refactoring. These levels include:

Beginner

Knows the definition of "refactoring".

Can use some automated refactorings from the IDE.

Can perform some refactorings by hand.

Is aware of the risks of regression from manual and automated refactorings.

Is aware of code duplication and can remove it by refactoring.

Intermediate

Knows and is able to remedy a broader range of "code smells".

Can chain several refactorings to carry out a design intention, in awareness of the dependencies between refactorings.

Refactors continuously, rather than in sporadic and lengthy sessions.

Advanced

Has an acute sense of code duplication and coupling.

Applies refactorings to non-code elements such as database schema, documents, etc.

Uses refactoring to guide large bodies of code toward design styles intentionally chosen from a broad palette: object-oriented, functional, or inspired by known design patterns.



Page 223

F2F On several occasions this course has also talked about the importance Agile places on face-to-face communication. A picture might further the point more than simply adding another description. In the graph, the X-axis represents the richness or temperature of the communication. When Agilists refer to communication temperature they are talking about how the communication brings people together and helps promote a positive or negative feeling about whatever is being discussed. Warm communication helps the participants have a positive feeling about the message. Cold communication causes the participants to have the opposite feeling, negative. The temperature of the communication impacts its overall effectiveness. The warmer the communication, the more effective it is. Based on these two axes, the graph generates two curves. The first curve represents naturally cold communication methods such as old-fashioned paper documents, audio recordings, or video recordings. All of these techniques struggle because they lack the ability to provide question and answer time. At the bottom of the warm curve is email. Although it does provide a method to get questions answered, it encounters delays and often suffers from misinterpretation. The most effective way to communicate is always face-to-face because each party can see the other’s expression and respond. The most effective way to use face-to-face communication is to include a whiteboard where the two parties can create visualization of the information being shared.

Information Radiators Information Radiators represent a number of highly visible methods to display information including large charts, graphs, and summaries of project data. These are sometimes referred to as visual controls, according to famed Agilist Alistair Cockburn. This course has already introduced a number of information radiators such as Burndown or Burn-Up Charts. However, there are a number of other visualizations used in Agile Development such as Average Cycle Time Charts, Cumulative Flow Diagrams, Earned Value Management Systems Diagrams, or a Velocity Tracking Chart. The Velocity Tracking Chart is a bar or line graph used to display the project’s daily velocity.

Agile Modeling The next tool used to promote stakeholder engagement is Agile Modeling. This is

Slide 235

Slide 236-237

Slide 238



Page 224

a practice-based methodology for effective modeling and documentation of software-based systems. At a high level, Agile Modeling is a collection of best practices, depicted in the pattern language map below. At a more detailed level Agile Modeling is a collection of values, principles, and practices for modeling software that can be applied on a software development project in an effective and light-weight manner. There are many different types of types of Agile Models. This fact has the potential to create a lot of confusion. Don’t let it. To get the highest value, focus on the value Agilists get from the practice. Scott Ambler, a top expert in Agile Modeling argues that Agile Modeling’s value peaks earlier than the traditional theory leads us to believe.

To model in an agile manner, you will apply Agile Modeling’s practices as appropriate. Fundamental practices include creating several models in parallel, applying the right artifact(s) for the situation, and iterating to another artifact to continue moving forward at a steady pace. Modeling in small increments, and not attempting to create the magical "all encompassing model" from your ivory tower, is also fundamental to your success as an agile modeler. Because models are only abstract representations of software—and abstractions that may not be accurate—you should strive to prove it with code to show that your ideas actually work in practice and not just in theory. Active stakeholder participation is critical to the success of your modeling efforts because your project stakeholders know what they want and can provide you with the feedback that you require.

The principle of “assume simplicity” is supported by a number of practices. One such practice is to create simple content by focusing only on the aspects that you need to model and not trying to create a highly detailed model. A second practice is depicting models simply via use of simple notations. A third practice is using the simplest tools to create your models. You travel light by single sourcing information, discarding temporary models, and updating models only when it hurts.

Clear communication is fostered through a number of practices such as displaying models publicly (either on a wall or internal web site), practicing collective ownership of the project artifacts, applying modeling standards, and modeling with others. Your development efforts are greatly enhanced when you apply patterns gently. Because you often need to integrate with other systems, including legacy



Page 225

databases as well as web-based services, you will find that you need to formalize contract models with the owners of those systems.

The table below shows some of the most common forms of Agile Modeling.

Use Cases One of the tools listed in the table above is the Use Case. It is a tool also originally created by Alistair Cockburn. Its original use was with the Unified Modeling Language. A Use Case is a tool used to help define requirements. It can best be compared to a User Story. The User Story is one or two sentences in the form of “As a ROLE, I need to FUNCTION so that I may ACCEPTANCE CRITERIA.” It is kept simple to force the developer and customer to talk about the feature. A Use Case is a much larger tool. It has two parts. The first part is the diagram. A Use Case Diagram has two key components. The first component is a simple stick figure of a person. The stick figure represents a system user. In Use Case parlance they are called ACTORS. An actor can be any person or user that makes use of the system. The other component of a User Case Diagram are ellipses. The ellipses represent the systems, or core components of functionality. These systems take inputs and run some kind of process against them, thus creating an output. Several of these individual functions can be brought together to form a larger system. Those two components are then connected by lines denoting the fact that one or more specific user makes “calls” to the system or requests that one or more component perform its function. That is all there is to the Use Case Diagram. It is another low fidelity tool.

The Use Case Write Up represents a more complex instrument. It appears as a one or two page document representing a series of steps in a single process. The Use Case provides a detailed description in language the can customer understand. The Use Case begins with an ID that is usually a unique identifier specific to the organization. The next field is the Project, which represents the name of the

Slide 239

Acceptance Test Business Rule Template Change Case Template

Contract Model Template Data Flow Diagram Domain Model

Feature Free-Form Diagrams Flow Chart

Constraint Essential/Abstract User Interface Prototype Logical Data Model

Network Diagram Object Role Model Diagram Personas

Robustness Diagram Security Threat Model System Use Case Template

UML Activity Diagram UML Class Diagram UML Communication/Collaboration Diagram

UML Composite Structure Diagram UML Deployment Diagram UML Interaction Overview Diagram

UML Package Diagram UML Sequence Diagram UML State Machine Diagram

UML Use Case Diagram Usage Scenario User Interface Flow Diagram

User Story Value Stream Map Class Responsibility Collaborator Model

Essential/Abstract Use Case Template Glossary Mind Map

Physical Data Model (PDM) Technical Requirement UML Component Diagram

UML Object Diagram UML Timing Diagram User Interface Prototype



Page 226

project. The final field in the first row is the Project Owner. This is the project sponsor or the person who is ultimately responsible for the project. The next row only contains a single field. It is the Deliverable. This is the feature or the requirement the Use Case defines. It is written in the language of the business. The row beneath the title offers a Brief Description of the Use Case. This is an explanation that both the customer and the developer understand. The next two fields go together. The first is the Primary Actor. This is person or persons most likely to make use of the system. In addition to the Primary Actor, many systems have other Actors who make use of the system in a non-primary capacity. The Secondary Actors appear as a field in the Detailed Use Case, but do not appear in the High Level Use Case.

The next field in the High Level Use Case is Preconditions. Preconditions are situations or conditions that must exist before the process described in the Use Case can work. Immediately after the Preconditions are the Post Conditions. These represent the outcomes that exist once the process described in the Use Case is complete. Beneath the Post Conditions is the most important section: the Normal Flow of Events. This section provides a step-by-step description of the process used to complete the normal flow of events that begins with the preconditions and ends with the post conditions. Beneath the Normal Flow of Events are the Exceptions. This is an area that often confuses those who are unfamiliar with a Use Case. The confusing aspect of the Exceptions area is the numbering. Notice in the example that the numbering starts with the number two and then skips to four and five. These numbers are tied to specific steps in the process found in the Normal Flow of Events. The final area in the High Level Use Case is the Future Enhancements. This area is used to provide developers with insight into how the team might be asked to change the product or service in the future. This allows the developer to place hooks in their code to accept the new functionality, or to design the code in other ways that are open to such possibilities.



Page 227

High Level Use Case ID: Proj1.1.2.3 Project: Make Me Rich Owner: Bob Jones

Deliverable Name: Buying Stock Over the Internet

Brief Description: Individual wants to purchase a stock using their Internet browser and then get the stock added to their personal portfolio automatically. The brokerage firm wants to make sure they obtain complete purchase and customer information.

Primary Actor(s): Stock Purchaser

Precondition: User must have an investment account open prior to initiating purchase.

Post Condition:

Website acknowledges stock purchase Website system log records transaction The individual’s portfolio information is updated within the investment

company’s database

Normal Event Flow:

1. Individual decides to buy a stock using the internet. 2. Individual goes to website and submits user login. 3. User researches various stocks. 4. User selects a stock to purchase. 5. User selects the share price, order type and number of shares. 6. The website calculates the total price for the order. 7. The user confirms the order and submits it to the system. 8. The website submits the order the appropriate securities market. 9. The stock is purchased and a confirmation is sent to the website. 10. The website updates the database containing customer holdings. 11. The stock is displayed within the individual’s portfolio.

Exceptions:

2. Individual’s login fails a. System displays failure message and asks for resubmission of login

information. b. If login attempt is the third (3rd) time or greater, send access denial

message. 4. System user provides an invalid stock symbol. Message shown to user

requesting valid stock symbol.

5. System user selects an invalid transaction type. Message shown to user stating the selected transaction type is invalid and a new transaction type is requested.

Future Enhancements:

1. Order confirmations are automatically e-mailed to system users.



Page 228

Slide 240-241 Other Tools When the Agilist talks about engaging stakeholders there are a number of other tools that are included beyond what has already been discussed. The first of these tools are basic soft skills. Soft Skills represent the core skills every leader needs in order to help their team. These skills represent the ability of the leader to dialogue, motivate and otherwise engage with their team. Leaders get their power from several places, but part of it comes from their ability to get their team to want to achieve the desired result. Soft skills is a term often associated with a number of things that characterize a person’s relationships with other people. This includes their EQ (Emotional Intelligence Quotient), their unique cluster of personality traits, their social graces, their ability to communicate, their knowledge of different languages, their personal habits, their interpersonal skills, their capacity for managing people, their leadership ability, etc. Soft skills contrast to hard skills, which are easy to quantify and measure (e.g. software knowledge, basic plumbing skills).

A person's soft skill EQ is an important part of their individual contribution to the success of an organization. Particularly those organizations dealing with customers face-to-face are generally more successful if they train their staff to use these skills. Screening for and training in personal habits or traits such as dependability and conscientiousness can yield significant return on investment for an organization. For this reason, soft skills are increasingly sought out by employers in addition to standard qualifications.

One important tool associated with soft skills is the ability to negotiate. Negotiation is a dialogue between two or more people or parties that is intended to reach a mutually beneficial outcome, to resolve points of difference, to gain some advantage for an individual or collective, or to craft outcomes that satisfy various interests. It is often done by putting out one position (or interest) and anchoring that position while making small concessions on other solutions and positions. The reliability and willingness of the person negotiating to implement the negotiated solution (as in contract) is a major factor in these transactions. It is not a zero-sum game. If that is the case, the negotiations have failed. If the negotiation is in an impasse, it is essential that both parties should acknowledge the rough decision that's been taken, and work towards the solution another day. Negotiation occurs in business, non-profit organizations, government branches, legal proceedings, among nations and in personal situations such as marriage, divorce, parenting, and everyday life. The study of the subject is called negotiation theory. Professional negotiators are often specialized—such as union negotiators, leverage buyout negotiators, peace negotiators, hostage negotiators. They may work under other titles, such as diplomats, legislators or brokers.

The next tool that is important in the Agile process is listening. Listening and hearing are two different things. Hearing involves perceiving the sound. Hearing is involuntary and may simply reflect the auditory capabilities of our brain. Listening, on the other hand, is much more active than just hearing. In fact, listening usually requires more energy than speaking since it involves receiving and interpreting information.



Page 229

Listening is vital in the process of language acquisition. Reading and translation simply won't do. However, not every listening activity can be beneficial to language students because our response to the message we hear might either be passive or active.

Passive listening is not much different from hearing. For instance, we have all found ourselves in situations where our minds drift, we lose our motivation in listening, and we consider the information we hear to be "a background noise," or we pretend that we're listening just to be polite. We think that we are listening, but in fact we are simply letting the information go past our brain.

Active listening implies listening with a purpose. We might listen to gain information from the speaker—not just to "fill in the awkward silence." When listening actively, we obtain directions, pay attention to details, solve problems, get to know people, share interests, feelings, emotions, etc.

There are three different levels of Active Listening:

Level I — Internal Listening. When a person uses Internal Listening, they ask how the topic affects them personally. The listener looks out for their own self interests and does not think in terms of anyone else.

Level II — Focused Listening. When a person reaches this level, they are focused on putting themselves in the mind of the speaker.

Level III — Global Listening. When a person enters Level III they build on Level II, in order to pick up on the physical and environmental indicators from the person speaking and from their surrounding.

The Agilist needs to make extensive use of a wide range of facilitation methods. It is not critical that you know each of these techniques for the exam. Instead, focus on the goals, rules, and timing as well as on how the use of facilitation methods helps the team deliver business results.

Agilists need to understand how globalization, culture and team diversity impact the success or failure of the project. Globalization is the process of an organization spreading out throughout the world. As the team becomes more and more disparate, it becomes more and more difficult to deliver business results. Culture is another aspect of stakeholder development that impacts project success. The more diverse the organization is, the more difficult it is for the team to deliver business results. Team diversity refers to how different the team members are. The more disparate the team is, the more conflict the team is likely to experience. The more distributed the team is, the more they are to likely to experience conflict as well. This brings us to the concepts surrounding conflict resolution.

Conflict Resolution No matter how hard the Agilist tries, they are guaranteed to experience differences of opinions. A conflict is simply a disagreement between two parties. The existence of a conflict, however, is not seen as a negative. It is how the conflict is resolved that determines whether it is positive or negative. There are five possible



Page 230

Slide 242

Slide 243

approaches to resolving a conflict. These are referred to as conflict resolution modes. They include the following:

Withdraw — Often referred to as the ostrich approach. This approach only offers temporary resolution to the conflict because it represents a situation where one party refuses to engage with the other about the conflict. Of course, this resolves nothing but the immediate confrontation. This is only a temporary solution!

Smoothing — Smoothing, or the kumbaya approach, is also a temporary solution to conflict. In this approach both parties engage with each other and make each other feel better, but they refuse to discuss the issue which caused the conflict. In this resolution mode, the person smoothing cares a lot about the other party but does not care about the issue.

Compromising — Compromise is the first conflict resolution mode that provides a permanent solution. However, it is also considered suboptimal because compromise is all about both parties finding the solution with which they can live. They are not interested in finding the best solution. Therefore neither party is totally satisfied. The two parties care a medium amount for the other party and a medium amount about the issue.

Forcing — When someone uses forcing to resolve a conflict they make the other party accept their solution to the issue. In this mode, the person doing the forcing has a high regard for the issue but a low regard for the other party.

Problem Solving — Problem solving is also referred to as confronting. This is the preferred mode to resolve any conflict. When they are engaged in problem solving, both parties have a high regard for each other and for the issue being discussed. The parties are more concerned about finding the correct solution than about having their own solution win the day.

Another conflict resolution model is the Speed B. Leas Conflict Model. Speed Leas is a nationally known consultant to religious organizations and an educator of church leaders, including pastors, laity, and church executives. Since 1967 he worked full-time as a teacher and consultant to ecclesiastical groups throughout the U.S. and Canada. He has an extensive background as a management consultant to churches and synagogues and has earned a special reputation as an authority on conflict. His model establishes five levels that focus on the nature of the conflict itself, rather than how it is resolved.

Level I — Problem to Solve. This level is characterized by the team openly sharing information and displaying consistent collaboration. The team uses open, fact-based language to communicate with one and other. There are a number of characteristics used to describe the atmosphere and environment. These include people having different opinions or misunderstandings without it destroying the team. Often the team has conflicting goals or values. Although the team has conflicts no one is uncomfortable with these conflicts, and the situation is not emotionally charged.

Level II — Disagreement. The second level in Leas’ model is characterize by personal protection trumping the resolution of the conflict. In this situation,



Page 231

team members communicate in a guarded manner that is often unclear and open to interpretation. The atmosphere and environment at this level is defined by the fact that self-protection has become important. Team members at this level tend to distance themselves from the debate, and many discussions happen off-line outside the team environment. Often good-natured joking changes into half-joking barbs.

Level III — Contest. At this level, winning trumps resolving the conflict. Here the team has become a lot more concerned about the outcome than each other. Communication includes lots of personal attacks, and the atmosphere or environment is highly charged because most of the team members are focused on winning. This forces individuals to take sides and blame others when things don’t work out as planned.

Level IV — Crusade. Leas’ fourth level transitions the team from simply winning to protecting one’s own group. Here, people are either part of your group or they are the enemy. People hold the a ideological position of us versus them, and this creates an environment where resolving the situation is not good enough. Team members must protect the members of their own team because they believe the people “on the other side” will not change and need to be removed.

Level V — World War. This level is almost rabid. The battle cry is “Destroy the other side!” There is little or no communication between the two sides. In many cases the combatants must physically be separated because physical violence becomes possible. Unfortunately, no constructive outcome is possible.

Participatory Decision Models Once the team is gathered and is required to engage the stakeholders, a key issue they will face is getting decisions from these stakeholders. This is especially true when they discuss requirements. Imagine a room full of 10 to 20 stakeholders or more, all of whom want to have a voice in the project requirements. How is the team going to decide what is included in the project and what is not? Engaging the stakeholders in a positive manner requires active participation by the customer. With such large groups this can be difficult and can require some form of decision model or some methodology—of which there are many. Here are the most common examples you might see on the exam.

Simple Voting — This is the easiest technique. It requires the facilitator to simply take a vote about each topic. This can be done with written secret ballots or by allowing the stakeholders to simply hold their hands up.

Thumbs Up / Down / Sideways — This is a slight modification of the simple voting where instead of stakeholders holding a hand up when asked to vote, they are asked to indicate whether the approve the decision (thumbs up), are just OK with the decision (Thumb held sideways), or if they are against the decision (thumbs down).

Slide 244



Page 232

Slide 245

Highsmith’s Decision Spectrum — Using this model, team members are asked to indicate where they feel about the decision at hand on a spectrum from “fully in favor” through “mixed feelings” to “No, veto.” This is an effective model because it allows people to indicate support for a decision, and at the same time air their reservations. Giving people an opportunity to register their concern is an important component of achieving the agreement necessary to go forward, while respecting dissenting views and keeping everyone engaged. People who indicate that they are not entirely in favor are then invited to share the concerns. Often it is the case that just being able to register their reservations is enough for people to feel comfortable committing to a new direction. The spectrum can be created on a whiteboard with tape and permanent markers and then easily reused for multiple decision making sessions.

Fist-of-Five Voting — Fist to five, also called fist of five, is a technique used by agile software development teams to poll team members and help achieve consensus. Fist to five is similar to thumbs up, thumbs down or thumbs sideways. To use the technique, the team facilitator restates an action that the group may make and asks the team to show their level of support. Each team member responds by holding up a closed fist or the number of fingers that corresponds to the level of support. If a team member holds up fewer than three fingers, she is given the opportunity to state her objections and the team may respond. The facilitator continues the fist to five process until the team achieves consensus (which is when everyone holds up three or more fingers) or agrees to move on to the next issue.

Closed Fist - No. A closed fist is a way to block consensus. 1 Finger - I have major concerns. 2 Fingers - I would like to discuss some minor issues. 3 Fingers - I’m not in total agreement but I feel comfortable enough to

let this proposal pass without further discussion. 4 Fingers - I think it’s a good idea and will work for it. 5 Fingers - It’s a great idea and would like to take the lead when we

implement it.

Management vs. Leadership Agile is consistent in distinguishing between two very important but different aspects of project management: management and leadership. Of the two, Agile emphasizes the importance of leadership. While management is necessary, leadership is absolutely critical. Sometimes these terms are used as synonyms, but they are not the same. Management is about controlling tasks and things. It is about focusing on achieving efficiency and ensuring that the right things are done. Management is about working to achieve speed and to control the team’s practices. It is a set of practices based on a command and control mentality. Leadership, on the other hand, is all about people and relationships. The goal of the leader is to empower people and to find every possible way to help the team become more effective. Leaders help the team find their direction and establish guiding principles. The leader often acts as a facilitator, helping the team to communicate.



Page 233

Servant Leadership The next concept an Agilists must learn is Servant leadership, which is a philosophy and set of practices that enriches the lives of individuals, builds better organizations, and ultimately creates a more just and caring world. The phrase “servant leadership” was coined by Robert K. Greenleaf in The Servant as Leader, an essay that he first published in 1970. In that essay, Greenleaf said:

“The servant-leader is servant first… It begins with the natural feeling that one wants to serve, to serve first. Then conscious choice brings one to aspire to lead. That person is sharply different from one who is leader first, perhaps because of the need to assuage an unusual power drive or to acquire material possessions…The leader-first and the servant-first are two extreme types. Between them there are shadings and blends that are part of the infinite variety of human nature.”

“The difference manifests itself in the care taken by the servant-first to make sure that other people’s highest priority needs are being served. The best test, and most difficult to administer, is: Do those served grow as persons? Do they, while being served, become healthier, wiser, freer, more autonomous, more likely themselves to become servants? And, what is the effect on the least privileged in society? Will they benefit or at least not be further deprived?”

A servant-leader focuses primarily on the growth and well-being of people and the communities to which they belong. While traditional leadership generally involves the accumulation and exercise of power by one at the “top of the pyramid,” servant leadership is different. The servant-leader shares power, puts the needs of others first and helps people develop and perform as highly as possible.

Robert Greenleaf recognized that organizations as well as individuals can be servant-leaders. Indeed, he had great faith that servant-leader organizations could change the world. In his second major essay, “The Institution as Servant,” Greenleaf articulated what is often called the “credo.” There he said:

“This is my thesis: caring for persons, the more able and the less able serving each other, is the rock upon which a good society is built. Whereas, until recently, caring was largely person to person, now most of it is mediated through institutions – often large, complex, powerful, impersonal; not always competent; sometimes corrupt. If a better society is to be built, one that is more just and more loving, one that provides greater creative opportunity for its people, then the most open course is to raise both the capacity to serve and the very performance as servant of existing major institutions by new regenerative forces operating within them.”

12 Principles for Leading Agile Projects The final principle to cover within Stakeholder Engagement is the 12 principles for leading Agile teams as described by Lyssa Adkins. She outlines 12 different principles that are key to being a successful Agile leader.

Slide 246-249

Slide 250



Page 234

Learn the team members’ needs — Outstanding Agile leaders know that they need to take the time to learn about their team, and to really understand what not only drives the team, but also what they truly need.

Learn the project’s requirements — A great Agile leader takes the time to really understand the needs of the business. Only by understanding the needs of the business can everyone else’s needs be met.

Acts for the simultaneous welfare of the team and the project — A great Agile leader always puts the needs of the team and the project together first above their own. This item is all about ensuring that the team does not become unbalanced. The project cannot become more important than the team. When there is an imbalance the team will eventually burn out.

Create an environment of functional accountability — Each member of the team has to be accountable to every other member of the team and to the organization as a whole.

Have a vision of the completed project — One of the things that separates Agile leaders from others is that they are able to take a strategic approach to the project. They are able to see how the project fits into the greater organization.

Use the project vision to drive your own behavior — Agile leaders understand where the project is trying to go and how the customer intends to use the product or service of the project. They then use that information to drive their own behavior.

Serve as the central figure in successful team development — Be careful with this concept. It does not mean you are in charge, or that the resources somehow report to you. Instead, it focuses you on your critical role as a facilitator.

Recognize team conflict as a positive step — Many leaders a scared of conflict, or view it as a negative. Successful leaders understand that conflict is a natural part of the process. The key is how the team deals with the conflict. Great teams use problem solving to address their conflicts.

Manage with an eye toward ethics — When everyone in the organization is watching, doing the right thing and holding yourself to a high standard is easy. The question is, what do you do when no one is watching and you could completely get away with doing something that is below that high standard. A great leader always thinks about the ethics of what they do, and chooses the high road.

Remember that ethics is not an afterthought, but an integral part of our thinking — Ethics must be front and center in every decision the leader and the team make. Only by constantly making ethics a core part of the decision making process can an Agilist ensure transparency.



Page 235

Take time to reflect on the project — No one ever gets everything right. There is always something that can be learned. The best way for learning to occur is for the team to slow down and take time to reflect on what caused things to happen.

Develop the trick of thinking backwards—Thinking backwards is the process of starting with the desired end-state, and then stepping back through the process to determine the most effective way of getting to that end point.

Before continuing to the next chapter, take the time to complete the following quiz. Make sure you score at least 90% before you move on.



Page 236

Exercise 8—Stakeholder Engagement

Stakeholder Engagement Exercise 1. The team is discussing why they need to conduct periodic reviews with the business

stakeholders. Which of the following is NOT a commonly cited reason?

A. Periodic reviews help ensure the team is knowledgeable about stakeholder's interests and needs.

B. Periodic reviews help to empower the business stakeholders to communicate throughout the organization about the project.

C. Periodic reviews help ensure the unimpeded flow of information and value throughout the project.

D. Periodic reviews ensure the right stakeholders are making key feature and product decisions throughout the project lifecycle.

2. Which of the following is NOT a common task found used in managing stakeholder expectations?

A. Provide forecasts in order to allow stakeholders to plan effectively. B. Establish transparency of all budgets and strategic components with all stakeholders. C. Establish and maintain a shared understanding of success criteria, deliverables, and

acceptable trade-offs with key stakeholders. D. Establish a shared vision of the various project increments.

3. Which of the following represent a quick, simple, and inexpensive tool you might use to represent a new website?

A. Wireframes B. Venn diagrams C. Object models D. Ishikawa diagrams

4. Which of the following is NOT a reason to use wireframes?

A. Wireframes are cheap. B. Wireframes allow the team to accurately present highly complex solutions. C. Wireframes represent rough representations of the system. D. Wireframes represent a low fidelity solution.

5. Which of the following is often referred to as archetypal descriptions of a system user?

A. Wireframes B. User stories C. Visualizations D. Personas

6. Which of the following statements concerning personas is NOT true?

A. Personas are written descriptions of system users. B. Personas are archetypal description of a system users. C. Personas represent real people. D. Personas are both tangible and actionable.

7. Which of the following statements about personas is true?

A. Personas are used to help the team generate focus towards who the system's users are and what they really want.

B. Personas are not actionable. C. Personas represent real people. D. Personas are often used to replace traditional requirements development processes.



Page 237

8. Who first introduced personas to agile development?

A. Mike Cohn B. Alan Cooper C. Lyssa Adkins D. Ken Schwaber

9. Why were user stories originally created?

A. User stories were created as the primary vehicle for defining features or work packages within Scrum.

B. User stories represent multiple rows combined on the product backlog. C. User stories represent the perspective of the developer. D. User stories allow the team to get an specific time estimate it will take to development

the feature.

10. Which of the following represents the correct form of the user story?

A. As a function I must produce the specific result. B. If I produce this result I may success criteria. C. As a role, I need to function so that I may success criteria. D. As a job, I need to complete my function so that I may achieve.

11. Which of the following is NOT key to a well formed user story?

A. Each user story must be testable. B. Each user story must contain acceptance criteria. C. User stories must be written in the language of the business. D. User stories must represent key themes of the project.

12. Which of the following is NOT a key advantage of user stories?

A. User stories are very incomplete. B. User stories force developers and customers to speak. C. User stories provide critical, detailed information about deliverables. D. User stories better represent amorphous requirements, especially early in the project.

13. Which of the following is NOT one of the three Cs of user stories?

A. The card B. The cadence C. The conversation D. The confirmation

14. Which of a user story's three Cs is considered MOST important by agilists?

A. The card B. The cadence C. The conversation D. The confirmation

15. Which of the following is NOT part of the user story acronym INVEST?

A. Interconnected B. Negotiable C. Valuable D. Estimable



Page 238

16. Which of the following is NOT part of the user story acronym INVEST?

A. Testable B. Negotiable C. Significant D. Estimable

17. When creating non-functional or system-based stories which of the following represents the most common format?

A. As a ROLE, I need to FUNCTION so that I may SUCCESS CRITERIA. B. Given, When, Then C. If, Else, Then D. Whereas, Therefore, Then

18. The Definition of Done states that before a project can truly be considered complete it must be what?

A. Designed, developed, and demonstrated B. Defined, coded, and integrated C. Declared, defined, and developed D. Designed, coded, and fully tested

19. What is the process of improving the internal structure of an existing program's source code, while preserving its external behavior called?

A. Test-driven development B. Refactoring C. Design-build D. Object-oriented development

20. Which of the following is NOT a key benefit of refactoring defined by the Agile Alliance?

A. Refactoring improves objective attributes of code that correlate with ease of maintenance.

B. Refactoring encourages each developer to think about and understand key design decisions, in the context of collective code ownership.

C. Refactoring helps stakeholders understand key development components and architecture.

D. Refactoring favors the emergence of reusable design elements and code modules.

21. When agilists talk about refactoring they may be referring to all of the following EXCEPT:

A. A particular behavior-preserving transformation B. The extract method C. The introduce parameter D. Code rewriting

22. Refactoring in the absence of safeguards against introducing defects is considered risky. Examples of safeguards include all of the following EXCEPT:

A. Composite testing B. Automated unit tests C. Automated acceptance tests D. Type systems



Page 239

23. According to the Agile Alliance, which of the follow is representative of the beginning skill level of refactoring?

A. Knows and is able to remedy a broader range of "code smells". B. Can use some automated refactorings from the IDE. C. Can chain several refactorings to carry out a design intention, in awareness of the

dependencies between refactorings. D. Refactors continuously, rather than in sporadic and lengthy sessions.

24. According to the Agile Alliance, which of the follow is representative of the intermediate skill level of refactoring?

A. Is aware of the risks of regression from manual and automated refactorings. B. Is aware of code duplication and can remove it by refactoring. C. Knows and is able to remedy a broader range of "code smells." D. Applies refactorings to non-code elements such as database schema, documents, etc.

25. According to the Agile Alliance, which of the follow is NOT representative of the advanced skill level of refactoring?

A. Has an acute sense of code duplication and coupling. B. Applies refactorings to non-code elements such as database schema, documents, etc. C. Uses refactoring to guide large bodies of code toward design styles intentionally

chosen from a broad palette: object-oriented, functional, or inspired by known design patterns.

D. Can chain several refactorings to carry out a design intention, in awareness of the dependencies between refactorings.

26. When Agilists discuss the temperature of communication to what are they referring?

A. Communication temperature defines how the communication brings people together and helps promote a positive or negative feelings about whatever is being discussed.

B. The temperature of communication defines how angry the message makes the recipient.

C. The temperature of communication defines the level of emotional intensity displayed in the exchange between two parties.

D. Communication temperature defines the proximity in language, tone and intangibles between two parties when attempting to share complex information.

27. A senior executive in your organization is concerned about stakeholders having negative feelings about the communication the team is providing. Which of the following tool is likely to be most effective in addressing this concern?

A. Email B. Face-to-face communication C. Video conferencing D. Teleconferencing

28. Which of the following is NOT a common agile information radiator?

A. Burndown charts B. Burnup charts C. The product backlog D. A velocity tracking chart



Page 240

29. According to top expert Scott Ambler, when does the value of Agile modeling peak?

A. Early in the project lifecycle. B. Late in the project lifecycle. C. Whenever it is used. D. In the middle of the project lifecycle.

30. Which of the following is NOT a fundamental practice found in Agile modeling?

A. Creating several models in parallel. B. Applying the right artifact(s) for the situation. C. Iterating to another artifact to continue moving forward at a steady pace. D. Creating the product backlog.

31. Which of the following is NOT a common form of agile modeling?

A. A UML package diagram B. Physical data model C. Requirements document D. System use case template

32. In which level of active listening is it when the listener is focused on putting themselves in the mind of the speaker?

A. Level I B. Level II C. Level III D. Level IV

33. In which level of active listening is it when the listener is picking up on the physical and environmental indicators from and surrounding the person speaking?


34. Which of the following conflict resolution modes is the first to provide a permanent resolution to a conflict, but also runs the risk of not providing the optimal solution?

A. Smoothing B. Compromising C. Forcing D. Problem solving

35. Which of the following conflict resolution modes is considered optimal in MOST situations?

A. Smoothing B. Compromising C. Forcing D. Problem solving

36. What distinguishes the Speed B. Leas Conflict Model from other conflict tools?

A. Speed B. Leas defines the conflict itself instead of how to resolve it. B. Speed B. Leas defines more tools to resolve the conflict. C. Speed B. Leas defines fewer methods to resolve the conflict. D. Speed B. Lease defines specific roles that participants in conflicts assume.



Page 241

37. At what level of the Speed B. Leas Conflict Model is a team that is characterized by team members communicating in a guarded manner that is often unclear and open to interpretation. The atmosphere and environment at this level is defined by self-protection becoming important. Team members at this level tend to distance themselves from the debate, and many discussions happen off-line outside the team environment. Often good-natured joking changes and becomes half-joking barbs?


38. A what level of the Speed B. Leas Conflict Model is a team that is characterized by the team being focused on winning to protecting one’s own group? At this level, people are either part of your group or they are the enemy. This is a ideological position, us versus them that creates an environment where resolving the situation is not good enough. Team members must protect the members of their own team because they believe the people “on the other side” will not change and need to be removed.

A. Level II B. Level III C. Level IV D. Level V

39. A what level of the Speed B. Leas Conflict Model is a team that is characterized by the team being focused on the team being almost rabid as the battle cry is destroy the other side! When in this level there is little or no communication between the two sides. In many cases the combatants must physically be separated as physical violence becomes possible. Unfortunately, no constructive outcome is possible.

A. Level II B. Level III C. Level IV D. Level V

40. Which of the following is NOT a commonly used participatory decision model used in agile development?

A. Thumbs up / down / sideways B. Cockran's decision matrix C. Highsmith's decision spectrum D. Fist-of-five voting

41. When discussing the difference between management and leadership from an agile perspective which is emphasized by the agilist?

A. Management B. Agile management C. Leadership D. Agile leadership

42. According to Greenleaf, what is the primary focus of the servant-leader?

A. The growth and well-being of the people and the communities to which they belong. B. The education and development of the staff. C. The accumulation and exercise of power to benefit the team. D. The care of the members of your team.



Page 242

43. Which of the following is NOT one of Lyssa Adkins' 12 principles to be an agile leader?

A. Learn the team members' needs; Learn the project's requirements. B. Act for the simultaneous welfare of the team and the project. C. Begin with the end in mind. D. Create and environment of functional accountability.


A. Use the project vision to drive your own behavior. B. Serve as the central figure in successful team development. C. Recognize team conflict as a positive step. D. Establish clear lines of communication and governance.


A. Manage with an eye towards ethics; remember that ethics is not an afterthought, but an integral part of our thinking;.

B. Make planning a habit not a chore. C. Take time to reflect on the project D. Develop the trick of thinking backwards.



Page 243

Stakeholder Engagement Answers 1. Answer D. LGd course manual p. 214-215 - There are a lot of reasons why the team needs to

hold periodic reviews. However, the fact that the team is holding reviews does not ensure the best stakeholders are present and making feature decisions.

2. Answer B. LGd course manual p. 214-215 - The tasks grouped as manage stakeholder expectations include: Establish a shared vision of the various project increments (products, deliverables, releases, iterations) by developing a high level vision and supporting objectives in order to align stakeholders’ expectations and build trust. Establish and maintain a shared understanding of success criteria, deliverables, and acceptable trade-offs by facilitating awareness among stakeholders in order to align expectations and build trust. Provide transparency regarding work status by communicating team progress, work quality, impediments, and risks in order to help the primary stakeholders make informed decisions. Provide forecasts at a level of detail that balances the need for certainty and the benefits of adaptability in order to allow stakeholders to plan effectively.

3. Answer A. LGd course manual p. 216 - Wireframes represent quick, cheap and simple tool. In Agile parlance we refer to tools like these as low fidelity. They represent rough representations of the systems that help the team validate key concepts early in the design process. Simply put, wireframes are used for quick mockups of screens and interfaces typically used with thin client and client server technology.

4. Answer B. LGd course manual p. 216 - Wireframes represent quick, cheap and simple tool. In Agile parlance we refer to tools like these as low fidelity. They represent rough representations of the systems that help the team validate key concepts early in the design process. Simply put, wireframes are used for quick mockups of screens and interfaces typically used with thin client and client server technology.

5. Answer D. LGd course manual p. 216-217 - Personas are written descriptions of system users. They are referred to as archetypal descriptions of a user of the system. In this case, archetypal refers to a specific sample user that has characteristics that are very typical for the system users. However, the persona is NOT a real person.

6. Answer C. LGd course manual p. 216-217 - Personas are written descriptions of system users. They are referred to as archetypal descriptions of a user of the system. In this case, archetypal refers to a specific sample user that has characteristics that are very typical for the system users. However, the persona is NOT a real person. Simply put, a persona is grounded in reality.

7. Answer A. LGd course manual p. 216-217 - A persona is grounded in reality. They are used to help the team generate focus towards who the system’s users are and what they really want. One of the key aspects of personas is the fact that they are both tangible and actionable. Personas create a powerful likeness of a user that allows the developer to build functionality around the personas’ needs. However, this tool does not replace requirements.

8. Answer B. LGd course manual p. 216-217 - Personas where first introduced by Alan Cooper for software development projects. He argued that software must be designed for a specific person. In this way, personas differ from Use Cases.

9. Answer A. LGd course manual p. 218 - Originally created as the primary vehicle for defining features or Work Packages in Scrum, User Stories represent features written from the perspective of the end user. Each Story represents a single row or item in the Product Backlog. Hence, they are sometimes referred to as Product Backlog Items or PBIs. Because the User Stories represent the primary vehicle for defining the features on a project, there must be some way of creating estimates at the Story level.



Page 244

10. Answer C. LGd course manual p. 218 - User Stories always appear in the form of “As a ROLE, I need to FUNCTION so that I may SUCCESS CRITERIA. This single sentence or sometimes pair of sentences appear incredibly simplistic, but there are very powerful. User Stories are always written in the language of the business because the providing a primary bridging tool between developers and the customer. Additionally, each Story must provide acceptance criteria and must be testable.

11. Answer D. LGd course manual p. 218 - User Stories always appear in the form of “As a ROLE, I need to FUNCTION so that I may SUCCESS CRITERIA. This single sentence or sometimes pair of sentences appear incredibly simplistic, but there are very powerful. User Stories are always written in the language of the business because the providing a primary bridging tool between developers and the customer. Additionally, each Story must provide acceptance criteria and must be testable.

12. Answer C. LGd course manual p. 218 - The absence of too much detail is seen by Agilists as an advantage. Having or attempting to have too much detail in the early stages of the project often causes the team to focus on features and/or requirements that change or disappear as the project progresses. When this happens in non-Agile projects it often causes costs to dramatically increase without providing any benefit. This avoidance of detail allows the team to adapt and change the requirements as the project progresses. Finally, User Stories simply acknowledge the fact that all requirements are not known at the beginning of the project. Requirements the Agilist contend are amorphous, often poorly or misunderstood in the early phases of the project.

13. Answer B. LGd course manual p. 219 - The three Cs of user stories include: The Card — The brief description must have meaning to both the team and the product owner. It is the bridge between the developer and customer. The Conversation — This is the most important part. The card is not enough to write code. The card leads to a conversation to ensure understanding. The Confirmation — This is the success criteria. It gives us the high-level criteria against which the resulting feature will be tested.

14. Answer C. LGd course manual p. 219 - The Conversation — This is the most important part. The card is not enough to write code. The card leads to a conversation to ensure understanding.

15. Answer A. LGd course manual p. 219 - INVEST represents six steps every agilist must take to get the most out of User Stories. These items include: Independent, negotiable, valuable, estimable, small, and testable.

16. Answer C. LGd course manual p. 219 - INVEST represents six steps every agilist must take to get the most out of User Stories. These items include: Independent, negotiable, valuable, estimable, small, and testable.

17. Answer B. LGd course manual p. 220 - Another form of User Stories is the Given, When, Then format. This format is used for non-functional or system-based stories.

18. Answer D. LGd course manual p. 220 - The Definition of Done states that before anything can truly be declared complete it must be designed, coded and fully tested. Each of these steps represent small incremental steps necessary in any software project.

19. Answer B. LGd course manual p. 221 - The Definition of Done states that before anything can truly be declared complete it must be designed, coded and fully tested. Each of these steps represent small incremental steps necessary in any software project.

20. Answer C. LGd course manual p. 221 - According to the Agile Alliance, refactoring is done to provide the project a number of key benefits including: Refactoring improves objective attributes of code (length, duplication, coupling and cohesion, cyclomatic complexity) that correlate with ease of maintenance. Refactoring helps code understanding. Refactoring encourages each developer to think about and understand key design decisions, in the context of collective code ownership. Refactoring favors the emergence of reusable design elements (such as design patterns) and code modules.



Page 245

21. Answer D. LGd course manual p. 221 - The noun "refactoring" refers to one particular behavior-preserving transformation, such as "Extract Method" or "Introduce Parameter". Refactoring does not mean simply rewriting code, fixing bugs or improving observable aspects of software such as its interface.

22. Answer A. LGd course manual p. 221 - Refactoring does not mean simply rewriting code, fixing bugs or improving observable aspects of software such as its interface. Refactoring in the absence of safeguards against introducing defects (i.e. violating the "behavior preserving" condition) is risky. Safeguards include aids to regression testing including automated unit tests or automated acceptance tests, and aids to formal reasoning such as type systems.

23. Answer B. LGd course manual p. 221 - The beginning level of refactoring includes concepts such as: Knows the definition of "refactoring". Can use some automated refactorings from the IDE. Can perform some refactorings by hand. Is aware of the risks of regression from manual and automated refactorings. Is aware of code duplication and can remove it by refactoring.

24. Answer C. LGd course manual p. 221 - The intermediate level of refactoring includes concepts such as: Knows and is able to remedy a broader range of "code smells". Can chain several refactorings to carry out a design intention, in awareness of the dependencies between refactorings. Refactors continuously, rather than in sporadic and lengthy sessions.

25. Answer D. LGd course manual p. 221 - The advanced level of refactoring includes concepts such as: Has an acute sense of code duplication and coupling. Applies refactorings to non-code elements such as database schema, documents, etc. Uses refactoring to guide large bodies of code toward design styles intentionally chosen from a broad palette: object-oriented, functional, or inspired by known design patterns.

26. Answer A. LGd course manual p. 222 - When Agilists refer to communication temperature they are talking about how the communication brings people together and helps promote a positive or negative feeling about whatever is being discussed. Warm communication helps the participants have a positive feeling about the message. Cold communication causes the participants to have the opposite feeling, negative. The temperature of the communication impacts its overall effectiveness.

27. Answer B. LGd course manual p. 222 - The temperature of the communication impacts its overall effectiveness. The warmer the communication the more effective it is. Based on these two axis, the graph generates two curves. The first curve represents naturally cold communication methods such as old-fashioned paper documents, audio recordings, or video recordings. All of these techniques struggle because they lack the ability to provide question and answer time. At the bottom of the warm curve is email. Although it does provide a method to get questions answered, it encounters delays and often suffers from misinterpretation. The most effective way to communicate is always face-to-face because each party can see the other’s expression and respond.

28. Answer C. LGd course manual p. 222 - Information Radiators represent a number of highly visible methods to display information including large charts, graphs, and summaries of project data. There are sometimes referred to as visual controls according to famed Agilist Alistair Cockburn. This course has already introduced a number of information radiators such as Burndown or Burn-Up Charts. However, there are a number of other visualizations used in Agile Development such as Average Cycle Time Charts, Cumulative Flow Diagrams, Earned Value Management Systems Diagrams, or a Velocity Tracking Chart.

29. Answer A. LGd course manual p. 222 - To get the highest value focus on the value Agilists get from the practice. Scott Ambler, a top expert in Agile Modeling argues that Agile Modeling’s value peaks earlier than traditional theory leads us to believe.

30. Answer D. LGd course manual p. 223 - To model in an agile manner you will apply AM's practices as appropriate. Fundamental practices include creating several models in parallel, applying the right artifact(s) for the situation, and iterating to another artifact to continue moving forward at a steady pace.



Page 246

31. Answer C. LGd course manual p. 223 - The list of potential agile models is huge, but a traditional requirements document does not appear on it.

32. Answer B. LGd course manual p. 228- There are three different levels of Active Listening. Level I — Internal Listening. When a person uses Internal Listening the ask how the topic being discussed is going to affect them personally. The listener is looking out for their own self interests and not thinking in terms of anyone else. Level II — Focused Listening. When a person reaches this level they are focused on putting themselves in the mind of the speaker. Level III — Global Listening. When a person enters Level III they build on Level II to pick up on the physical and environmental indicators from and surrounding the person speaking.

33. Answer C. LGd course manual p. 228 - There are three different levels of Active Listening. Level I — Internal Listening. When a person uses Internal Listening the ask how the topic being discussed is going to affect them personally. The listener is looking out for their own self interests and not thinking in terms of anyone else. Level II — Focused Listening. When a person reaches this level they are focused on putting themselves in the mind of the speaker. Level III — Global Listening. When a person enters Level III they build on Level II to pick up on the physical and environmental indicators from and surrounding the person speaking.

34. Answer B. LGd course manual p. 229 - Compromise is the first conflict resolution mode that provides a permanent solution. However, it is also considered suboptimal because compromise is all about both parties finding the solution with which they can live. They are not interested in finding the best solution. Therefore neither party is totally satisfied. The two parties care a medium amount for the other party and a medium amount about the issue.

35. Answer D. LGd course manual p. 229 - Problem solving is also referred to as confronting and is the preferred mode to resolve any conflict. When problem solving, both parties have a high regard for each other and for the issue being discussed. The parties are more concerned over finding the correct solution rather than just having their solution.

36. Answer A. LGd course manual p. 229 - Speed Leas is a nationally known consultant to religious organizations and an educator of church leaders, including pastors, laity, and church executives. Since 1967 he worked full-time as a teacher and consultant to ecclesiastical groups throughout the U.S. and Canada. He has an extensive background as a management consultant to churches and synagogues and has earned a special reputation as an authority on conflict. His model establishes five levels that describe the conflict itself instead of how it is resolved.

37. Answer B. LGd course manual p. 229 - The Speed B. Leas Conflict Model establishes five levels that describe the conflict itself instead of how it is resolved. Level II is called Disagreement and is defined as: The second level Leas’ model is characterize by personal protection trumping the resolution of the conflict. Team members communicate in a guarded manner that is often unclear and open to interpretation. The atmosphere and environment at this level is defined by self-protection becoming important. Team members at this level tend to distance themselves from the debate, and many discussions happen off-line outside the team environment. Often good-natured joking changes and becomes half-joking barbs.

38. Answer C. LGd course manual p. 229 - The Speed B. Leas Conflict Model establishes five levels that describe the conflict itself instead of how it is resolved. Level IV — Crusade. Leas’ fourth level transitions the team from simply winning to protecting one’s own group. People are either part of your group or they are the enemy. This is a ideological position, us versus them that creates an environment where resolving the situation is not good enough. Team members must protect the members of their own team because they believe the people “on the other side” will not change and need to be removed.

39. Answer D. LGd course manual p. 229 - The Speed B. Leas Conflict Model establishes five levels that describe the conflict itself instead of how it is resolved. Level V — World War. This level is almost rabid as the battle cry is destroy the other side! There is little or no communication between the two sides. In many cases the combatants must physically be separated as physical violence becomes possible. Unfortunately, no constructive outcome is possible.



Page 247

40. Answer B. LGd course manual p. 229 - There are many different decision models a team might use. The most common you might see on the exam include simple voting, thumbs up / down / sideways, Highsmith's decision spectrum, and fist-of-five voting.

41. Answer C. LGd course manual p. 231 - Agile emphasizes the importance of leadership. While management is necessary, leadership is absolutely critical. Sometimes these terms are used as synonyms, but they are not the same. Management is about controlling tasks and things. It focuses on achieving efficiency, and ensuring that the right things are done. Management works to achieve speed and control the team’s practices. It is a set of practices based on a command and control mentality. Leadership is all about people and relationships. The goal of the leader is to empower people, to find every possible way to help the team become more effective. Leaders help the team find their direction and establish guiding principles. The leader often acts as a facilitator helping the team to communicate.

42. Answer A. LGd course manual p. 232 - A servant-leader focuses primarily on the growth and well-being of people and the communities to which they belong. While traditional leadership generally involves the accumulation and exercise of power by one at the “top of the pyramid,” servant leadership is different. The servant-leader shares power, puts the needs of others first and helps people develop and perform as highly as possible.

43. Answer C. LGd course manual p. 232 - Lyssa Adkins outlines 12 different principles that are key to being a successful Agile leader. These include: Learn the team members' needs; Learn the project's requirements; Act for the simultaneous welfare of the team and the project; create and environment of functional accountability; have a vision of the completed project; Use the project vision to drive your own behavior; Serve as the central figure in successful team development; recognize team conflict as a positive step; manage with an eye towards ethics; remember that ethics is not an afterthought, but an integral part of our thinking; take time to reflect on the project; and develop the trick of thinking backwards.

44. Answer D. LGd course manual p. 232 - Lyssa Adkins outlines 12 different principles that are key to being a successful Agile leader. These include: Learn the team members' needs; Learn the project's requirements; Act for the simultaneous welfare of the team and the project; create and environment of functional accountability; have a vision of the completed project; Use the project vision to drive your own behavior; Serve as the central figure in successful team development; recognize team conflict as a positive step; manage with an eye towards ethics; remember that ethics is not an afterthought, but an integral part of our thinking; take time to reflect on the project; and develop the trick of thinking backwards.

45. Answer B. LGd course manual p. 232 - Lyssa Adkins outlines 12 different principles that are key to being a successful Agile leader. These include: Learn the team members' needs; Learn the project's requirements; Act for the simultaneous welfare of the team and the project; create and environment of functional accountability; have a vision of the completed project; Use the project vision to drive your own behavior; Serve as the central figure in successful team development; recognize team conflict as a positive step; manage with an eye towards ethics; remember that ethics is not an afterthought, but an integral part of our thinking; take time to reflect on the project; and develop the trick of thinking backwards.

Chapter 7 — Team Performance


Page 248

Slide 252

Slide 253

Page 248

Boosting Team Performance

Team Performance Overview Team performance describes how well the project team is working together to achieve a desired project goal. Boosting that performance must be a central goal of every Agile leader. The domain is broken into three groupings of nine tasks that include:

Team Formation — The first thing every project needs is a team to execute it. The PMI-ACP Exam calls this process Team Formation, and it is where we discuss all the aspects of bringing people together to truly become a team and to deliver the project. This area includes two tasks.

Cooperate with the other team members to devise ground rules and internal processes in order to foster team coherence and strengthen team members’ commitment to shared outcomes.

Help create a team that has the interpersonal and technical skills needed to achieve all the project objectives in order to create business value with minimal delays.

Team Empowerment — This area covers the tasks necessary to give the team the authority and control they need to succeed.

Encourage the team members to become generalizing specialists in order to reduce team sizes and bottlenecks, and to create a high-performing cross-functional team.

Contribute to self-organizing work by empowering others and encouraging emerging leadership in order to produce effective solutions and to manage complexity.

Continuously discover team and personal motivators and de-motivators in order to ensure that the team morale is high and the team members are motivated and productive throughout the project.

Team Collaboration and Commitment — Once the team is formed and has the authority they need to execute the project, it is critical that an Agile leader ensure that the team constantly works well together and remains committed to the project.

Facilitate close communication both within the team and between the team and the appropriate external stakeholders through co-location or the use of collaboration tools in order to reduce miscommunications and rework.

Reduce the team’s distractions in order to establish a predictable work outcome and to optimize the value the team delivers.

Participate in aligning the team with the project’s goals by sharing the ownership for the project vision and ensuring that the team understands how their objectives fit into the overall goals of the project.

Encourage the team to measure their velocity by tracking and measuring their actual performance in previous iterations or releases, so



Page 249

Slide 254-255

that members can gain a better understanding of their capacity and can create more accurate forecasts in the future.

COCOMO The first tool in our effort to boost team performance is the Constructive Cost Model which was originally created based on a correlation study that looked at the input variables and total project costs of thousands of software projects. The results of this study are used as an estimating technique. The algorithmic model was originally developed by Barry Boehm in 1981 as part of his book Software Engineering Economics. The model uses basic regression analysis based on historical data in order to estimate effort, cost, and scheduling on software projects.

Boehm’s original study examined 63 projects at TRW Aerospace where Boehm was the Director of Software Research and Technology. All of the projects in the study were managed using a waterfall model. The projects ranged in size from 2,000 to 100,000 lines of code using assembly and PL/I. Literature refers to this edition of the model as COCOMO 81. In 1995, COCOMO II was developed, but it was not published until the year 2000 when it appeared in the book Software Cost Estimation with COCOMO II. The major difference between this and the previous version is that the second study is better suited for projects that make use of methodologies such as Agile.

The COCOMO model consists of a hierarchy of three versions. The initial level is called Basic COCOMO and is good for quick, early, rough order of magnitude, or ROM estimates of software costs, but its accuracy is limited due to its lack of factors to account for differences in project attributes. These are referred to as cost drivers. Intermediate COCOMO takes the Cost Drivers into account making it more accurate than Basic COCOMO. The third and final version is called Detailed COCOMO. It provides for the addition of project phases as a variable in the model.

The Basic COCOMO model gives estimates based on project size that are expressed as an estimate of the thousands of lines of code. These estimates use two measures, Source Lines of Code or SLOC and KLOC which represents Thousands of Lines of Code. The K simply refers to 1,000. COCOMO works with three types or classes of software projects:

Effort Applied (E) = ab(KLOC)bb [ person-months ]

Development Time (D) = cb(Effort Applied)db [months]

People required (P) = Effort Applied / Development Time [count]

where, KLOC is the estimated number of delivered lines (expressed in thousands) of code for project. The variables ab, bb, cb and db are defined in the table that appears to the right. Basic

Software Project ab bb cb db

Organic 2.4 1.05 2.5 0.38

Semi-Detached 3.0 1.12 2.5 0.35

Embedded 3.6 1.20 2.5 0.32



Page 250

CO2COMO is good for quick estimates of software costs. It does not account for differences in the hardware constraints, the personnel quality and experience, the use of modern tools and techniques, and so on.

Intermedia COCOMO computes software development effort as a function of program size and a set of "cost drivers" that includes a subjective assessment of product, hardware, personnel and project attributes. This extension considers a set of four "cost drivers," each with a number of subsidiary attributes:

Product attributes Required software reliability Size of application database Complexity of the product

Hardware attributes Run-time performance constraints Memory constraints Volatility of the virtual machine environment Required turnabout time

Personnel attributes Analyst capability Software engineering capability Applications experience Virtual machine experience Programming language experience

Project attributes Use of software tools Application of software engineering methods Required development schedule

Each of the 15 primary attributes receives a rating on a six-point scale that ranges from "very low" to "extra high" (in importance or value). An effort multiplier from the table below applies to the rating. The product of all effort multipliers results in an effort adjustment factor (EAF). Typical values for EAF range from 0.9 to 1.4. The formula for Intermediate COCOMO takes the form of E=ai(KLOC)(bi)(EAF) where E is the effort

Ratings

Cost Drivers Very Low Low Nominal High

Very High

Extra High

Product Attributes

Required software reliability 0.75 0.88 1.00 1.15 1.40

Size of application database 0.94 1.00 1.08 1.16

Complexity of the product 0.70 0.85 1.00 1.15 1.30 1.65

Hardware Attributes

Run-time performance constraints 1.00 1.11 1.30 1.66

Memory constraints 1.00 1.06 1.21 1.56

Volatility of the virtual machine environment 0.87 1.00 1.15 1.30

Required turnabout time 0.87 1.00 1.07 1.15

Personnel Attributes

Analyst capability 1.46 1.19 1.00 0.86 0.71

Applications experience 1.29 1.13 1.00 0.91 0.82

Software engineer capability 1.42 1.17 1.00 0.86 0.70

Virtual machine experience 1.21 1.10 1.00 0.90

Programming language experience 1.14 1.07 1.00 0.95

Project Attributes

Application of software engineering methods 1.24 1.10 1.00 0.91 0.82

Use of software tools 1.24 1.10 1.00 0.91 0.83

Required development schedule 1.23 1.08 1.00 1.04 1.10



Page 251

Slide 256

applied in person-months, KLoC is the estimated number of thousands of delivered lines of code for the project, and EAF is the factor calculated above. The coefficient ai and the exponent bi are given in the next table. The Development time D calculation uses E in the same way as in the Basic COCOMO.

Detailed COCOMO builds on the Basic and Intermediate models that came before. The difference is that the Detailed Model takes those variables and adds an assessment of the cost driver’s impact at each step of the project process. It is important to remember that this Detailed Model uses a Waterfall-type model. These Phase Sensitive effort multipliers are each used to help determine the amount of effort required to complete each phase. In detailed COCOMO, the whole software is divided in different modules and then we apply COCOMO in different modules to estimate effort and then to sum the effort. In detailed COCOMO, the effort is calculated as a function of program size and a set of cost drivers is given according to each phase of the software life cycle. A Detailed project schedule is never static.

The five phases of detailed COCOMO are:

Plan and requirement System design Detailed design Module code and test Integration and test Cost Constructive Model

Before leaving COCOMO, it is important to note that there are a number of other potential variables not listed above. The important thing to remember for the Exam is that COCOMO represents an equation-based method for estimating the cost and duration of a project based on a database of previously performed projects.

Adaptive Leadership

Adaptive leadership is a central tool to the Agilist. It is a framework of ideas that allows the individual and team to adapt and thrive in challenging environments. It is based on a process of gradual and meaningful change that must occur continually for the team to succeed. Adaptive Leadership requires the Agilist to determine which practices are essential to the future of the organization and which obstacles prevent the team from making the maximum use of those practices. The team must then determine how to remove the obstacles and then develop and test the next set of practices before they integrate the new practices into their environment.

The term Adaptive Leadership is based on the Harvard University research of Dr. Ron Heifetz and Marty Linsky. However, many other authors also make use of the term. Heifetz and Linsky describe a technical challenge as one that can be solved through additional expertise and information. Adaptive Challenges, on the

Software Project ai bi

Organic 3.2 1.05

Semi-Detached 3.0 1.12

Embedded 2.8 1.20



Page 252

Slide 257

other hand, are the problems that require change at the core of what people are doing, feeling, and thinking. Such challenges require a tailored approach, beyond calling in an expert. They require adaptive leadership. Famed Agilist Jim Highsmith, while working with the consulting firm Thought Works, wrote the book Adaptive Leadership—Accelerating Enterprise Agility. This book describes the topic of Adaptive Leadership within the framework of Agile Development. He contends that, “Creative leadership includes embracing ambiguity, taking risks that disrupt the status quo, instituting new management styles, and faster decision making. Building operating dexterity includes simplifying whenever possible, managing systemic complexity (standardization in some cases), and promoting a fast and flexible mindset.”

Highsmith further argues that leaders often forget or don’t understand the difficulty their staff has in transitioning to an Agile delivery model. Programmers have to change the way they do testing (a technical change) and how they interact more collaboratively with others (a social change). Product managers have to change their interactions with delivery teams—by increasing their availability, managing backlogs and engaging with the delivery team. These changes are often challenging. Adaptive leadership is the work of energizing, empowering and enabling teams to rapidly and reliably deliver business value by engaging with customers and continuously learning and adapting to a constantly changing environment. What many Agilists (or their executives and managers) haven’t realized is that the changes that leaders face are just as wrenching. Leaders face the same two challenges as delivery teams: doing different things, and behaving in different ways. They have also been forced to change their mental models about how best to improve performance. For example, just a few of the things adaptive leaders need to do are as follows:

Create an Agile performance management system Align agile transformation efforts to business strategy Determine operational, portfolio, and strategic agility aims Facilitate a decentralized, empowered, collaborative workplace Foster adaptable IT, product line, and product architectures Create an Agile proficiency evaluation framework

So how does one adapt and change in the chaotic environment described by Highsmith and other Agilists? Highsmith describes four specific models that help.

Purpose Alignment Model The first question in responding to turbulent change is “what’s important?” The question is easy to ask, hard to answer. One effective tool for doing so is the Purpose-Alignment Model (Pixton, Nickolaisen, Little, and McDonald, 2009). This model can be used at any level—strategy, project, and feature. The two dimensions are market differentiation (does this really make a difference) and mission criticality (is it something we have to do to succeed). For example, in most businesses, billing is mission critical (must be done) but not differentiating (having the best billing system won’t scare the competition). Usually you only need to match competitors billing systems (parity). In looking at potential



Page 253

Slide 258

adaptation initiatives, it’s important to first ask why and how it matters. One of the hardest things leaders do is choose. There are so many options today—this product/that product, onshore/offshore; bricks and mortar/internet, extensive marketing/word-of-mouth marketing, social networking/traditional networking, data center/cloud. The list of possibilities is endless. One of the things that distinguish effective leaders from ineffective leaders is choosing well. Models such as the Purpose-Alignment model can help. But the model doesn’t make decisions, leaders do.

The Short-Horizon Model Managers and executives tend to think in certain horizons— strategic, tactical, and operational. However, in a turbulent world the traditional timeframes for these horizons (a year for operational for example) are too long. A better, Short-Horizon model for responding quickly to opportunities and threats is the roadmap, release, and iteration model used by software delivery teams. Business initiatives can be planned and executed with this model. A roadmap targets large chunks of work onto a 6-18 month timeline. Within the roadmap, release plans—consisting of deployable chunks of work—are outlined in a 3 month timeline. At the lowest level are 2-week iterations, consisting of small, useful chunks of work that are planned within each release. If executives and managers want to be adaptive, they must shorten their working cycles just like Agile software deliverers do. “Yet time turns out to be a more important factor in organizational performance than traditional financial measurements. When you focus on time, you tend to get both greater responsiveness and lower cost.” (Denning, 2010)

The OODA Loop Model The third useful model in building adaptive mindsets and organizations is the OODA loop developed by US Air Force fighter pilot John Boyd. Boyd was an ace fighter pilot and had great influence in fighting strategy. His OODA loop shows the thinking process behind making lightning fast actions and responses to competitor’s action. The way the basic OODA Model is normally depicted (using simple arrows around in a circle) is somewhat deceptive, because the normal fast path is OODA (Observe, Orient, Decide and Act). But for really fast action, Boyd depended on his training and experience to guide him directly to action— thereby skipping the decision step. The decision step was usually performed after the fact, acting as a learning practice. Boyd also differentiated between observing and orienting. Observing was seeing reality without filters. Orienting applied the filters of culture, experience, new information, and analysis. In a turbulent environment, the importance of seeing reality without filters enhances the ability to identify opportunities and threats.

Satir Change Model The Satir Change Model is one of a number of useful ways to think about change. Highsmith likes this model because it emphasizes some key points:

Things get worse before they get better.



Page 254

Slide 259

People may give up on a change if it gets too bumpy. The ride from current performance to better performance is bumpy. Successful transitions require investments in both time and money. Trust and understanding are needed to overcome fear and resistance.

This model, and many others, seems to ignore the question, “Is this a good adaptation?” The entire process is geared to overcoming resistance, and resistance always has a negative connotation. But think about change for a minute. Environmental changes create both opportunity and danger. In any business, development organization, or project team there are many, many changes: market, economic, competitor, team member, business objectives, and so on. For any one of those changes there may be multiple possible adaptations. With hundreds of changes, large and small, and hundreds of possible adaptations to each—again, both large and small—how do we weed out the adaptations that are wrong choices? Maybe we should look at the Satir model not only from the negative perspective of overcoming resistance, but also from a positive perspective of helping us weed out the inappropriate adaptations while implementing the appropriate ones. We tend to think of change management—or maybe better called adaptation management—as managing our exceptions about the deviations from the norm. But maybe we should view adaptation as the normal and steady state—it sure seems that way in today’s business environment.

Tuckman Model Dr Bruce Tuckman published his Forming Storming Norming Performing model in 1965. He added a fifth stage, Adjourning, in the 1970s. The Forming Storming Norming Performing theory is an elegant and helpful explanation of team development and behavior (US spelling: behavior). Similarities can be seen with other models, such as the Tannenbaum and Schmidt Continuum, and Hersey and Blanchard's Situational Leadership® model, which were developed about the same time.

Tuckman's model explains that as the team develops maturity and ability, people establish relationships with each other and the leader changes her leadership style. The leader generally begins with a directing style, but then she moves through that to a style of coaching, then participating, then delegating, and arrives finally at an almost detached stage. At this point, the team may produce a successor leader and the previous leader can move on to develop a new team. This progression of team behavior and leadership style can be seen clearly in the Tannenbaum and Schmidt Continuum. The authority and freedom extended by the leader to the team increases while the control of the leader reduces. In Tuckman's Forming Storming Norming Performing model, Hersey's and Blanchard's Situational Leadership® model and in Tannenbaum and Schmidt's Continuum, we see the same leadership development represented in three ways.

Here are the features of each phase:

Forming — At this stage the team has a high level of dependence on the leader for guidance and direction. There is little agreement on the team’s aims,



Page 255

other than those received from the leader. Individual roles and responsibilities are unclear. The leader must be prepared to answer lots of questions about the team's purpose, objectives and external relationships. Processes are often ignored. Members of the team test the tolerance of the system and the leader. The leader directs others in this stage (similar to the 'Telling' mode in Situational Leadership®).

Storming — At this stage decisions don't come easily within the group. The team members vie for position as they attempt to establish themselves in relation to other team members and to the leader, who might receive challenges from team members. Clarity of purpose has increased from the prior stage, but plenty of uncertainties persist. Cliques and factions form and there may be power struggles. The team needs to be focused on its goals in order to avoid becoming distracted by relationships and emotional issues. Compromises may be required by team members in order to enable progress. The leader coaches others in this stage (similar to the 'Selling' mode in Situational Leadership®).

Norming — At this stage, the team forms agreements and develops a consensus. They respond well to facilitation by leader. Roles and responsibilities are clear and are accepted by everyone. Big decisions are made by group agreement. Smaller decisions may be delegated to individuals or small teams within group. Commitment and unity is strong among members. The team may engage in fun and social activities. The team discusses and develops its processes and working style. There is general respect for the leader and some of the leadership is shared with the team. In this stage, the leader facilitates and enables (similar to the 'Participating' mode in Situational Leadership®).

Performing — In this stage the team is more strategically aware; the team knows clearly why it is doing what it is doing. The team has a shared vision and is able to stand on its own feet with no interference or participation from the leader. At this stage there is a focus on over-achieving goals, and the team makes most of the decisions according to criteria that has been agreed upon with the leader. The team has a high degree of autonomy. Disagreements occur but now they are resolved within the team positively, and necessary changes to processes and structure are made by the team. The team is able to work towards achieving the goal—and also to attend to relationship, style and process issues along the way. Team members look after each other. The team requires that tasks and projects be delegated from the leader. The team does not need to be instructed or assisted. Team members might ask for assistance from the leader with personal and interpersonal development. In this stage, the leader delegates and oversees (similar to the 'Delegating' mode in Situational Leadership®).

Bruce Tuckman refined his theory around 1975 and added a fifth stage to the Forming Storming Norming Performing model - he called it Adjourning, which is also referred to as Deforming and Mourning. Adjourning is arguably more of an adjunct to the original four stage model rather than an extension. It views the



Page 256

group from a perspective beyond the purpose of the first four stages. The Adjourning phase is certainly very relevant to the people in the group and their well-being, but not to the main task of managing and developing a team which is clearly central to the original four stages.

Adjourning — At this stage the group is broken-up, hopefully when the task is completed successfully and its purpose has been fulfilled. Everyone can move on to new things, feeling good about what's been achieved. From an organizational perspective, recognition of and sensitivity to people's vulnerabilities in Tuckman's fifth stage is helpful—particularly if members of the group have been closely bonded and feel a sense of insecurity or threat from this change. Feelings of insecurity are natural for people with high 'steadiness' attributes (as regards the 'four temperaments' or DISC model) and with strong routine and empathy style (as regards the Benziger thinking styles model, right and left basal brain dominance).

Leadership & Interpersonal Skills Interpersonal skills aid the Agile Leader in developing exceptional performance. This is an area that requires study to memorize the basic terms and types of skills that can be used. Much of an Agilist’s interpersonal skills are tied to the areas of leadership, influencing, and effective decision making. To prepare for the exam it is important that you recognize how each of these components is viewed by PMI®. Leadership deals with the ability to motivate the project team to complete the required work. There are several potential leadership styles including:

Autocratic – These leaders solicit little or no informational input from their group and make managerial decisions solely by themselves.

Consultative Autocratic – These leaders solicit information from others but keep all substantive decision-making authority to themselves.

Consensus Manager – These leaders throw problems to the group and encourage the entire team to make the relevant decisions.

Shareholder Manager – (Poor Management) These leaders exchange little or no information with the group, yet the group is given the authority for the final decision.

There are also conflicting ideas about which leadership style is best. PMI® does not define a “best” style. However, two theories need to be reviewed for the exam. The first theory is the Leadership Contingency Model by Fielder. Fiedler’s contingency model postulates that the leader’s effectiveness is based on ‘situational contingency’ which is a result of interaction of two factors: leadership style and situational favorableness. It argues leadership is a function of the leader’s style aligning with the situation because there is no perfect leader. In this model, leadership is dependent on several key variables including the following: the team leader versus team member relations, the degree of task structure, and the position of power of the leader.

Slide 260

Slide 261



Page 257

Slide 262

Personal Power Formula

The second major theory is the Situational Leadership Theory. The Situational Leadership Theory is a leadership theory developed by Paul Hershey and Ken Blanchard. The Theory was first introduced as "Life Cycle Theory of Leadership.” The theory holds that there is no single “best” style of leadership. Effective leadership is task-relevant, and that the most successful leaders are those that adapt their leadership style to the maturity of the individual or group they are attempting to lead or influence. Effective leadership varies, not only with the person or group that is being influenced, but also with the task, job or function that needs to be accomplished. Within this theory there are four styles of leadership:

Telling — Telling is characterized by one-way communication in which the leader defines the roles of the individual or group and provides the what, how, why, when, and where to do the task.

Selling — In Selling the leader is still providing the direction but he or she is now using two-way communication and providing the socio-emotional support that will allow the individual or group to buy into the process.

Participating — Participating is shared decision making about aspects of how the task is accomplished. The leader is providing less task behaviors while maintaining high relationship behavior.

Delegating — In Delegating the leader is still involved in decisions but the process and responsibility has largely been passed to the individual or group. The leader stays involved to monitor progress.

Sources of Power How a leader gets their power is also important. There are several sources of power you must know about in order to prepare for the exam. These sources are not exclusive. In other words, the total power possessed by any leader is a combination of the power provided and is defined by the following equation:

Total Power = Positional Power + Personal Power

The specific types of power include:

Legitimate — Legitimate power is derived from the individual’s position in the organization. It is sometimes referred to as formal authority or power.

Coercive — Coercive power is a based upon intimidation. It can be physical or emotional but most commonly it is based on the person’s ability to impact one’s job security. It is predicated on fear.

Reward — This from of power involves offering positive reinforcement for desired behavior. One of the simplest examples is Pavlov’s dog experiment. Every time a bell was rung the dog got fed. Eventually the dog began salivating at the ringing of the bell. People will often act the same way. You can condition resources to respond in a desired fashion by providing positive reinforcement.

Expert — When using expert power, a leader will get resources to act in a desired way because the leader has some special skill or knowledge and the resource wants to impress the leader.



Page 258

Referent — When using referent power, a leader gains authority based upon who they know or with whom they are associated. A simple example is when the project leader is friends with the company’s president.

Emotional Intelligence Emotional Intelligence is the ability to identify and manage your own emotions and the emotions of others. Most scholars however, take the definition further. They argue that it requires people to discriminate between different emotions, to label them appropriately, and to use emotional information to guide thinking and behavior. Further, it also refers to a person’s ability to combine intelligence, empathy, and emotions to enhance one’s thought and understanding of interpersonal dynamics. It is generally said to include three skills:

The ability to have emotional awareness; to be able to identify your own emotions and those of others.

The ability to harness emotions and apply them to tasks like thinking and problems solving.

The ability to manage emotions—including the ability to regulate your own emotions, and the ability to cheer up or calm down another person.

Although there is general agreement on this definition, there is significant disagreement with regards to EI terminology and operationalizations.

The term first gained prominence in 1995 when Daniel Goleman released his book entitled Emotional Intelligence. However, this was not the first time the term was used. In 1964, Michael Beldoch used the term in a scholarly paper, as did N. Leuner in 1966. The first significant use of the term came in Wayne Payne’s 1985 doctoral thesis. Central to the themes we now consider key to EI was Howard Gardner’s 1983 Frames of Mind: The Theory of Multiple Intelligences that introduced the idea that traditional types of intelligence, such as IQ, fail to fully explain cognitive ability. His idea of multiple intelligences included both interpersonal intelligence (the capacity to understand the intentions, motivations and desires of other people) and intrapersonal intelligence (the capacity to understand oneself, to appreciate one's feelings, fears and motivations). In 1989 Stanley Geenspan put forward another model to describe EI and was followed by Peter Salovey and John Mayer later that year. All of this simply points to the fact that significant scholarly research was done on the topic before Goleman, but it was his work that became a best seller and popularized the term.

All of this research has led to several models, each with a slightly different take on the basic themes. Repeated studies have shown that people with high emotional intelligence have greater mental health, exemplary job performance, and more potent leadership skills. For example, Goleman’s research in his book, Working with Emotional Intelligence, indicated that EI accounted for 67% of the abilities deemed necessary for superior performance in leaders—and mattered twice as much as technical expertise or IQ. Other research, however, finds that the effect of EI on leadership and managerial performance is non-significant when ability and personality are controlled for, and that general intelligence correlates very closely with leadership. Markers of EI and methods of developing it have become



Page 259

Slide 263

more widely coveted in the past few decades. In addition, studies have begun to provide evidence to help characterize the neural mechanisms of emotional intelligence.

The different models of emotional intelligence have led to a significant industry in the construction and application of EI assessments. Most researchers who examine these different instruments agree that the differences can be significant.

Criticism of Emotional Intelligence centers on whether EI is a real intelligence, and whether or not it has incremental validity over IQ and the Big Five personality traits. Several scholarly reviews of the research supporting emotional intelligence argue that in most studies poor research methodology has exaggerated the significance of EI. This criticism has not slowed the significant use of EI in the workplace, as an attempt to create higher functioning leaders.

For the PMI-ACP® exam, it is important that you understand the basic concepts of EI and some of the fundamentals surrounding the three main models that exist.



Page 260

Ability Model

Mixed Model

Trait Model

Before describing the three models, it is important that you gain a solid understanding of the underpinnings of the concept.

The easiest way to understand Emotional Intelligence for most people is to focus on the Goleman Model and to think about a four-square grid. At the top of the grid are the two column headings, Self and Social. Self describes how we manage ourselves, while Social describes how we handle relationships. The two rows represent recognition of who the individual is and regulation, or what the individual does with respect to both themselves and others.

The first quadrant is Self-Awareness. This quadrant represents a person’s ability to recognize and understand your moods, emotions and drives as well as their effect on others. Leaders who are self-aware display self-confidence as well as a strong sense of emotional self-awareness. They also display the ability to accurately assess themselves. The self-aware leader has significant personal power.

The other quadrant that appears in the top row of the image is the Social, or Other Awareness. This is the ability to understand the emotional makeup of other people, and represents a skill in treating others according to their individual emotional reactions. It is highlighted by empathy, and by a situational awareness that is combined with a clear understanding of the organization and a strong service orientation. These two quadrants define who the individual truly is, according to Emotional Intelligence believers.

The bottom row of the grid represents regulation or management. It combines with both the self and others to define how we choose to manage ourselves and how we handle relationships. It begins with the quadrant Self-Management. This quadrant is about the ability to control or redirect disruptive impulses and moods. It is the propensity to suspend judgment and think before acting. There are a number of characteristics that highlight the exercise of self-management, most important of which is self-control, or the ability to control one’s own actions and prevent disruptive impulses from turning into action. Self-management also requires integrity, innovation and creativity. Leaders who possess strong self-management tend to take the initiative while displaying a bias towards action. Their achievement drive and their high level of realistic optimism combines with a high degree of resilience and stress management.

The final quadrant is Relationship Management. Proficiency in managing relationships and building networks is key to relationship management. It requires the leader to possess the ability to find common ground and build rapport with their team and the rest of the organization. There are a large number of characteristics that define a leader who is strong in Relationship Management. Skills such as the ability to influence others, communicate, manage conflicts, and inspire others combine with the ability to catalyze the organization for change and



Page 261

Slide 264

Slide 265

build bonds of trust with others in the organization while providing coaching and mentoring in a team-based environment.

Salovey and Mayer created the Ability-Based Emotional Intelligence Model. This model attempts to define EI within the boundaries of the standard criteria for a new intelligence. Based on their research, they redefined EI as, “The ability to perceive emotion, integrate emotion to facilitate thought, understand emotions and to regulate emotions to promote personal growth.” However, after pursuing further research, they again revised the definition to, “the capacity to reason about emotions, and of emotions, to enhance thinking. It includes the abilities to accurately perceive emotions, to access and generate emotions so as to assist thought, to understand emotions and emotional knowledge, and to reflectively regulate emotions so as to promote emotional and intellectual growth.”

The ability-based model views emotions as useful sources of information that help one to make sense of and navigate the social environment. The model proposes that individuals vary in their ability to process information of an emotional nature and in their ability to relate emotional processing to a wider cognition. This ability is seen to manifest itself in certain adaptive behaviors. The model claims that EI includes four types of abilities:

Perceiving Emotions — This is the ability to detect and decipher emotions in faces, pictures, voices, and cultural artifacts—including the ability to identify one's own emotions. Perceiving emotions represents a basic aspect of emotional intelligence because it makes all other processing of emotional information possible.

Using Emotions — This is the ability to harness emotions to facilitate various cognitive activities, such as thinking and problem solving. The emotionally intelligent person can capitalize fully upon his or her changing moods in order to best fit the task at hand.

Understanding Emotions — This is the ability to comprehend emotion language and to appreciate the complicated relationships between emotions. For example, understanding emotions encompasses the ability to be sensitive to slight variations between emotions, and the ability to recognize and describe how emotions evolve over time.

Managing Emotions — This is the ability to regulate emotions in both ourselves and in others. The emotionally intelligent person can harness emotions, even negative ones, and manage them to achieve their intended goals.

The current measure of Mayer and Salovey's model of EI, the Mayer-Salovey-Caruso Emotional Intelligence Test, or MSCEIT which is based on a series of emotion-based problem-solving items administered as a 30 to 45 minute exam.. Consistent with the model's claim of EI as a type of intelligence, the test is modeled on ability-based IQ tests. By testing a person's abilities on each of the four branches of emotional intelligence, it generates scores for each of the branches, which accumulate into a total score.



Page 262

Central to the four-branch model is the idea that EI requires attunement to social norms. Therefore, the MSCEIT is scored in a consensus fashion, with higher scores indicating higher overlap between an individual's answers and those provided by a worldwide sample of respondents. The MSCEIT can also be expert-scored, so that the amount of overlap is calculated between an individual's answers and those provided by a group of 21 emotion researchers.

Although promoted as an ability test, the MSCEIT is unlike standard IQ tests in that its items do not have objectively correct responses. Among other challenges, the consensus scoring criterion means that it is impossible to create items (questions) that only a minority of respondents can solve, because, by definition, responses are deemed emotionally "intelligent" only if the majority of the sample has endorsed them. This and other similar problems have led some cognitive ability experts to question the definition of EI as a genuine form of intelligence

The model introduced by Daniel Goleman focuses on EI as a wide array of competencies and skills that drive leadership performance. This concept is key to the Agilist, and is the model you should spend the most time studying. Goleman's model outlines five main EI constructs. If after reading through this discussion you still have questions, refer to "What Makes A Leader" by Daniel Goleman, found in The Best of Harvard Business Review, 1998. These five areas include:

Self-Awareness — This is the ability to know one's emotions, strengths, weaknesses, drives, values and goals, and to recognize their impact on others while using gut feelings to guide decisions.

Self-Regulation — This involves controlling or redirecting one's disruptive emotions and impulses and adapting to changing circumstances.

Social Skill — This involves managing relationships to move people in the desired direction.

Empathy — This means the ability to consider other people's feelings, especially when making decisions.

Motivation — This means being driven to achieve for the sake of achievement.

Goleman includes a set of emotional competencies within each construct of EI. Emotional competencies are not innate talents, but rather they are learned capabilities that must be worked on and can be developed to achieve outstanding performance. Goleman posits that individuals are born with a general emotional intelligence that determines their potential for learning emotional competencies.

Two measurement tools are based on the Goleman model:

The Emotional Competency Inventory or ECI — The ECI was created in 1999. The Emotional and Social Competency Inventory (ESCI), a newer edition of the ECI, was developed in 2007. The Emotional and Social Competency - University Edition (ESCI-U) is also available. These tools were developed by Goleman and Boyatzis and provide a behavioral measure of the Emotional and Social competencies.

Slide 266



Page 263

Slide 267

The Emotional Intelligence Appraisal or EIA — The EIA was created in 2001 and can be taken as a self-report or a 360-degree assessment.

The third model of Emotional Intelligence is the Trait Model. Konstantinos Vasilis Petrides proposed a conceptual distinction between an ability based model and a trait based model of EI, and has been developing the latter over many years in numerous publications. Trait based EI is "a constellation of emotional self-perceptions located at the lower levels of personality." In lay terms, Trait EI refers to an individual's self-perceptions of their emotional abilities. This definition of EI encompasses behavioral dispositions and self-perceived abilities, and is measured by self report. This is an improvement over the ability based model which refers to actual abilities, but which has proven highly resistant to scientific measurement. Trait EI should be investigated within a personality framework. An alternative label for the same construct is trait emotional self-efficacy. The trait EI model is general and subsumes the Goleman model.

There are many self-report measures of Emotional Intelligence used for the Trait Model, including the EQ-i, the Swinburne University Emotional Intelligence Test (SUEIT), and the Schutte EI model. None of these assess intelligence, abilities, or skills, but rather they are limited measures of trait emotional intelligence. One of the more comprehensive and widely researched measures of this construct is the Trait Emotional Intelligence Questionnaire (TEIQue), which was specifically designed to measure the construct comprehensively, and is available in many languages.

Although Emotional Intelligence is extremely popular within the Agile Community and elsewhere, not everyone supports its theories. Mayer, Roberts and Barsade have criticized Goleman’s model (in 2008) as nothing more than “pop Psychology.” The ability EI model has also been criticized in the research for lacking face and predictive validity in the workplace. However, in terms of construct validity, ability EI tests have a great advantage over self-report scales of EI, because they compare individual maximal performance to standard performance scales and do not rely on individuals' endorsement of descriptive statements about themselves.

Empowered Teams A key difference that Agilists draw between traditional linear processes and Agile Development is how power is managed. The Agilists contends that traditional projects are hindered by highly hierarchical power structures. These structures take autonomy away from the team. Agile Development works to restore that autonomy by empowering the team. Furthermore, Agilists are very specific about what Team Empowerment means. The most important element of this for them is that the team is self-directed. This refers to the idea that the team gets to guide their own actions and to decide which resources go to which activities, without undo influence from senior management. This is not some nefarious power grab. Empowered teams are required to act in the best interest of the team using a style of leadership referred to as Servant Leadership, that places the needs of the organization and the other team members ahead of their own. To be effective in



Page 264

this effort, the team must be appropriately sized. This means they must small—generally less than 20 people. The teams must also be committed to a common purpose, and must hold each other mutually accountable to the achievement of a common goal. The concept of mutual accountability refers to a situation where each team member expects themselves and others to act at all times in the best interest of the organization and project—as opposed to acting in a manner that focuses on personal interest.

High Performance Teams Agile Development demands that teams move beyond simply being empowered and focus on becoming high performing. This is not something that happens overnight or is easy. It begins by creating a shared vision for the team and by answering questions like “Why are we here?” Only when the entire team is striving to reach a common end can they truly achieve greatness. However, as they attempt to achieve greatness the team must also set realistic goals which the entire team believes they can achieve.

Many of the ideas surrounding High-Performance teams for the ACP exam comes from Frank LaFasto’s book Teamwork. LaFasto describes an Agile Team as being smaller than previous work teams. He specifies that the team needs to be 12 or fewer members so that each member can support the others. The smaller team size also ensures that the team can build its own unique strong identity. All of these factors allow the team to provide strong leadership within the organization.

Lyssa Adkins offers some additional insights about high performing teams. Many of the requirements are the same as the ideas presented by LaFasto and others. She argues that Agile teams must be self-organizing, they must be empowered to make their own decisions, and they must believe they can solve any problem. Everyone on the team must be committed to the team’s success. This commitment requires the team to own its decisions and commitments. According to Adkins, a great team uses trust to motivate themselves. Such teams are able to have a constant state of constructive conflict where the members of the team diverge due to the different ideas that are held by the different team members. But the team then comes together in consensus. However, even the best teams can struggle due to personality conflicts and other issues.

The Five Dysfunctions of a Team Best selling author Patrick Lencioni is often cited by

Slide 268-269



Page 265

Agilists to describe common dysfunctions experienced by even the best team. Lencioni identified five dysfunctions that are all too common. Every team has the potential to become dysfunctional because they are made up of people whose needs must be met. Understanding what the potential dysfunctions are and how to overcome them, are both critical steps to the success of any team.

Absence of Trust

Trust is the real foundation of team structure. Often team members don’t feel comfortable enough with the other members to fully disclose or share information that is needed for the team to succeed. Common indicators that your team is struggling with an absence of trust include:

Concealing weaknesses and/or mistakes

Not asking for help or providing constructive criticism

Not offering to help other team members outside their own areas

Jumping to conclusions

Failing to recognize one another’s capabilities

Holding grudges from previous meetings/projects

Dreading meetings and finding reasons to avoid each other

If you identify that you have an absence of trust within your team, here are some tools for getting the team back on track:

Personal Histories Exercise — Have each team member review what they did prior to becoming part of this team. This will allow everyone to better understand the strengths of each member.

Team Effectiveness Exercise — Use team building exercises to allow each member to gain personal insight into how he or she acts in the team setting.

Personality and Behavioral Preferences Profiles — Team Dimensions Profile.

360 Degree Feedback — These are reviews by team members, managers and subordinates on your performance. This will provide team members with valuable information about their performance.

These exercises and activities will not be the panacea for all problems. They are simply the first step for the team to recognize the problems that exist, and realize that they all need to work toward resolving the team’s trust issue.

Absence of Conflict

Team members are surrounded by conflict from other team members and stakeholders because of the varying points of view that naturally exist throughout a project. Not all conflicts are bad. On the contrary, constructive conflicts can allow the team to identify issues, solutions and potential problems within the



Page 266

project. It is important that the entire team recognize conflict as a potentially beneficial thing. If a team suffers from any of the following symptoms, it likely has an absence of conflict:

Boring meetings

Back channel politics

Personal attacks

Ignoring controversial topics that are critical

Opinions and perspectives of all team members are not heard or are silenced

Lots of posturing and interpersonal risk management

Lack of Commitment

The third major dysfunction of a team is a lack of commitment. When an organization suffers from a lack of commitment, it rarely sticks with difficult decisions or finds it impossible to make the decisions that are necessary to ensure project success. Often these issues create exponentially increasing problems as project resources become more and more frustrated. Each of the following represent telltale signs of a lack of commitment within an organization:

Ambiguity about direction and priorities

Paralysis by analysis

Lack of confidence and fear of failure

Revisiting discussions and decisions repeatedly

Second guessing amongst the team

If you identify that you have a commitment issue within your team or organization, it is recommended that you implement the following measures:

Cascading Messaging — Ensure that messaging flows from the top of the organization. Senior management must have belief in their ideas and set a consistent direction for the organization.

Deadlines — Set deadlines and make everyone live up to them.

Contingency and Worst-case Analysis — Make sure you have contingency plans in place and conduct a worst-case analysis of all plans to ensure that you and the team can deal with it.

Low-risk Exposure Therapy — Identify the risk exposure tolerances within the organization and your team.

Avoidance of Accountability

Without committing to a clear plan of action, even the most focused and driven team members will hesitate to call out actions and behaviors that seem



Page 267

counterproductive to the good of the project and organization. Members will hold deep seeded resentment for team members that fail to live up to their standards, although they may say nothing.

The avoidance of accountability is exemplified by the following indicators:

Resentment among team members of different performance standards

Encouraged mediocrity

Missed deadlines and key deliverables

Team leader is the sole source of discipline

If you identify that you have an accountability issue within your team or organization, it is recommended that you implement the following measures:

Publish goals and standards for all team members

Have simple and regular progress reviews

Introduce team rewards

Inattention to Results

Inattention to results occurs when team members put their individual needs (such as ego, career development, or recognition) above the collective goals of the team. This will cause the team to fail to meet most, if not all, of the original objectives of the project. Inattention to results can be indicated by any of the following:

Team stagnates and fails to grow

The organization rarely defeats a competitor

The organization loses achievement-oriented employees

Team members are encouraged to focus on their own goals

The team is easily distracted

If you identify that you have an inattention to results issue within your team or organization, implement the following measures:

Public declaration of results

Results-based rewards

The Daily Scrum A key element of performance management in a Scrum project is the Daily Scrum. The Daily Scrum is the way the Team provides accountability and is also a key connection point. To succeed you must do the Daily Scrum correctly! Here are some basic rules to help ensure your success:

Stand up means STAND UP! – The Daily Scrum is a standing meeting, and stand means stand. Everyone stands around the key Scrum artifacts and



Page 268

physically moves things to help keep everyone focused and to keep the meeting short.

Target 10 minutes — Far too many people spend a lot of time in really bad meetings that take hours. The Daily Scrum is a critical touch point, but key to its success is being short. The target is 10 minutes, and the Daily Scrum must never be longer than 15 minutes. In the Daily Scrum, the Team is reporting their results to each other with the answer to three short questions:

What did you do yesterday?

What are you going to do today?

What impediments do you have?

Same time every day and don’t miss a day — A key to Scrum’s success is its consistency. Scrum helps the team achieve consistency and predictability. To do that, the team must get into a routine. When the Team shifts its meeting times or skips days it becomes easier to do it the next time, and then easier to do it the time after that. Pretty soon a week or more passes between Daily Scrums. When the tasks are designed to be accomplished in a day or less, this scenario is a disaster. Tasks that were supposed to take a day take a week or more without the team knowing there is a problem.

Stand in front of the visual progress artifact — An important tool for any methodology are the artifacts that come with the methodology. When the team is Required to stand in front of the Team Board, Product Backlog, and WBS it helps to creates accountability. Suddenly the team has to touch the cards or PostIts that they are working on and must tell everyone where they are with those PBIs.

Everybody is present — A common occurrence in a lot of projects is for key team members to miss meetings because they are too “busy.” Sometimes these people send stand-ins. The result of this practice is that communication breaks down and the rest of the team has no idea what is happening.

No typing during the meeting — The Daily Scrum is all about the Team communicating. This means they must look each other in the eye and really listen. This doesn’t happen when team members look down at their laptops or phones. A common rule is to not allow electronic devices in the Daily Scrum. It’s only 10 or 15 minutes and people need to learn to live without their devices once in a while.

Concentrate on the 2nd and 3rd questions — The past is the past. It cannot be changed. But teams often get caught up in the past. Successful teams hold themselves accountable for the past but focus on the future. In the Daily Scrum, therefore, the team focuses more on the future by paying more attention to what the Team is going to do today and by addressing any impediments that exist.



Page 269

Slide 270

Don’t talk to the Scrum Master. Talk to the Team — In Scrum there are no project managers for the Team to report to. In Scrum, the Team reports to each other. Everyone is responsible to everyone else. One of the key advantages that the Scrum provides is visibility. Team members cannot hide their shortcomings.

One-on-One Coaching & Mentoring The highest level of Agilist is the Agile Coach. This role is reserved for very experienced Agile leaders. Coaches work from the sidelines just like a coach in football or basketball. An Agile Coach has years of experience in Agile Development and has experienced both successful and failed Agile projects. Because of this they are able to meet the Agile Team one half-step ahead of where they currently are. The seasoned Agile Coach can see what is likely to happen in the future based on their experience. The Agile leader succeeds in this process by guaranteeing the personal safety of each member of the team. This means they must create an environment where individuals can come to their Agile Coach and tell them anything without fear of retribution or fear that the information will get out to others. For this to work, team members must have the assurance that anything said to the Coach is said in confidence—even though the Agile Coach acts as a partner with managers and the senior leadership team. The Agile Coach must constantly work to create a positive relationship with both the Team and the leadership of the organization, because they are powerful to the degree that they can influence both parties toward a higher state of productivity and collaboration.

While every Agile Coach brings their own approach to an assignment, there are basically three types of Coaches.

The first type of Agile Coach is technical. Such a Coach works mainly with those cutting code, and sometimes becomes fully integrated with the developers. Technical coaches are likely to be found pairing with developers to help them apply test driven development, to support developers in refactoring work, to help improve the continuous integration system and to assist with other activities that are close to the code. Technical Coaches are experts in what they do. They aim to both transfer their knowledge and to enthuse team members to try new approaches and techniques.

The second type of Coach is also an expert who aims to transfer their knowledge, however the focus is not on technology but on process, management and requirements. Coaches like myself work with project managers, line managers, business analysts, product managers and others who are responsible for making the work happen. Rather than working at the code-face, this coaching tends to happen in meetings and in one-on-one sessions. There is a greater focus on facilitating events that help create change and improvement. For example, in addition to moderating stand-up meetings and planning meetings, I normally run retrospectives and “future-spectives.” A future-spective is an event which applies many of the same ideas and techniques as a retrospective, but is used to kick-off a new project or Agile transition. When working with managers there is more to coaching than simply knowledge transfer. It is much more about helping people



Page 270

rethink their inbuilt assumptions and mental models. Many managers have experienced career success with other development modes, and therefore they perceive Agile as a threat. Here coaching gives way to the third type.

The third type of Coach may work across everyone in the team but mostly finds himself or herself working with managers and analysts. In this mode, the Coach drops the expert persona and focuses instead on helping individuals and teams solve their own problems. To do this, the Coach takes on a non-directive approach. When working as an expert authority the Coach is provides direct advice and recommendations. This is known as directive coaching. In the non-directive mode, the Coach may – or may not – be an expert in the field. But they assume the Coach is the expert, and the Coach helps facilitate their learning. While Directive Coaching is often found in sports teams, the non-directive approach is used by Coaches who help business leaders. This approach is set out in books such as Coaching for Performance and Effective Coaching, and anyone thinking about embarking on this approach is well advised to read at least one of these books.

The diversity of coaching roles makes it difficult for one person to fill all. A technical expert will find it difficult to switch to a non-directive mode, and team members may be confused when an expert starts throwing questions back at them. Even if one individual can cover all the bases on all but the smallest projects, it is unlikely that there will be enough time to do justice to each role.

Brainstorming Techniques There are many situations that require an Agile team to discuss various ideas or options for addressing issues within the project. Many of these situations warrant the use of some form of brainstorming. The term brainstorming was first popularized by Faickney Osborn in the 1953 book Applied Imagination. This book defines brainstorming as a group creativity technique in which efforts are made to find a solution to a specific problem by gathering a list of ideas that are spontaneously contributed by its members. For the PMI-ACP Exam, there are a number of brainstorming techniques with which you must be familiar.

Free-For-All — This is the most common brain storming technique. However, many do not even think about it when deciding how to conduct a brainstorming session. It just happens. A free-for-all occurs whenever team members shout out ideas without any rules or constructs. In many cases team members shout over each other, making it difficult to hear each other.

Quiet Writing — This is a brainstorming technique where the individual team members are given time to generate a list of ideas before sharing them with the team. This technique has the advantage of limiting peer influence in the initial creation of ideas. It often results in a larger initial list.

Round-Robin Brainstorming — This brain storming technique requires the team to take turns suggesting ideas to address specific project needs. It is often used in conjunction with the Quiet Writing technique, and it continues to ensure that each team member participates in the process.

Slide 272



Page 271

Slide 273 Green Zone / Red Zone — This is a model first described by Lyssa Adkins. It is more than a simple brainstorming technique because it provides a way of establishing organizational guidelines for positive performance. Atkins describes two states of being in which we all exist: a red zone and a green zone. The red zone is a space where we become defensive and act in a rigid way. When we become rigid, we typically stop thinking and turn to using most of our abilities to protect ourselves from the others members of our team. Our need for self preservation is important. But we must learn to control it and turn it towards a positive direction. To do this we must learn to recognize when we are entering the Red Zone. The defensive response pattern can take many forms, but it is most commonly highlighted by a response to fight, flee, or freeze. When team members are in a heightened state physically, emotionally, and intellectually, this state forces them to focus on self-protection and defending. When in the Red Zone there are a number of possible tendencies:

Blaming others for the circumstances of their life Feeling threatened or wronged Triggering defensiveness in others through their actions Not seeking or valuing feedback from others Communicating a high level of disapproval and contempt for our

teammates

The Red Zone is not likely to be a place of collaboration, trust building, mutual problem solving, or deeper self-reflection and shared accountability. According to the most Agile thought leaders, each of these are critical for project and team success.

The alternative to the Red Zone is the Green Zone. When we are in the Green Zone, we feel relaxed, safe, alive, emotionally significant, competent and likable. When the team is in the Green Zone, team members can be intellectually open and honest. They can consciously operate in a non-defensive, cooperative, problem-solving, and accountable state. When we are in the Green Zone, we do not see conflict as a threatening. When a team member is in the Green Zone, they exhibit the following qualities:

They take responsibility for the circumstances of their life. They seek to respond to the actions and words of others in a non-

defensive manner. They seek solutions rather than blame. They welcome feedback. They communicate a caring attitude with the other members and with

stakeholders.

Additional Terms Before leaving the Team Performance Domain, there are several additional terms you must know in order to be prepared for the exam. These terms include the following:



Page 272

Self-Organizing Teams — Members from empowered teams are freed from command-and-control management and can use their own knowledge to determine how best to do their job.

Self-Directing Teams — These teams work collectively to create team norms and make their own local decisions. This means they figure out the best way to accomplish the work they committed to for an iteration, and they resolve the day-to-day issues that crop up along the way.

Whole-Team Coaching — This coaching happens more at the iteration boundaries because the team is assembled for events like iteration planning, iteration reviews, and retrospectives.

Co-Located Teams — Teams that share the same physical space.

Caves and Common — This "layout" is made of two different environments: Open rooms that are great for overhearing useful project information. Closed spaces give the team members a place to retreat to when they

need some quiet time or privacy.

Osmotic Communication — Information that flows in the background of an open workspace is easily absorbed by the team members. It is as if they pick up relevant information by osmosis. This requires them to sit in the same room.

Tacit Knowledge — This is information that is not written down but is instead supported through collective group knowledge. It is also more effective when teams are co-located.

Low Tech, High Touch Tools — These "tools" assist the team in communication and collaboration by giving team members tangible objects to use in their interactions.

The Spy — This is someone who spends just enough time observing the team to pick up topics for the next retrospective.

The Seagull — This is someone who swoops in at stand-ups, poops all over the team (with well-intentioned observations or advice) and flies away again.

The Opinionator — This is someone who expresses opinions during the team discussions and gets so attached to their opinions (or the opinions of others) that they lose the objectivity needed to help the team have great discussions.

The Admin — Someone who undermines team ownership by becoming an unnecessary middle-man for meeting logistics, access requests and other administrator-type jobs.

The Hub — Someone who acts as the center of the universe for communication between team members and for task-level coordination.

The Butterfly — Someone who flits around from team to team, landing just long enough to impart a pearl of wisdom or pose a philosophical question.

Slide 274



Page 273

The Expert — Someone who is so involved in the details of the team's work when only the trees are visible. What? We're in a forest? Huh, does that mean there's a way out?

The Nag — Someone who helpfully "reminds" the team to start the stand-up, update the story board, complete the tasks they committed to, etc.

Before continuing on, please complete the exam that follows, and make sure to score at least 90% before you move on to the next chapter.



Page 274

Team Performance Exercise

1. Which of the following is part of the team performance area?

A. Team empowerment B. Team health C. Team communication D. Team cooperation

2. Which of the following tasks is NOT a task found in the team empowerment group of team performance?

A. Encourage team members to become generalizing specialists in order to reduce team size and bottlenecks, and to create a high-performing cross-functional team.

B. Contribute to self-organizing the work by empowering others and encouraging emerging leadership in order to produce effective solutions and manage complexity.

C. Reduce distractions in order to establish a predictable outcome and optimize the value delivered.

D. Continuously discover team and personal motivators and de-motivators in order to ensure that team morale is high and team members are motivated and productive throughout the project.

3. Which of the following tasks is NOT a task found in the team collaboration and commitment group of team performance?

A. Facilitate close communication within the team and the team and with appropriate external stakeholders through co-location or the use of collaboration tools in order to reduce miscommunication and rework.

B. Continuously discover team and personal motivators and de-motivators in order to ensure that team morale is high and team members are motivated and productive throughout the project.

C. Reduce distractions in order to establish a predictable outcome and optimize the value delivered.

D. Encourage the team to measure its velocity by tracking and measuring actual performance in previous iterations or releases in order for members to gain a better understanding of their capacity and create more accurate forecasts.

4. What is the primary use of COCOMO?

A. COCOMO is a team collaboration model. B. COCOMO is forecasting tool. C. COCOMO represents an estimating technique. D. COCOMO is a resourcing model.

5. Which version of COCOMO is best when the team is looking for a ROM estimate of software costs?

A. Basic COCOMO B. Stage I COCOMO C. Foundational COCOMO D. Developmental COCOMO

6. Which version of COCOMO provides the addition of project phases as a variable in the model?

A. Basic COCOMO B. Intermediate COCOMO C. Detailed COCOMO D. Advanced COCOMO

Exercise 9 — Boosting Team Performance



Page 275

7. Which of the following statements concerning basic COCOMO is NOT true?

A. Basic COCOMO is good for quick estimates of software projects. B. Basic COCOMO does not account for differences in hardware constraints. C. Basic COCOMO does not account for differences in personnel quality and

experience. D. Basic COCOMO accounts for the use of modern tools and techniques.

8. Which of the following is NOT a core cost driver found in intermediate COCOMO?

A. Product attributes B. Operational attributes C. Hardware attributes D. Personnel attributes

9. What kind of development model does the Detailed COCOMO model use?

A. Waterfall B. Scrum C. Extreme programming D. Any agile method

10. Which of the following is the final step in the Detailed COCOMO process?

A. Detailed design B. Module code and test C. Integration and test D. Cost Constructive Model

11. Which of the following statements about COCOMO is true?

A. COCOMO represents an equation-based method for estimating costs and duration based on a database of previously performed projects.

B. COCOMO represents a qualitative estimating technique based on subject matter expertise.

C. COCOMO represents a quantitative estimating technique based on subject matter expertise.

D. COCOMO represents a set of lookup tables used to generate cost estimates.

12. Which of the following statements concerning Adaptive leadership is NOT true?

A. Adaptive leadership is a framework of ideas that allows the individual and team to adapt and thrive in challenging environments.

B. Adaptive leadership is based on a process of gradual and meaningful change that must occur constantly for the team to succeed.

C. Adaptive leadership is best when used on technical challenges to deliver a more responsive product or service to the customer.

D. Adaptive leadership requires the Agilist to determine which practices are core to the future of the organization and the obstacles that prevent the team from making maximum use of those practices.

13. A team member is struggling to deal with the high degree of change and ambiguity they are facing on the project. As an agile leader you coach them on the importance of adaptive leadership in agile development. Which of the following best justifies this path?

A. Adaptive leadership focuses on being willing to change for the betterment of the team.

B. Adaptive leadership embraces ambiguity as a cultural norm. C. Adaptive leadership embraces taking risks that disrupt the status quo for better results. D. Adaptive leadership promotes a flexible mindset in all aspects of project execution.



Page 276

14. Which of the following is NOT something Jim Highsmith believe adaptive leaders need to do?

A. Create an agile environment full of dedicated agile professionals. B. Create an Agile performance management system. C. Determine operational, portfolio, and strategic agility aims. D. Foster adaptable IT, product line, and product architectures.

15. Which of the following is NOT a specific model described by Highsmith to help adapt and change in the chaotic environment described by agilists?

A. The Purpose Alignment Model B. The Gibson Alignment Model C. The Short-Horizon Model D. The OODA Loop Model

16. Which Highsmith advocated adapt and change model is depicted by the argument that in a turbulent environment the importance of seeing reality without filters enhances the ability to identify opportunities and threats?

A. The Purpose Alignment Model B. The Satir Change Model C. The Short-Horizon Model D. The OODA Loop Model

17. Which Highsmith advocated adapt and change model is depicted by the argument that project are more effective when they have a roadmap targets large chunks of work onto a 6-18 month timeline. Within the roadmap, release plans, consisting of deployable chunks of work, are outlined in a 3-month timeline. And at the lowest level, 2-week iterations, consisting of small, useful chunks of work, are planned within each release.

A. The Purpose Alignment Model B. The Satir Change Model C. The Short-Horizon Model D. The OODA Loop Model

18. Which of the following is NOT a step found in the Tuckman Model?

A. Planning B. Forming C. Storming D. Norming

19. Which of the following represents the correct order of steps found in the Tuckman Model?

A. Storming, forming, norming, performing, and adjourning B. Forming, storming, norming, performing, and adjourning C. Norming, forming, storming, performing, and adjourning D. Norming, storming, forming, performing, and adjourning

20. Which stage from the Tuckman Model represents a stage where decisions fail to come easily, and team members attempt to establish themselves in relationship to other members as they are challenged. In this stage, cliques and factions form and there are possible power struggles.

A. Forming B. Storming C. Norming D. Performing



Page 277

21. _______ is NOT another term Tuckman used to represent the fifth stage of his forming, storming, etc. model?

A. Adjourning B. Deforming C. Performing D. Mourning

22. What kind of leader are you if you throw open the problem to the group and encourage the entire team to make the relevant decision?

A. A autocratic leader B. A consultative autocratic leader C. A consensus manager D. A shareholder manager

23. Which of the following leadership mode is generally considered an example of poor leadership?

A. A autocratic leader B. A consultative autocratic leader C. A consensus manager D. A shareholder manager

24. Which leadership model postulates that the leader’s effectiveness is based on ‘situational contingency’ which is a result of interaction of two factors: leadership style and situational favorableness?

A. The Leadership Contingency Model B. The Situational Leadership Theory C. The Lifecycle Leadership Theory D. The Functional Leadership Theory

25. Which of the following leadership theories was developed by Hersey and Blanchard and was first called the Life Cycle Theory of Leadership?

A. The Leadership Contingency Model B. The Situational Leadership Theory C. The Lifecycle Leadership Theory D. The Functional Leadership Theory

26. Within Hershey and Blanchard's theory of leadership which of the following is NOT one of the defined styles?

A. Telling B. Selling C. Coaching D. Delegating

27. What Hershey and Blanchard leadership style is one using if the leader is still involved in decisions; however, the process and responsibility has been passed to the individual or group. The leader stays involved to monitor progress?

A. Telling B. Selling C. Participating D. Delegating



Page 278

28. What Hershey and Blanchard leadership style is one using if the leader is still providing the direction, he or she is now using two-way communication and providing the socio-emotional support that will allow the individual or group being influenced to buy into the process?

A. Telling B. Selling C. Participating D. Delegating

29. When discussing the total amount of power a person has, it is defined by the formula:

A. Total Power = Positional Power + Personal Power B. Total Power = Personal Power + Relational Power C. Total Power = Legitimate Power + Referent Power D. Total Power = Expert Power + Positional Power

30. As the team gets together for their daily stand-up, one of the team members starts telling the rest of the group about their friendship with the organization's CEO. What kind of power is being exhibited?

A. Legitimate B. Reward C. Expert D. Referent

31. A team member stands 6' 8" tall and weighs close to 300 pounds. They often corner other members of the team slowly invading their personal space as they discuss issues getting closer as the conversation gets more heated, and backs off once the issue is closed. This is an example of what kind of power?

A. Legitimate B. Coercive C. Referent D. Reward

32. Which of the following is NOT a skill generally included with emotional intelligence?

A. Emotional awareness, including the ability to identify your own emotions and those of others.

B. The ability to harness emotions and apply them to tasks like thinking and problems solving.

C. The ability to generate strong emotions in others for the betterment of the project and the team.

D. The ability to manage emotions, including the ability to regulate your own emotions, and the ability to cheer up or calm down another person.

33. Which of the following does NOT represent a main Emotional Intelligence model?

A. The Ability Model B. The Conformance Model C. The Mixed Model D. The Trait Model

34. When examining the basics of Emotional Intelligence using the Goleman Model, which of the following brings together who you are and how you handle relationships?

A. Self-Awareness B. Self-Management C. Social / Other Awareness D. Relationship Management



Page 279

35. Which Emotional Intelligence Model redefined the term as, "the ability to perceive emotion, integrate emotion to facilitate thought, understand emotions and to regulate emotions to promote personal growth?"

A. The Ability Model B. The Conformance Model C. The Mixed Model D. The Trait Model

36. Which of the following is NOT one of the four types of abilities found in the Ability-based EI model?

A. Perceiving emotions B. Controlling emotions C. Using emotions D. Managing emotions

37. Within the Ability-Based EI model which of the four types of abilities represents the ability to regulate emotions in both ourselves and in others. Therefore, the emotionally intelligent person can harness emotions, even negative ones, and manage them to achieve intended goals?

A. Perceiving emotions B. Using emotions C. Understand emotions D. Managing emotions

38. A commonly cited problem with the MSCEIT is that it is impossible to create new questions that only a minority can solve because:

A. By definition, the answers are only deemed "emotional intelligent" if a majority of the sample answers correctly.

B. The MSCEIT requires strict adherence to a set of question defined by the authors. C. The MSCEIT requires a very large pool of respondents to develop new questions. D. By definition, the question are only deemed viable if they a minority of the sample

answers correctly.

39. According to Goleman, which of the following does NOT represent one of the model's five main EI constructs?

A. Self-awareness B. Self-regulation C. Motivation D. Other awareness

40. Which of the following is a common measurement tool based on the Goleman Model?

A. The Emotional Competency Inventory B. The Emotional Intelligence Checklist C. The Trait EI Survey D. The General Emotional Intelligence Survey

41. Which of the following best describes the recommended size of an agile team according to Frank LaFasto?

A. Less than 50. B. Less than 20. C. Less than 12. D. Less than 6.



Page 280

42. According to Lyssa Adkins, a great team must what?

A. Stay constantly focused on the team's success. B. Open to new ideas. C. Exist in a constant state of constructive conflict. D. Focused on a singular mission.

43. Which of the following is NOT a common indicator that your team is struggling with an absence of trust?

A. The team conceals weaknesses and/or mistakes. B. Team members fail to ask for help or provide constructive criticism. C. Team members fail to recognize others’ capabilities. D. Team members lack confidence and fear failure.

44. If you discover your team is struggling with an absence of trust which of the following is a viable response?

A. A personal histories exercise B. Cascading messaging C. A published declaration of results D. Results-based rewards

45. Which of the following might be indicative of your team struggling with an absence of conflict?

A. The team holds boring meetings. B. The team ignores controversial topics that are critical to success. C. The team leader is the sole source of discipline. D. Lots of posturing and interpersonal risk management by the team.

46. The team is conducting its daily standup when the Product Owner begins asking a series of questions about a story the team is completing. As the Scrum Master what is the BEST thing to do?

A. Nothing. The Product Owner is the sponsor of the project and may ask for any needed information at the Daily Scrum.

B. Pull the PO aside politely, allowing the team to continue, and explain that the Daily Scrum is for the team and not the PO to ask questions.

C. Obtain the information for the Product Owner immediately after the meeting and keep the questioning to only a couple of minutes.

D. Encourage a dialogue about the PO's questions even if it causes the Daily Scrum to go over time. Good communication is critical to project success.

47. You are asked to act as an Agile Coach for a struggling Scrum team. You attend the Daily Scrum and observe the team as they come into the conference room and sit around a oval table that allows the team members to look at each other as they talk. A couple of team members take notes during the meeting while the Scrum Master facilitates the meeting. After the meeting the Scrum Master asks you for advice to improve the Daily Scrum. Which of the following would BEST help this team?

A. Advise the Scrum Master to get the team talking to each other and not the Scrum Master.

B. Advise the Scrum Master to stop people from taking notes so they can look at each other.

C. Advise the Scrum Master to get the team standing by the team board and moving tasks.

D. Advise the Scrum Master that no major changes are needed at this time.



Page 281

48. Which of the following is NOT one of the three key questions asked at the Daily Scrum?

A. What did you do yesterday? B. What are you going to do today? C. What impediments or blockers do you have? D. Do you have capacity to help anyone else on the team?

49. Which of the following questions is a core focus of the Daily Scrum?

A. What did you do yesterday? B. Do you have capacity to help someone else on the team? C. What else do you need to complete your task? D. What impediments do you have?

50. Which of the listed titles represents the highest level of Agilist?

A. The Agile Coach B. The Release Train Engineer C. The Product Owner D. The Scrum Master



Page 282

Team Performance Exercise Answers

1. Answer A. LGd course manual p. 247 - Team performance describes how well the project team is working together to achieve the desired project goal. Boosting that performance must be a central goal of every Agile leader. The domain is broken into three groupings of nine tasks that include: Team performance; Team empowerment; Team collaboration and commitment.

2. Answer C. LGd course manual p. 247 - Team performance describes how well the project team is working together to achieve the desired project goal. Boosting that performance must be a central goal of every Agile leader. The domain is broken into three groupings of nine tasks that include: Team performance; Team empowerment; Team collaboration and commitment. The team empowerment area includes: Encourage team members to become generalizing specialists in order to reduce team size and bottlenecks, and to create a high-performing cross-functional team. Contribute to self-organizing the work by empowering others and encouraging emerging leadership in order to produce effective solutions and manage complexity. Continuously discover team and personal motivators and de-motivators in order to ensure that team morale is high and team members are motivated and productive throughout the project.

3. Answer B. LGd course manual p. 247 - Team performance describes how well the project team is working together to achieve the desired project goal. Boosting that performance must be a central goal of every Agile leader. The domain is broken into three groupings of nine tasks that include: Team performance; Team empowerment; Team collaboration and commitment. The team collaboration and commitment area includes: Facilitate close communication within the team and the team and with appropriate external stakeholders through co-location or the use of collaboration tools in order to reduce miscommunication and rework. Reduce distractions in order to establish a predictable outcome and optimize the value delivered. Participate in aligning project and team goals by sharing the project vision in order to ensure the team understands how their objectives fit into the overall goals of the project. Encourage the team to measure its velocity by tracking and measuring actual performance in previous iterations or releases in order for members to gain a better understanding of their capacity and create more accurate forecasts.

4. Answer C. Gd course manual p. 248 - The Constructive Cost Model was originally created based on a correlation study that originally looked at thousands of software projects between input variables and total project costs. The results of this study are used as an estimating technique. The algorithmic model was originally developed by Barry Boehm in 1981 as part of his book Software Engineering Economics as a model for estimating effort, cost, and scheduling on software projects. The model uses basic regression analysis based on historical data.

5. Answer A. LGd course manual p. 248 - The COCOMO model consists of a hierarchy of three versions. The initial level is called Basic COCOMO and is good for quick, early, rough order of magnitude, or ROM estimates of software costs, but its accuracy is limited due to its lack of factors to account for difference in project attributes. These are referred to as cost drivers. Intermediate COCOMO takes the Cost Drivers into account making it more accurate than Basic COCOMO. The third and final version is called Detailed COCOMO. It provides for the addition of project phases as a variable in the model.

6. Answer C. LGd course manual p. 248 - The COCOMO model consists of a hierarchy of three versions. The initial level is called Basic COCOMO and is good for quick, early, rough order of magnitude, or ROM estimates of software costs, but its accuracy is limited due to its lack of factors to account for difference in project attributes. These are referred to as cost drivers. Intermediate COCOMO takes the Cost Drivers into account making it more accurate than Basic COCOMO. The third and final version is called Detailed COCOMO. It provides for the addition of project phases as a variable in the model.



Page 283

7. Answer D. LGd course manual p. 248 - Basic COCOMO is good for quick estimate of software costs. However it does not account for differences in hardware constraints, personnel quality and experience, use of modern tools and techniques, and so on.

8. Answer B. LGd course manual p. 248 - Intermediate COCOMO computes software development effort as function of program size and a set of "cost drivers" that include subjective assessment of product, hardware, personnel and project attributes. This extension considers a set of four "cost drivers", each with a number of subsidiary attributes: product attributes, hardware attributes, personnel attributes, and project attributes.

9. Answer A. LGd course manual p. 248 - Detailed COCOMO builds on the Basic and Intermediate models that came before. The difference is that the Detailed Model takes those variables and adds an assessment of the cost driver’s impact at each step of the project process. It is important to remember that this Detailed Model uses a Waterfall-type model.

10. Answer D. LGd course manual p. 248 - The five phases of detailed COCOMO are: Plan and requirement; System design; Detailed design; Module code and test; Integration and test; and Cost Constructive Model.

11. Answer A. LGd course manual p. 248 - The important thing to remember for the Exam is that COCOMO represents an equation-based method for estimating costs and duration based on a database of previously performed projects.

12. Answer C. LGd course manual p. 250 - Adaptive leadership is a central tool to the Agilist. It is a framework of ideas that allows the individual and team to adapt and thrive in challenging environments. It is based on a process of gradual and meaningful change that must occur constantly for the team to succeed. Adaptive Leadership requires the Agilist to determine which practices are core to the future of the organization and the obstacles that prevent the team from making maximum use of those practices. The team must then determine how to both remove the obstacles as well as develop and test the next set of practices before integrating those new practices into the existing environment.

13. Answer C. LGd course manual p. 251 - Jim Highsmith contends that, “Creative (or adaptive) leadership includes embracing ambiguity, taking risks that disrupt the status quo, instituting new management styles, and faster decision making. Building operating dexterity includes simplifying whenever possible, managing systemic complexity (standardization in some cases), and promoting a fast and flexible mindset.”

14. Answer A. LGd course manual p. 251 - According to Jim Highsmith, just a few of the things adaptive leaders need to do include: Create an Agile performance management system; Align agile transformation efforts to business strategy; Determine operational, portfolio, and strategic agility aims; Facilitate a decentralized, empowered, collaborative workplace; Foster adaptable IT, product line, and product architectures; and create an Agile proficiency evaluation framework.

15. Answer B. LGd course manual p. 251 - According to Jim Highsmith, just a few of the things adaptive leaders need to do include: Create an Agile performance management system; Align agile transformation efforts to business strategy; Determine operational, portfolio, and strategic agility aims; Facilitate a decentralized, empowered, collaborative workplace; Foster adaptable IT, product line, and product architectures; and create an Agile proficiency evaluation framework.

16. Answer D. LGd course manual p. 252 - The way the basic OODA Model (using simple arrows around in a circle) is normally depicted—is somewhat deceptive because the fast- and normal- path is actually OOA (Observe, Orient, and Act). For really fast action, Boyd depended on training and experience guiding him directly to action, without a lengthy decision step. The decision step was usually performed after the fact, acting as a learning practice. Boyd also differentiated between observing and orienting—the first was seeing reality without filters, while orienting applied the filters of culture, experience, new information, and analysis. In a turbulent environment the importance of seeing reality without filters enhances the ability to identify opportunities and threats.



Page 284

17. Answer C. LGd course manual p. 252 - A better Short-Horizon model for responding quickly to opportunities and threats is the roadmap, release, and iteration model used by software delivery teams. Business initiatives can be planned and executed with this model. A roadmap targets large chunks of work onto a 6-18 month timeline. Within the roadmap, release plans, consisting of deployable chunks of work, are outlined in a 3 month timeline. And at the lowest level, 2-week iterations, consisting of small, useful chunks of work, are planned within each release.

18. Answer A. LGd course manual p. 253 - Tuckman's model explains that as the team develops maturity and ability, relationships establish, and the leader changes leadership style. Beginning with a directing style, moving through coaching, then participating, finishing delegating and almost detached. The steps include: forming, storming, norming, performing, and adjourning.

19. Answer B. LGd course manual p. 253 - Tuckman's model explains that as the team develops maturity and ability, relationships establish, and the leader changes leadership style. Beginning with a directing style, moving through coaching, then participating, finishing delegating and almost detached. The steps include: forming, storming, norming, performing, and adjourning.

20. Answer B. LGd course manual p. 254 - Storming — Decisions don't come easily within group. Team members vie for position as they attempt to establish themselves in relation to other team members and the leader, who might receive challenges from team members. Clarity of purpose increases but plenty of uncertainties persist. Cliques and factions form and there may be power struggles. The team needs to be focused on its goals to avoid becoming distracted by relationships and emotional issues. Compromises may be required to enable progress. Leader coaches (similar to Situational Leadership® 'Selling' mode).

21. Answer C. LGd course manual p. 254 - Bruce Tuckman refined his theory around 1975 and added a fifth stage to the Forming Storming Norming Performing model - he called it Adjourning, which is also referred to as Deforming and Mourning. Adjourning is arguably more of an adjunct to the original four stage model rather than an extension - it views the group from a perspective beyond the purpose of the first four stages. The Adjourning phase is certainly very relevant to the people in the group and their well-being, but not to the main task of managing and developing a team, which is clearly central to the original four stages.

22. Answer C. LGd course manual p. 255 - A consensus manager throws open the problem to the group and encourage the entire team to make the relevant decision.

23. Answer D. LGd course manual p. 255 - Shareholder managers represent a style of management considered generally poor. With this style of management, little or no information input and exchange takes place within the group context, yet the group is provided the authority for the final decision.

24. Answer A. LGd course manual p. 255 - There are also conflicting ideas about which leadership style is best. PMI® does not define a “best” style. However, two theories need to be reviewed for the exam. The first theory is the Leadership Contingency Model by Fielder. Fiedler’s contingency model postulates that the leader’s effectiveness is based on ‘situational contingency’ which is a result of interaction of two factors: leadership style and situational favorableness.

25. Answer B. LGd course manual p. 256 - The Situational Leadership Theory is a leadership theory developed by Paul Hersey and Ken Blanchard. The Theory was first introduced as "Life Cycle Theory of Leadership”. The theory holds there is no single “best” style of leadership. Effective leadership is task-relevant and that the most successful leaders are those that adapt their leadership style to the maturity of the individual or group they are attempting to lead/influence, and that effective leadership varies, not only with the person or group that is being influenced, but it will also depend on the task, job or function that needs to be accomplished.



Page 285

26. Answer C. LGd course manual p. 256 - The Situational Leadership Theory is a leadership theory developed by Paul Hersey and Ken Blanchard. The Theory was first introduced as "Life Cycle Theory of Leadership”. The theory holds there is no single “best” style of leadership. Effective leadership is task-relevant and that the most successful leaders are those that adapt their leadership style to the maturity of the individual or group they are attempting to lead/influence, and that effective leadership varies, not only with the person or group that is being influenced, but it will also depend on the task, job or function that needs to be accomplished. Within this theory there are four styles of leadership: Telling; Selling; Participating; and Delegating.

27. Answer D. LGd course manual p. 256 - According to Hershey and Blanchard, when using a delegating style the leader is still involved in decisions; however, the process and responsibility has been passed to the individual or group. The leader stays involved to monitor progress.

28. Answer B. LGd course manual p. 256 - According to Hershey and Blanchard, when using a selling style the leader is still providing the direction, he or she is now using two-way communication and providing the socio-emotional support that will allow the individual or group being influenced to buy into the process.

29. Answer A. LGd course manual p. 256 - There are several sources of power you must know to prepare for the exam. These sources are not exclusive. Meaning the total power possessed by any leader is a combination of the power provided and is defined by the equation: Total Power = Positional Power + Personal Power

30. Answer D. LGd course manual p. 256-257 - When using referent power a leader gains authority based upon who they know or with whom they are associated. A simple example is when the project leader is friends with the company president.

31. Answer B. LGd course manual p. 256-257 - Coercive power is a based upon intimidation. It can be physical, emotional or most commonly based on the ability to impact one’s job security. It is predicated on fear.

32. Answer C. LGd course manual p. 257 - Emotional Intelligence experts argue that it requires people to discriminate between different emotions and label them appropriately and to use emotional information to guide thinking and behavior. Further, it also reflects the ability to combined intelligence, empathy, and emotions to enhance one’s thought and understanding of interpersonal dynamics. It is generally said to include three skills: Emotional awareness, including the ability to identify your own emotions and those of others; The ability to harness emotions and apply them to tasks like thinking and problems solving; And the ability to manage emotions, including the ability to regulate your own emotions, and the ability to cheer up or calm down another person.

33. Answer B. LGd course manual p. 257 - For the PMI-ACP® exam, it is important that you understand the basic concepts of EI and some of the fundamentals surrounding the three main models that exist: Ability Model; Mixed Model Trait Model.

34. Answer C. LGd course manual p. 258 - Social or Other Awareness is the ability to understand the emotional makeup of other people, and represents a skill in treating others according to their individual emotional reactions. It is highlighted by empathy and both a situational awareness that is combined with a clear understanding of the organization and a strong service orientation.

35. Answer A. LGd course manual p. 260 - Salovey and Mayer created the Ability-Based Emotional Intelligence Model. This model attempts to define EI within the boundaries of the standard criteria for a new intelligence. Based on their research, they redefined EI as, “The ability to perceive emotion, integrate emotion to facilitate thought, understand emotions and to regulate emotions to promote personal growth.”



Page 286

36. Answer B. LGd course manual p. 260 - The ability-based model views emotions as useful sources of information that help one to make sense of and navigate the social environment. The model proposes that individuals vary in their ability to process information of an emotional nature and in their ability to relate emotional processing to a wider cognition. This ability is seen to manifest itself in certain adaptive behaviors. The model claims that EI includes four types of abilities: Perceiving Emotions; Using Emotions; Understanding Emotions; and Managing Emotions.

37. Answer D. LGd course manual p. 260 - Within the ability of ability-based EI model the Managing emotions ability represents the ability to regulate emotions in both ourselves and in others. Therefore, the emotionally intelligent person can harness emotions, even negative ones, and manage them to achieve intended goals.

38. Answer A. LGd course manual p. 261 - Although promoted as an ability test, the Mayer-Salovey-Caruso Emotional Intelligence Test or MSCEIT is unlike standard IQ tests in that its items do not have objectively correct responses. Among other challenges, the consensus scoring criterion means that it is impossible to create items (questions) that only a minority of respondents can solve, because, by definition, responses are deemed emotionally "intelligent" only if the majority of the sample has endorsed them. This and other similar problems have led some cognitive ability experts to question the definition of EI as a genuine intelligence.

39. Answer D. LGd course manual p. 261 - The model introduced by Daniel Goleman focuses on EI as a wide array of competencies and skills that drive leadership performance. This concept is key to the Agilist, and is the model you should spend the most time coming to know. Goleman's model outlines five main EI constructs. If after reading through this discussion you still have questions refer to "What Makes A Leader" by Daniel Goleman, best of Harvard Business Review, 1998. These five areas include: Self-awareness; Self-regulation; Social skills; Empathy; and Motivation.

40. Answer A. LGd course manual p. 262 - Two measurement tools are based on the Goleman model: The Emotional Competency Inventory or ECI — The ECI was created in 1999, and the Emotional and Social Competency Inventory (ESCI), a newer edition of the ECI was developed in 2007. The Emotional and Social Competency - University Edition (ESCI-U) is also available. These tools, developed by Goleman and Boyatzis provide a behavioral measure of the Emotional and Social competencies. The Emotional Intelligence Appraisal or EIA — The EIA created in 2001 and can be taken as a self-report or 360-degree assessment.

41. Answer C. LGd course manual p. 263 - Frank LaFasto describes an Agile Team as being smaller than what some earlier work has. He specifies that the team needs to be 12 or fewer members so that each member can support the others. The smaller team size also ensures the team can build its own unique strong identity.

42. Answer C. LGd course manual p. 263 - Lyssa Adkins offers some additional insights about high performing teams. Many of the requirements are the same as the ideas presented by LaFasto and others. She argues that Agile teams must be self-organizing, empowered to make their own decisions, and believe they can solve any problem. Additionally, everyone on the team must be committed to the team’s success. This commitment requires the team to own its decisions and commitments. According to Adkins, a great team uses trust to motivate themselves. Such teams are able to have a constant state of constructive conflict where the team diverges with different ideas are held by the different team members who then come together in consensus. However, even the best teams can struggle due to personality conflicts and other issues.



Page 287

43. Answer D. LGd course manual p. 264 - Trust is the real foundation of team structure. Often team members don’t feel comfortable enough with the other members to fully disclose or share information that is needed for the team to succeed. Common indicators that your team is struggling with an absence of trust include: Concealing weaknesses and/or mistakes; Not asking for help or providing constructive criticism; Not offering to help other team members outside their own areas; Quickly jumping to conclusions; Failing to recognize others’ capabilities; Holding grudges from previous meetings/projects; and dreading meetings and finding reasons to avoid each other.

44. Answer A. LGd course manual p. 264 - If you identify that you have an absence of trust within your team, here are some tools for getting the team back on track: Personal Histories Exercise — Have each team member review what they did prior to becoming part of this team. This will allow everyone to better understand the strengths of each member; Team Effectiveness Exercise — Use team building exercises to allow each member to gain personal and team insight to how they act in the team setting; Personality and Behavioral Preferences Profiles — Team Dimensions Profile; and 360 Degree Feedback — Reviews by team members, managers and subordinates on your performance. This will provide team members with valuable information about their performance.

45. Answer C. LGd course manual p. 264 - Team members are surrounded by conflict from other team members and stakeholders because of the varying points of view that naturally exist throughout a project. Not all conflicts are bad. On the contrary, constructive conflicts can allow the team to identify issues, solutions and potential problems within the project. It is important that the entire team recognize conflict as a potentially beneficial thing. If your team often suffers from any of the following you likely have an absence of conflict: Boring meetings; Back channel politics; Personal attacks; Ignoring controversial topics that are critical; Opinions and perspectives of all team members are not heard or are silenced or lots of posturing and interpersonal risk management.

46. Answer B. LGd course manual p. 266 - The Daily Scrum is a meeting for the team to get focus on what they are accomplishing each day. The Product Owner participates as an observer only. Therefore, the best thing is to politely pull the PO aside and explain the purpose of the Daily Scrum while also promising to get their questions answered quickly.

47. Answer C. LGd course manual p. 266 - The most important aspects of the Daily Scrum include the team standing in front of a Team Board and physically going through the process of moving tasks as they answer the three key questions amongst themselves. Doing this will likely solve several of the other issues being observed.

48. Answer D. LGd course manual p. 266 - In the Daily Scrum the Team is reporting their results to each other with the answer to three short questions: What did you do yesterday? What are you going to do today? What impediments do you have?

49. Answer D. LGd course manual p. 266 - In every scenario the past is the past. It cannot be changed, but teams often get caught up in the past. Successful teams hold themselves accountable for the past, but focus on the future. In the Daily Scrum the future is found in what the Team is going to do today and solving any impediments that exist.

50. Answer A. LGd course manual p. 268 - The highest level of Agilist is the Agile Coach. This role is reserved for very experienced Agile leaders and is focused on working from the sidelines just like a coach in football or basketball. An Agile Coach has years of experience in Agile Development and has experienced both successful and failed Agile projects.

Chapter 8 — Adaptive Planning


Page 288

Slide 276

Slide 277

Page 288

Adaptive Planning Adaptive Planning Overview The ninth chapter introduces a topic that describes how an Agilist plans a project in an adaptive or evolving fashion. The push in this section is against what many Agilists see as common among linear methodologies. The idea is actually a very easy one. Agilists contend that project leaders for linear projects build plans that get locked in and therefore they fail to adapt and change as the team discovers new information. This leads to the team either fighting to deliver the right product or service on time, or being completely unable to deliver the right thing. In contrast, linear project leaders view the tact taken by Agilists with fear and trepidation. They argue that Agile strips away all process and rules. Actually, both positions are incorrect assessments. There is nothing in the Waterfall Methodology that prevents it from adapting and changing its plans as necessary. The problem is way people use the methodology. Similarly, good Agile Development makes extensive use of defined processes to deliver project results. This chapter focuses on those processes.

The domain defines ten specific tasks that have been broken down into three groups. They are the following:

Levels of Planning

Plan at multiple levels (strategic, release, iteration, daily) and create appropriate detail by using rolling wave planning and progressive elaboration to balance the predictability of outcomes with the ability to exploit opportunities.

Make planning activities visible and transparent by encouraging the participation of key stakeholders and publish the planning results in order to increase commitment level and reduce uncertainty.

As the project unfolds, set and manage the stakeholders’ expectations and ensure common understanding of the deliverables by making increasingly specific levels of commitments.

Adaptation

In order to maximize value, adapt the cadence and the planning process based on the results of periodic retrospectives about the characteristics and/or the size/complexity/criticality of the project deliverables.

In order to maximize business value delivered, inspect and adapt the project plan to reflect changes in requirements, schedule, budget, and shifting priorities based on team learning, delivery experience, stakeholder feedback, and defects.

Agile Sizing and Estimating

Size items by using progressive elaboration techniques in order determine the likely project size in a way that is independent of team velocity and external variables.



Page 289

Slide 278-279

Slide 280

Adjust capacity by incorporating maintenance and operations demands and other factors in order to create or update the range estimates.

In order to develop a starting point for managing the project, create initial scope, schedule, and cost range estimates that reflect current the high level understanding of the effort necessary to deliver the project.

In order to manage the project well, refine the scope, schedule, and cost range estimates so that they reflect the latest understanding of the effort necessary to delivery the project.

In order to evaluate the estimate of what is necessary to complete the project, continuously use data from changes in resource capacity, project size and velocity metrics.

Agile Planning Core Concepts Adaptation is a central focus of Agile Development, and is a key to the method’s delivery of better project results. However, many people are confused by what Adaptive Planning is. Traditional project planning concepts harken back to a topic discussed earlier in this course, waste. The notion is simple: to succeed, a project leader must do everything in their power to reduce the amount of non-value added work on the project. Based on their experience, Agilists quickly concluded that traditional planning commonly includes much waste. The logic follows that since planning is a form of waste, it must be minimized. At the same time, the project leader has a voice telling them that planning is really, really important. In real life, rarely does this scenario balance out. It typically plays out in one of two extremes: either the leader adopts a minimalist attitude towards planning and does very little, or they listen to that little voice too much and planning becomes the key to the universe. In either case the project often fails to deliver and the team suffers. Many traditional project leaders look at Agile Development and the see the minimal amount of up-front planning. Upon seeing this they have a knee-jerk reaction, “How can this ever work with so little planning?” Unfortunately, they miss the entire argument Agilists make concerning planning.

Agilists argue that the only way to successfully plan a project is to plan and then re-plan, and then re-plan some more. That’s right, Agile Development plans as much, if not more than linear development. The difference is that Linear Development does most—if not all—of the planning to the beginning of the project, whereas Agilists cycle through planning constantly as more information becomes available. Part of the concept of Adaptive Planning is the idea that early plans are inherently inaccurate and that this creates constant uncertainty. It is this uncertainty that drives the need to re-plan. Unlike what many traditionalists would have you believe, this process does have a structure and a cadence, both of which are key.

This structure and cadence begins with the concept of timeboxing. TIMEBOXING represents short, fixed-duration periods of time in which the activities or work of the project take place. An important way that Timeboxing differs from linear development is that instead of locking the scope of the project, timeboxing fixes the amount of time used for each phase, iteration, or meeting in



Page 290

Slide 281

Slides 282-286

Slide 287

the project. Common examples of timeboxing include the Daily Scrum Meeting, which is timeboxed to fifteen minutes. Similarly, a Scrum Sprint is timeboxed to between two and six weeks. In each of these cases, the length of time the item can take is fixed. The critical question is how much work can be delivered in that amount of time.

Timeboxing is combined with another key Agile concept, PROGRESSIVE ELABORATION. This refers to the process of capturing more detail over time as that information emerges. This concept sets the team up for greater success because it does not put pressure on the team to know everything up front. Progressive Elaboration is used constantly throughout the Agile process during stages of estimating, establishing Work Breakdown Structures, planning, defining acceptance criteria, and during the entire testing process. There are two categories of progressive elaboration that are most often used.

The first type of Progressive Elaboration is called Rolling Wave Planning. It represents detailed planning that is done for activities in the near-term. Only high-level planning is done for the necessary activities to be performed far into the future. When Rolling Wave Planning is used, the team focuses on the detailed information they know. This information typically applies most to near-term items. As the project moves forward, the team adds more details to their plans. This is both an iterative and intermittent process.

The second type of Progressive Elaboration is called prototyping. Prototyping is the idea of creating a small version of a function to learn how it works. Process tailoring is the concept that the team changes the process over time to meet the ever-changing needs of the project. Process Tailoring requires the team to answer a series of questions including the following:

What is going well? What areas could use improvement? What should the team do differently?

The Agile Pyramids

Agile offers a number of images to describe key concepts. One of the most common is pyramid. The Agile Pyramid is used to describe three important ideas related to Agile Development. The first way the Agile Pyramid is used is that it describes the product’s functionality and User Stories. This use of the pyramid comes from the discipline of Lean Manufacturing. In this scenario, the pyramid is built using a series of blocks or boxes. These



Page 291

Slide 288

represent User Stories or features. The stories are ranked based on their importance to the customer. At the very bottom are stories that are most important or critical to the customer. These stories are required to make the product recognizable as a real product. As the stories are stacked they become less and less important.

The stories at the very bottom of the pyramid make up the Minimum Viable Product. This is defined as the product with the highest return on investment versus its risk. It is the sweet spot between a product that does not have the required features (that fails the customer before even being used) and a product with so many features that they reduce the overall return and increase the organizational risk. Often referred to as the MVP, the term Minimum Viable Product was first used by Frank Robinson and then popularized by Steve Blank and Eric Ries. A minimum viable product has just those core features that allow the product to be deployed, and no more. The product is typically deployed to a subset of possible customers, such as early adopters that are thought to be more forgiving, more likely to give feedback, and able to grasp a product vision from an early prototype or from marketing information. It is a strategy targeted at avoiding building products that customers do not want, and that seeks to maximize the information learned about the customer per dollar spent. "The minimum viable product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort."[6] The definition's use of the words maximum and minimum means it is decidedly not formulaic. It requires judgment to figure out, for any given context, what MVP makes sense.

Above the MVP is the MMF, or the Minimally Marketable Features. The MMF represents the smallest set of functionality that must be realized in order for the customer to perceive value. A single Minimally Marketable Feature is characterized by three attributes:

Minimum — A feature is something that is perceived by itself as having value by the customer. It is something that matters to the customer.

Marketable — Marketable means that it provides significant value to the customer. The distinction between minimum and marketable is the word significant. This can come in the form of revenue generation, cost savings, competitive differentiation, brand-name projection, or enhanced customer loyalty.

Feature — A feature is a discrete piece of functionality that is relatively independent of the others.



Page 292

Slide 289

Slide 290-291

The second way that the Agile Pyramid is used is to describe and organize the relationship between the different Agile Methodologies. As you climb the ladder, the tools provide greater and greater perspective. The lower you go on the scale, the more philosophical and difficult to hold. These items are value and idea based. The lower you are on this pyramid, the wider the pyramid is and the more widely the idea is applicable. The higher you go up the pyramid, the more specific the tool and less applicable it is. At the bottom of the pyramid is basic organizational learning. This includes concepts like getting better over time, making mistakes and learning from them, etc. Above this level is Lean Thinking, which describes a way of examining and viewing projects. The idea of Lean thinking comes from the manufacturing arena but is adaptable to most projects. Above this are the basics of Agile Software Development described by the Agile Principles and the Agile Manifesto. At the top of this pyramid are the specific Agile Methodologies of Extreme Programming and Scrum.

The third way the Agile Triangle is used is called the Agile Test Pyramid. This diagram shows the levels of testing in an Agile environment. At the lowest level are the individual unit tests. These tests cover the individual features and are automated and done by the developer who writes the code. Above this level are the Integration Tests that ensure that features work together as designed. The third level of the Agile Testing Pyramid are the Acceptance Tests. These tests are typically run by a quality assurance groups or other group that represent the business. The purpose of these tests is to enable the customer to determine if the delivered functionality works as promised. The fourth level of testing covers the graphical user interface or GUI. These tests allow experts in the user experience to test weather or not the software interface provides the customer with an experience that is conducive to achieving the desired end. At the top of the Testing Pyramid are the User Acceptance Testing conducted as part of a beta test or a prerelease.

Value-Based Analysis

A large part of Adaptive Planning requires the team to spend significant time considering the value that the features and work items in the Backlog add to the business, and then act according to the outcome of that analysis. This process demands that the team prioritize the features and/or the work of the project in a



Page 293

Slide 292-295

way that always ranks as highest the items of greatest value to the customer. This process cannot be done blindly and must include the cost of delivering the feature as part of its calculation of value. True Agile Planning requires the leader to initiate this process at the point of eliciting the requirements from stakeholders, before ranking the requirements and then pulling the prioritized requirements into the development process. Because we they use processes such as Rolling Wave Planning, these requirements are typically coarsely grained, and will become more refined as the team continues its work.

Agile Games

One of the most popular tools used by the Agilist is the Agile Game. Like all board games, Agile games have rules. However, unlike most board games, Agile games do not have a defined “winner.” Instead, everyone who plays wins by participating in the game. The goal of almost every Agile game is to provide an engaging way for the team to work with each other and with the customer to discover new information that is needed to succeed. There are literally hundreds, perhaps even thousands, of Agile games available and more are created every day. All it takes is a little imagination and time to create a game. There are several websites dedicated to these games. One of the most popular is http://www.tastycupcakes.org. The list below shows some of the most popular Agile games and their characteristics.

Remember the Future — This is a brainstorming game designed for teams and customers who are meeting in a conference room or a shared space. It focuses the group on what conditions are important to everyone for some future state. Each member of the group works independently with a pad of PostIt Notes™. The group spends the first 20 minutes of the exercise writing independent thoughts down on the PostIts™ that represent what a perfect future looks like for both the team and the customer. It is important that each stickie represent a unique and independent idea. Once the team has completed their writing exercise the members are brought back together. The stickies are then placed on a whiteboard or a wall so that duplicates can be removed and like items can be grouped.

Prune the Product Tree — This is a game that is focused on features. It is designed to give the customer and Development Team a simple method to visualize the importance of various project features. The game begins with the facilitator drawing a large tree on a whiteboard or a poster board. Stakeholders are then asked to write the desired features or project requirements on 3” x 3” PostIt Notes™ that are added to the tree as leaves. Similar features are then grouped onto branches. Finally, the group considers whether or not a feature is “core” to the project’s success. These requirements or features are moved closer to the trunk. As the features or requirements are added, the tree begins to fill out and this creates a powerful visual image. The tree might be completely full of leaves or more sparse, but the picture is still easy for users to comprehend. The more important something is, the closer it is to the trunk of the tree. Finally, the tree visual allows the customer to prune branches if they discover there are too many.



Page 294

Speedboat — This is a risk management exercise designed to work in conjunction with requirements gathering games such as Prune the Product Tree. In this exercise, the facilitator draws an image of a sailboat on a body of water. The group then proceeds to review the project requirements or features with a focus on discovering potential project risks. Speedboat uses the same 3” x 3” PostIts™ that the last game used. However, in this game they are used to represent potential project risks. Positive risks are placed in the sky and represent “wind” that can push the project forward. Negative risks are placed below the waterline and represent drag on the sailboat. Really big negative risks represent rocks that can potentially damage the hull of the boat and must be avoided at all costs.

Buy a Feature — Another common game used for requirements prioritization is Buy a Feature. In this game the customers are asked to create a list of potential features and to provide each with a price. Just as with a real product, the price can be based on development costs, customer value, or something else. Although the price can be the actual cost you intend to charge for the feature, this is usually not required. Customers buy features that they want in the next release of your product using play money you give them. Make certain that some features are priced high enough that no one customer can buy them. The customers are encouraged to pool their money to buy especially important and/or expensive features. This will help motivate negotiations between customers as to which features are most important. This game works best with four to seven customers in a group, so that you can create more opportunities for customers to pool their money through negotiating. The Buy a Feature game is based on the list of features that are likely to be in your development road map.

Bang for the Buck — The goal of this game is to help the team prioritize the Product Backlog. The game involves collaboration among the product manager and development team to prioritize backlog items. Rather than blindly moving down your agenda without any direction, this game allows the team to analyze the costs and benefits of each task, and to organize them in a way that shows where to begin and how to proceed through the items on the list. Before the meeting, draw a graph with the “value” of the items on the y-axis and the “cost” of them on the x-axis, organizing each axis as a Fibonacci number. Write the backlog items on sticky notes and post them by the chart. Ask your players to write down other tasks and to put them along with yours. As a group, take time to discuss where each item belongs on the graph. The product manager should focus on what the “value” position of the task is, while the development team should concentrate on the “cost” of the item. With multiple players you can get different perspectives on the aspects of each item. After all the items have been posted, use the chart to get started on your agenda. Follow the graphed items in a clockwise order to optimize value delivery. If one item must be accomplished soon, but is too costly to start right away, work together to identify how to move it to the left on the graph. This game helps to prioritize both short-term and long-run tasks. By comparing the value and cost of each item, you can collaborate to alter approaches for the



Page 295

Slide 296-298

tasks depending on which are most important. The discussion and visualization involved in Bang-for-the-Buck helps you think differently about where to begin working. This not only increases efficiency and productivity, but it also allows you to see an impact faster.

Agile Estimation

As has previously been discussed, Agile Development assumes that the work required to complete the project includes some level of complexity and uncertainty. Because of this, estimates are often inaccurate. However, Agilists also recognize that estimates are necessary for project sizing, executive approvals, calculating a Return on Investment (ROI), and a number of other needs. Therefore some value must be provided. But, Agilists want to provide estimates that take compensate in some way for all the limitations they experience with traditional estimating techniques.

The first consideration is what type of estimate to provide. Most project leaders limit their estimates to the time/money required to execute the project. However, in many cases it makes a lot more sense to provide holistic estimates. A holistic estimate includes development costs, rollout costs, and sustainment costs because this additional information can significantly impact key decisions. To convey the accuracy—or lack thereof—of an estimate, a team is required to always provide a range rather than a single number. This range helps the team communicate the level of uncertainty in the value. Agile Development uses a process that is both iterative and incremental. This applies to estimating as well. As the team learns new information, they are required to include this information into the estimates, thus requiring the team to estimate continuously. To ensure that team members have full ownership of these estimates, it is also absolutely critical that the team does the estimating themselves and that they are not simply given the estimates by some other group or individual. In addition to the Planning Poker Technique described earlier, there are a number of other concepts that can help.

Ideal Time — This concept is something every Agilist must consider regardless of the estimating technique used. Many projects struggle with their estimates because the planner assumes the resource is more dedicated than it is. Managers respond by adding significant safety to estimates. Ideal Time is an Agile concept that attempts to address this issue. It requires the Agilist to overtly state that resources are 100% dedicated to a single project. In Agile Development, multi-project assignments are not allowed. Many organizations resist this covenant when first implementing Agile arguing that it just isn’t practical. Agilists overcome this complaint by insisting that project teams stay relatively small. It is much easier to dedicate a small group of people to one project than it is to dedicate a large group.

Relative Sizing — This is a technique often used in the very early stages of a project. It is often called T-Shirt sizing. This technique is comparative in nature, and the estimates never represent actual expectations. But a relative estimate allows the team to compare the size and complexity of one User Story against another. If the first story is worth 5 Story Points, we can then compare the next



Page 296

story to the first. Is it larger or smaller? Is it easier or harder to produce than the first? Common Relative Sizing methods make use of T-Shirt sizes (Small, Medium, Large, Extra Large) or Planning Poker values.

Fibonacci Sequence — This term has been described on multiple occasions in this course. It represents a sequence of values where one number is equal to the preceding two numbers.

Affinity Estimating — This is the process of grouping requirements into categories or collections and is used to group similarly sized user stories together.

Time & Cost Estimation Process — The process of estimating an Agile project is not that different from any other project. The team must first determine the size of the deliverables, features or requirements, and then must calculate the effort required to complete that work. In many cases, there are dependencies between features or requirements that must be documented in some fashion. In a linear methodology, this is the point where the schedule is built. But Agile Development requires the team to go one step further. Recall that Agile Methodologies such as Scrum and XP make extensive use of a Ranked Product Backlog. The primary method of ranking is based on the customers’ prioritization of the features. Hence, the Agilist must first consider the importance of the feature to the customer, and then examine any dependency chain in order to build the schedule. This schedule will also look very different from those of a linear project. It will consist of a Story Map or some other visualization of the Product Backlog.

Wideband Delphi — This is an estimating technique that is used to tap into the knowledge of the group in situations where there are a lot of unknowns or where there is specific domain knowledge required (including in the creation of User Story estimates). It is especially useful for early estimates of large, not-yet-well-understood projects. In such cases it can help the organizational leadership to make a go / no-go decision. The game has five basic steps:

Schedule the estimation meeting for a particular project or a set of projects. The estimators should be team members (and possibly other stakeholders) who are very knowledgeable about the project and are people from whom you need buy-in for the schedule of the project. The sweet spot is between 3-5 estimators, although much larger groups can work by breaking them into 3-5 person sub-groups and then combining those estimates.

Describe what the group is estimating. What part of the project, goals, or outcome are they estimating? What types of resources are they going to include? What units (ideal man-days or man-months, story points, etc.) will they use?

Ask everyone to estimate individually and privately using their best, instinctual judgement on the estimate. Give them enough time (5-20 minutes) to do this work quietly. Once people are familiar with the process, you may be able to ask them to do this before the estimation meeting. Also ask them to take note of the assumptions and major pieces of work that led to the estimate—they’ll use these later in the group discussion. The private/anonymous aspect of this first round of

Slide 299



Page 297

Slide 300

estimates is important: we’re specifically empowering each person to express their gut instinct, and not be influenced by group think yet.

Show the results on a spreadsheet or a whiteboard and discuss. The group can see how divergent or convergent their estimates are. Ask each person (but especially the high/low or other interesting estimators) to explain how they got to their estimate, especially major assumptions, things included, etc. People will then be more likely to remember things they forgot to include in their estimates. They will also be forced to confront different assumptions (which you may be able to quickly decide upon). All of this will improve future rounds of estimates.

Repeat steps 3 and 4 for a total of 2-3 rounds. After round one, anonymity is dropped and discussions can be short (the moderator should make decisions on behalf of group for the sake of expediency and just for the purposes of the estimate). Often only 2 rounds total are needed to see estimates converge somewhat. A common effect is that estimates converge together (and up) as people realize from the discussions all the things they missed from their initial estimates.

Planning Poker — Perhaps no Agile tool is as well known as Planning Poker. There are many different ways to do Planning Poker including regular playing cards and apps for both smartphones and tablets. Regardless of the specific tool, they all work similarly. Planning Poker is similar to a Delphi technique for gathering estimates on a project. A Delphi Technique is used to overcome the influence of a single resource and gain the advantages that come from having an entire group provide opinions about how long and/or difficult project work is expected to be. Delphi Techniques typically include three of four steps, depending on the version. These steps include the following:

Survey the subject-matter experts anonymously about the topic. Aggregate the estimates into a single estimate. Provide the single estimate back to the experts for confirmation.

In Planning Poker, this process is typically done as part of a brainstorming session. Imagine being part of a Scrum Team who has just completed defining the initial Product Backlog. The team spends time understanding these stories with the customer and then begins their discussions. Each member of the development team is given either a deck of cards, or an app for their mobile device. The cards and app provide the exact same thing: a series of cards with numeric values representing a modified Fibonacci Sequence. If you recall from our earlier discussions, a Fibonacci Sequence is a series of numbers where one value is equal to the preceding two. The values most commonly used for Planning Poker include, 1, 2, 3, 5, 8, 13, 20, 40, 100, and ∞. The last symbol represents infinity. Each member of the team has a set of cards with each of the possible values in it. After listening to the customer describe the User Story, and after asking any questions required to ensure understanding, each member of the team holds up a card at the same time to represent the complexity of and time it will take to finish the story. Because each member of the team shows their estimate at the same time, no one resource has undue



Page 298

influence on the rest of the team. Often team members show multiple values. The people who gave the highest and lowest estimates share why they gave the value they did and then the entire team votes again. This process continues until the team reaches consensus. It is important to remember that in most cases, the values provided through Planning Poker are not simply estimates. They most often represent Story Points which are a loose aggregations of time and complexity. Planning Poker is often used in Agile Methods that make use of the User Story. However, Planning Poker is not the only way to provide estimates for an Agile Project.

Project Delays

Almost every project faces challenges of one type or another, and these challenges arise regardless of the methodology used by the team. What is different however, is how the Agile team responds to those challenges. In this discussion we will examine the most common causes of project delays and how Agile Development responds to these issues.

Unfocused Project Management — In today’s world, it is not unusual for a project manager to work on three to five projects at the same time. Additionally, many project managers have little formal training and often create project plans comprised of hundreds or even thousands of individual tasks. This is simply too much information to track—even with the most advanced software. To be successful, you must strive to limit the number of items on your plate even though this is often very difficult. An Agile project should rarely have this struggle because the team is 100% dedicated to the single project and the team is small. It is not unusual for the Scrum Master to be assigned to more than one project, but they should never be assigned to more than two or three at a time, and they rarely do the work of the project. Furthermore, the use of daily reporting, such as that found in the Daily Scrum, ensures that the team is constantly focused on delivering results that day.

A Focus on Task Management — A project manager working on linear projects will focus on tasks. Teams everywhere are doing work, but very little gets delivered. The problem with task management is that it prevents the team or customer from seeing real progress. When a team member has worked late every night for several days they will almost always report they are further along than they really are and the project manager will have no way of knowing any differently. Agile addresses this problem on a daily basis. In Scrum it is called the Daily Scrum. Each day the team gathers to report their progress to each other. They work on tasks that are between 1/2 and 2 days in length so that every day they should accomplish something. Although these are tasks, they are also tied to features or deliverables that are prioritized by the customer. Additionally, the team works in short iterations that require them to show a working product or service to the customer at regular intervals in order to receive feedback. No Agile project ever goes months without delivering something of real value to the customer.

Slides 303-304



Page 299

Dependencies between steps cause delays to accumulate and advances to be wasted — This is a very complicated statement, but what does it really mean? Executing projects successfully is all about the laws of probability. But if this is true, then we should all see about 50% of the tasks or deliverables finished either right on time or early, and the other 50% should be right on time or late. These values should naturally distribute themselves along the normal distribution of a bell curve. Is that your experience? If you are like most project managers, you are laughing at that notion right now. In a majority of cases, the tasks or deliverables in your project consistently take longer than forecasted. How can this be when project management is about probability instead of precision? This happens because there is no incentive for your resources to complete their work early. All the incentives target being only right on time. If and when your resources do get their work done early, they don’t hand it off to the next person. They hold onto the deliverable, check it one more time, add some extra functionality, or simply let it sit on their desk. When this happens, the next resource obtains no advantage from the fact that the first resource was done early. However, if the first resource is late, the second resource is automatically negatively impacted. Agile Development does not attempt to micro-manage the team. Instead Agile does not even try to make accurate estimates for the entire project. Instead Agile plans in very small chunks of a few weeks in length. When more detailed information is captured the team develops a specific plan—but only for that small period.

Parkinson’s Law — This law states that work expands so as to fill the time available for its completion. It was first coined by Cyril Northcote Parkinson in a humorous essay published in The Economist in 1955. This concept is critical. To understand its impact, imagine you have just completed your first project. If you are like most project managers you discovered that most of your resources delivered most of their deliverables late. In an effort to improve this performance on your next project you add a little extra safety to the resource estimates. Does it help? No. In fact, the resources are just as late on the second project. On your third project you add even more safety with the same outcome. However, you also have another problem. Management quickly determines that you are padding the estimates so they begin cutting them. You respond to this by padding extra. Eventually, management figures this out and cuts your estimates even more. This cycle continues indefinitely and through it all your resources continue to deliver their work late. Only now they are delivering late against estimates that are either significantly larger than they should be or they have been changed so many times that they have no resemblance to reality. No matter, your resources are still late. At least you have comfort in consistency! Agile addresses Parkinson’s Law in two ways. First, It does away with any kind of exact estimate. Second, and more importantly, Agile forces the team to self-manage on a daily basis. Every day each member of the team is expected to deliver something to the rest of the group. This model makes it very difficult to pack extra work into a task or do anything but produce the simplest solution that will pass the tests.



Page 300

Safety in projects is misplaced — Safety is the amount of time above the estimate that is required to complete the task or deliverable. Estimates in the real world should initially assume that everything on the deliverable goes perfectly, and then safety is placed on top of that value just in case. However, for most projects the safety is actually imbedded in the duration estimate. This means the project manager has no visibility as to how much of the estimate is actual work and how much is safety. This lack of visibility also means the project manager has no control over how or when the safety is used. To be successful, all safety must be visible to everyone involved in the project. This is exactly what Agile Development does with the Daily Stand-Up and the Team Board. Suddenly everyone sees where the project is and they are expected to produce every single day.

Student Syndrome — Many readers of this manual have children. In most cases those parents regularly give their children the same instructions, “you must do you homework or chores before you can play”. Why is it that we all tell our children the same thing? It is because we have learned over the years that when our children do not do their homework or chores first they either won’t get done or they will be up late completing them. This is the student syndrome. It is the tendency to procrastinate with an assumption that there is plenty of time. In the world of projects we put off work because we have other work to do, because we perceive the task as easy, or because the resource believes they have plenty of safety built into the estimate. Everything would be on schedule if everything went perfectly. But how often does everything go perfectly for you? When we run into problems the deliverable is guaranteed to be late because we have already used all our safety at the beginning. To solve the Student Syndrome we must take our new found safety visibility and ensure that our project resources do not use it until it is absolutely necessary—at the end of each task. The only way this will happen is if you change the way you measure your resources. To be successful, you must hold resources accountable to start on time and to give 100% effort on the deliverable. If this occurs you will see the laws of probability take affect and you will be able to appropriately allocate safety when necessary. Agilists ensure that this happens by assessing work on a daily basis. The chunks of work are small and every day each team member is held accountable by the other members of the team. Peer pressure reduces safety and ensures something is delivered in each iteration.

Lack of Performance Metrics — Performance metrics provide visibility to the actual results of the project. Projects managers that do not use quantitative, objective performance metrics deliver a clear message to their resources that results do not matter. Don’t make this mistake. Use tangible metrics and hold all team members accountable to them. Some who are new to Agile believe it provides open license for the team to move away from quantifiable metrics, but the reality is quite the opposite. Few methodologies push transparent, quantifiable metrics as much as Agile Development. The Team Board, Burndown and Burn-Up Charts are visible at all times for anyone who is interested. Additionally, every day each team member is expected to report to their peers on his or her accomplishments from the previous day.



Page 301

Slide 305

Multi-Tasking — This is the attempt to execute more than one deliverable or task at a time. This can happen within a single project or when the same resource is used on multiple projects at the same time. The ability to multi-task is a misnomer when it comes to development, because time is a finite resource. In the real world no team member can work on more than one thing at a time. Some of us get pretty good at switching back and forth quickly, but it still costs us time to remember where you were. Agile Development specifically outlaws the team from participating in more than one project at a time during a iteration, and even provides tools to deal with large programs.

Planning Differences

Most people are surprised to learn about the commonalities between linear planning and Agile’s Adaptive Planning. However there are also a number of important differences.

Agile Development assumes the team doesn’t know the true requirements even though they might have a lot of things written down. To determine the real project requirements, the team must use trial and demonstration. At each iteration, the team shows the customer the product they have created and receives feedback. The process requires constant replanning as new information is received. Because the team is required to constantly replan based on newly obtained information, and because the entire framework is built on the premise that it is impossible to obtain all the information up front, the team does not spend huge amounts of time in an upfront planning exercise. Do not draw the wrong conclusion and assume that projects completed using Agile Development do not spend significant time planning, however. In fact, when the total time and effort is compared, often the project using Agile spent more time in planning. However, this effort is broken up and done throughout the entire project, and midcourse corrections and adjustments are so common they are the norm. Finally, both linear and Agile projects make use of business cases and charters that differ little when done correctly.

Before continuing to the next chapter, please complete the quiz that follows and be sure to score at least 90%.



Page 302

Adaptive Planning Exercise

1. When comparing Agile Development to traditional, linear methods which of the following is true?

A. Agile Development requires less planning than traditional, linear methods. B. Agile Development does as much planning as traditional, linear methods. C. Agile Development often requires significantly more planning than traditional, linear

methods. D. Agile Development is more efficient because the planning process is heavily front

loaded.

2. Key to the concept of Agile Planning is the fact that Agilists accepts:

A. that early plans are inherently inaccurate which creates constant uncertainty. B. that plans are an artificial construct of the traditional project manager. C. that planning is a necessary evil in the project process. D. that the project planning process does not require strong process or cadence.

3. Which of the following is NOT a component of timeboxing?

A. Timeboxes are short periods of time. B. Timeboxes are fixed periods of time. C. Timeboxes are primarily focused on the length of iterations. D. Timeboxes impact almost every area of an agile project.

4. Which of the following is NOT an example of something in an agile project that is timeboxed?

A. The Daily Scrum B. The Scrum Sprint C. The Sprint Retrospective D. The Agile Project

5. What is the length of a Scrum Sprint according to the original rules of Scrum?

A. 2 to 6 weeks B. 30 days C. 2 weeks D. 6 weeks

6. As an Agile Coach you advise a team that they shouldn't worry about not having all the project details at the beginning of the project because details naturally become apparent as the project progresses. This is an example of what?

A. The agile estimating process B. Progressive elaboration C. Decomposition D. WBS Planning

7. Which of the following is considered a type of progressive elaboration?

A. Rolling wave planning B. WBS decomposition C. Incremental planning components D. Defined iteration planning

Exercise 10 —Adaptive Planning



Page 303

8. Which of the following terms represents the concept of the team changes the process over time to meet the ever changing needs of the project?

A. Process tailoring B. WBS decomposition C. Rolling wave planning D. Defined iteration planning

9. Which of the following terms references the sweet spot between products without the required features that fail the customer before even being used and the products with so many features that they reduce the overall return and increase the organizational risk?

A. The minimally marketable features B. The minimum viable product C. The product backlog D. The baseline feature set

10. Which of the following is NOT a common way of describing the MVP?

A. The sweet spot between products without the required features that fail the customer before even being used and the products with so many features that they reduce the overall return and increase the organizational risk?

B. The product with the highest return on investment versus its risk. C. The MVP seeks to maximize the information learned about the customer regardless of

dollar spent. D. The MVP has just those core features that allow the product to be deployed, and no

more

11. Which of the following has just the core features that allow the product to be deployed, and no more?


12. Which of the following provides a a strategy targeted at avoiding building products that customers do not want, that seeks to maximize the information learned about the customer per dollar spent?

A. The product backlog B. The baseline featureset C. The minimally marketable features D. The minimum viable product

13. Which of the following represents the smallest set of functionality that must be realized in order for the customer to perceive value?


14. In examining the Agile Pyramid, what is found beneath the concepts of Lean Thinking?

A. XP B. Scrum C. Agile software development D. Organizational learning



Page 304

15. Which of the following types of tests sits at the bottom of the Agile Test Pyramid?

A. GUI tests B. UAT / Beta tests C. Integration tests D. Unit tests

16. What kind of tests have the purpose of the customer determining if the delivered functionality works as promised?

A. UAT beta tests B. Acceptance tests C. Integration tests D. Unit tests

17. The BEST definition of value-based analysis is:

A. The process of prioritizing features of greatest value to the customer highest. B. The process of ordering features based on cost. C. The process of modeling the project's feature set based on the organization's

definition of value. D. The process of prioritizing features based on organizational revenue impact.

18. What is the goal of most agile games?

A. To help the team define the minimally viable product. B. To present an engaging way for the team to work with each other and the customer to

discover new information needed to succeed. C. To present an engaging way for the team to work with the customer to define the

definition of success. D. To help the customer understand the agile process used by the team.

19. Which agile game has the group spends the first 20-minutes of the exercise writing independent thoughts down on the PostIts™ representing what a perfect outcome would look like for the team and customer where each stickie represents a unique and independent idea.

A. Prune the product tree B. Buy a feature C. Remember the future D. Bang for the buck

20. Which of the following agile games focuses the group on potential project risks?

A. Wideband Delphi B. Remember the future C. Bank for the buck D. Speedboat

21. Which agile technique is designed to overcome the influence of a single resource and gain the advantages that come from have the entire group provide opinions?

A. Planning poker B. Speedboat C. Prune the product tree D. Remember the future

22. Agilist generally attempt to complete what kind of estimate?

A. Complete B. Holistic C. Accurate D. Complex



Page 305

23. What is the agile concept using in estimating that requires resources to be 100% dedicated to a single project?

A. Affinity estimating B. Fibonacci sequencing C. Complete time D. Ideal time

24. Another name for the agile practice of relative sizing is:

A. Fibonacci sequencing B. Affinity estimating C. T-shirt sizing D. Delphi technique

25. Your team has just completed its 3rd sprint where your delivered 14 story points, but had forecast delivering 18. At this point you should:

A. Conduct your retrospective. B. Conduct your sprint review. C. Adjust your plan to show the forecast of 14 points. D. Place the uncompleted stories back on the product backlog.

You boss is comparing your team's productivity to another. Your team is currently producing 30 story points per sprint and the other team is completing 60. Your boss wants to know why they are 100% more productive. What do you tell them?

A. The teams are not the same size so their productivity won't be either. B. The projects are for entirely different departments therefore the projects can't be

compared. C. Story points are unique to each project so their 60 has no comparison to your 30. D. You team has had a difficult time with the project and will do better.



Page 306

Adaptive Planning Exercise Answer

1. Answer C. LGd course manual p. 287 - Agile Development argues that the only way to successfully plan a project is to plan and then re-plan, and then re-plan some more. That’s right, Agile Development plans as much, if not more than linear development. The difference is that Linear Development pushes most, if not all, of this planning to the beginning of the project whereas Agile cycles through planning constantly as information becomes available.

2. Answer A. LGd course manual p. 288 - The concept of Adaptive Planning accepts that early plans are inherently inaccurate which creates constant uncertainty, and it is this uncertainty that drives the need to re-plan. And, unlike what many traditionalists would have you believe this process does have structure and cadence that is key.

3. Answer C. LGd course manual p. 288 - Timeboxing represents short, fixed-duration periods of time in which the activities or work of the project take place. Timeboxing creates a difference from linear development. Instead of locking the scope of the project, timeboxing fixes the amount of time used for the phase, iteration, or meeting. Common examples of timeboxing include the Daily Scrum Meeting that is timeboxed to fifteen minutes, or a Scrum Sprint that is timeboxed to between two and six weeks.

4. Answer D. LGd course manual p. 288 - Common examples of timeboxing include the Daily Scrum Meeting that is timeboxed to fifteen minutes, or a Scrum Sprint that is timeboxed to between two and six weeks.

5. Answer B. LGd course manual p. 289 - The key to this question is the "original rules of Scrum." Most current implementations of Scrum set a sprint duration at the beginning of the project between 2 and 6 weeks, the original rules said a sprint's length was 30 days.

6. Answer B. LGd course manual p. 289 - Timeboxing is combined with another key Agile concept, Progressive Elaboration which is the process of capturing more detail over time as that information emerges. This concept sets the team up for greater success because it does not put pressure on the team to know everything up front. Progressive Elaboration is used constantly throughout the Agile process including estimating, Work Breakdown Structures, planning, acceptance criteria definition, and the entire testing process.

7. Answer A. LGd course manual p. 289 - Rolling wave planning is detailed planning done for activities in the near term. Only high-level planning is done for necessary activities to be performed far into the future. When Rolling Wave Planning is used the team focuses on the detailed information they know. This information typically applies most to near term items. As the project moves forward the team adds more details to their plans. The is both an iterative and intermittent process.

8. Answer A. LGd course manual p. 289 - Process tailoring is actually a very easy idea. It is the concept that the team changes the process over time to meet the ever changing needs of the project. Process Tailoring requires the team to answer a series of questions including: What is going well? What areas could use improvement? What should the team do differently? It is a form of progressive elaboration.

9. Answer B. LGd course manual p. 290 - The Minimum Viable Product is defined as the product with the highest return on investment versus its risk. It is the sweet spot between products without the required features that fail the customer before even being used and the products with so many features that they reduce the overall return and increase the organizational risk. Often referred to as the MVP, the term Minimum Viable Product was first used by Frank Robinson and then popularized by Steve Blank and Eric Ries. A minimum viable product has just those core features that allow the product to be deployed, and no more.



Page 307

10. Answer C. LGd course manual p. 290 - The Minimum Viable Product is defined as the product with the highest return on investment versus its risk. It is the sweet spot between products without the required features that fail the customer before even being used and the products with so many features that they reduce the overall return and increase the organizational risk. Often referred to as the MVP, the term Minimum Viable Product was first used by Frank Robinson and then popularized by Steve Blank and Eric Ries. A minimum viable product has just those core features that allow the product to be deployed, and no more. The product is typically deployed to a subset of possible customers, such as early adopters that are thought to be more forgiving, more likely to give feedback, and able to grasp a product vision from an early prototype or marketing information. It is a strategy targeted at avoiding building products that customers do not want, that seeks to maximize the information learned about the customer per dollar spent.

11. Answer B. LGd course manual p. 290 - The Minimum Viable Product is defined as the product with the highest return on investment versus its risk. It is the sweet spot between products without the required features that fail the customer before even being used and the products with so many features that they reduce the overall return and increase the organizational risk. Often referred to as the MVP, the term Minimum Viable Product was first used by Frank Robinson and then popularized by Steve Blank and Eric Ries. A minimum viable product has just those core features that allow the product to be deployed, and no more. The product is typically deployed to a subset of possible customers, such as early adopters that are thought to be more forgiving, more likely to give feedback, and able to grasp a product vision from an early prototype or marketing information. It is a strategy targeted at avoiding building products that customers do not want, that seeks to maximize the information learned about the customer per dollar spent.

12. Answer D. LGd course manual p. 290 - The Minimum Viable Product is defined as the product with the highest return on investment versus its risk. It is the sweet spot between products without the required features that fail the customer before even being used and the products with so many features that they reduce the overall return and increase the organizational risk. Often referred to as the MVP, the term Minimum Viable Product was first used by Frank Robinson and then popularized by Steve Blank and Eric Ries. A minimum viable product has just those core features that allow the product to be deployed, and no more. The product is typically deployed to a subset of possible customers, such as early adopters that are thought to be more forgiving, more likely to give feedback, and able to grasp a product vision from an early prototype or marketing information. It is a strategy targeted at avoiding building products that customers do not want, that seeks to maximize the information learned about the customer per dollar spent.

13. Answer A. LGd course manual p. 290 - Above the MVP is the MMF, or the Minimally Marketable Features. The MMF represents the smallest set of functionality that must be realized in order for the customer to perceive value.

14. Answer D. LGd course manual p. 291 - At the bottom of the pyramid is basic organizational learning. This is getting better over time, making mistakes, and learning from them. Above this level is Lean Thinking which describes a way of examining and viewing projects. Its ideas largely come from the manufacturing arena, and it’s ideas are adaptable to most projects. Above this are the basics of Agile Software Development described by the Agile Principles and the Agile Manifesto. At the top of this pyramid are the specific Agile Methodologies of Extreme Programming and Scrum.

15. Answer D. LGd course manual p. 91 - The third use of the Agile Triangle is called the Agile Test Pyramid. At the lowest level are the individual unit tests. These tests cover the individual features, are automated and done by the developer who writes the code.

16. Answer B. LGd course manual p. 291 - The third level of the Agile Testing Pyramid are the Acceptance Tests. These tests are typically run by a quality assurance group or other group that represents the business. The purpose of these tests is for the customer to determine if the delivered functionality works as promised.



Page 308

17. Answer A. LGd course manual p. 291 - Value-based analysis demands the team prioritize the features and/or the work of the project in a way that always ranks the items of greatest value to the customer highest. However, this process cannot be done blindly and must include the cost of delivering the feature as part of its calculation of value. True Agile Planning requires the leader to initiate this process even earlier at the point of eliciting the requirements from stakeholders, before ranking the requirements, and then pulling the prioritized requirements into the development process.

18. Answer B. LGd course manual p. 292 - The goal of almost every Agile game is to present an engaging way for the team to work with each other and the customer to discover new information needed to succeed.

19. Answer C. LGd course manual p. 292 - is a brainstorming game designed for teams and customers who are meeting in a conference room or other shared space. It focused the group on the conditions of a future state to determine what is important to everyone. Each member of the group works independently with a pad of PostIt Notes™. The group spends the first 20 minutes of the exercise writing independent thoughts down on the PostIts™ representing what a perfect future would look like for the team and customer. It is important that each stickie represents a unique and independent idea. Once the team has completed their writing exercise they are brought back together. The stickies are then brought together on a whiteboard or wall so duplicates can be removed and like items grouped.

20. Answer D. LGd course manual p. 293 - Speedboat — This is a risk management exercise designed to work in conjunction with requirements gathering games such as Prune the Product Tree. In this exercise, the facilitator draws an image of a sailboat on a body of water. The group then proceeds to review the project requirements or features with a focus on discovering potential project risks. Speedboat uses the same 3” x 3” PostIts™ that the last game used. However, in this game they are used to represent potential project risks. Positive risks are placed in the sky and represent “wind” that can push the project forward. Negative risks are placed below the waterline and represent drag on the sailboat. Really big negative risks represent rocks that can potentially damage the hull of the boat and must be avoided at all costs.

21. Answer A. LGd course manual p. 295 - Perhaps no Agile tool is as well known as Planning Poker. There are many different ways to do Planning Poker including regular playing cards and apps for both iDevices and Android phones or tablets. Regardless of the specific tool, they all work similarly. Planning Poker is similar to a Delphi technique for gathering estimates on a project. A Delphi Technique is used to overcome the influence of a single resource and gain the advantages that come from having an entire group provide opinions about how long and/or difficult project work is expected to be.

22. Answer B. LGd course manual p. 295 - Agilists try to create holistic estimates. A holistic estimate requires the inclusion of development costs, rollout costs, and sustainment costs as this additional information can significantly impact key decisions.

23. Answer D. LGd course manual p. 296 - Ideal time is something every Agilist must consider regardless of the estimating technique used. Many projects struggle with their estimates because the planner assumes the resource is more dedicated than they are so they respond by adding significant safety to estimates. Ideal Time is an Agile concept that attempts to address this issue. It requires the Agilist to overtly state that resources are 100% dedicated to a single project. In Agile Development, multi-project assignments are not allowed.

24. Answer C. LGd course manual p. 296 - This is a technique often used in the very early stages of a project. It is often called T-Shirt sizing. This technique is comparative in nature and the estimates never represent actual expectations. Instead, a relative estimate allows the team to compare the size and complexity of one User Story against another. If one story is worth 5 Story Points we can then compare the next story to the first. Is it larger or smaller than the first? Is it easier or harder to produce than the first? Common Relative Sizing methods make use of T-Shirt sizes (Small, Medium, Large, Extra Large) or Planning Poker values.



Page 309

25. Answer D. LGd course manual p.296-297 - Agile development does not require the team to complete all the committed stories in every sprint. In fact, this tends to be the exception. When the team fails to complete stories in a sprint they are placed back in the product backlog to be reprioritized and worked in future sprints. Once this is done the team can turn their attention to the review and retrospective. You should never erase the original plan as it prevents the team from determining their actual cadence.

26. Answer C. LGd course manual p. 295 - When using story points it is critical that you remember that each project creates its own scale for the value of each point. Therefore, it is impossible to compare the value of productivity from one project to another using only story points.

Chapter 9 — Problem Detection & Resolution


Page 310

Slide 307

Slide 308

Page 310

Problem Detection & Resolution Problem Detection & Resolution Overview At this point in an Agile project, it is time for the team to act according to the processes, backlogs, and plans established by the team. It is also time to look for things that might go wrong. Many project leaders refer to these issues euphemistically as “opportunities.” PMI® refers to situations where things do not go as planned as “problems” and outlines two core aspects of the domain, problem detection and resolution. The first part is all about determining that a problem exists and the second part is concerned with fixing the issue. Within this domain there are five defined domain tasks. These include the following:

To surface problems and impediments that are slowing the team down or preventing its ability to deliver value, create an open and safe environment by encouraging conversation and experimentation.

To resolve issues at the appropriate time and improve processes that caused the issues, identify threats and issues by educating and engaging the team at various points in the project.

To maximize the value delivered, ensure that issues are resolved by appropriate team members and/or reset the expectations of the team in light of issues that cannot be resolved.

Maintain a visible, monitored, and prioritized list of threats and issues in order to elevate accountability, encourage action, and track ownership and resolution status.

Communicate status of threats and issues by maintaining a threat list and by incorporating activities into the backlog of work in order to provide transparency.

Key Concepts

The first tool used to help detect project problems is Cycle Time. Cycle Time represents the amount of time it takes to get things done. The concepts and uses surrounding Cycle Time are closely related to Work in Progress or WIP. If you recall from an earlier point in this course, WIP represents items the team is currently attempting to complete but has not yet completed. They are in process. The typical work process can be thought of as a pipe. Imagine fluid entering one end of the pipe and then exiting the other. The fluid that is in the pipe at any point and time is the WIP. How long it takes the fluid to go from one end of the pipe to the other end is the project’s Cycle Time. By these definitions, WIP represents money spent without a return to the customer, who must wait for the feature to be completed in order to obtain any value. While the work is in the pipe, problems and inefficiencies can often be hidden. Additionally, the incomplete features or project requirements found in WIP represent project risk in the form of rework. Because they are not yet complete and approved by the customer, there is a risk that they could be incorrect and unapproved. This presents potential for rework.



Page 311

Slide 309

Slide 310

Agilists work to constantly reduce both WIP and Cycle Times. They attempt to have less going on at a single moment and to get those items done as quickly as possible. The relationship between Cycle Times, WIP, and Throughput is defined by the formula:

The relationship between these drivers also impacts change on the project. A core axiom for this area is that as time progresses on a project, the value of any change reduces. At the same time, the cost to make the change rises. At some point, the value of making the change becomes less than the cost to make it and the change should not be made. The reason for this rule is that the longer a project goes, the more investment of time, money, and resources has occurred. This locks pieces of functionality into place, and often makes it difficult for both team members and customers to accept change. The key is for the team to understand when the crossover has occurred, and to ensure that it does not allow any change to occur after that point.

Leaders must also ensure that they understand the difference between changes and defects. Both require additional time and money. Changes are previously unknown requirements or features that may cause adjustments to the project requirements. Defects do not represent adjustments to the list of project features or requirements. Instead, defects represent situations where features fail in some way to pass a defined test. The Daily Stand Up is used to identify most defects. However, the Daily Stand Up is not perfect. A defects that the Daily Stand Up misses is called an Escaped Defect. Escaped Defects represent the most expensive kind of defects to fix. They require the team to repair functionality they believed was already complete. This prevents the team from moving on to new functionality. This is generally bad and therefore the team must constantly measure the number of Escaped Defects Found. In well managed teams, the trend is to see this number decline over time.

The team must also ensure that they clearly understand what they must produce. A key concept that helps with this goal is Fitness for Purpose. A product or

Cycle Time = WIP . Throughput



Page 312

Slide 311

Slide 312-314

service’s Fitness for Purpose statement defines whether or not the product will meet the intended business need. This concept ties back to the Agile concepts of the Definition of Done, Sprint and Release Goals. Each of these requires the team to think about what they will do to ensure that the quality and value of the product meets the business’ needs. Establishing metrics to ensure the expected delivery is critical, and there are a number of metrics often used to promote the desired team behavior. These include the following:

Tracking the tests that have been passed and the customer’s acceptance. These two measures track two components of the same value change. Tracking Tests Passed tells the team how many units of productivity have been produced successfully. Measuring Customer Acceptance tells the team how many completed features have been accepted by the customer.

Automating tests. Agile Development makes extensive use of Test Driven Development. Part of this concept includes the requirement that most of the unit tests are automated.

Constant testing. In Agile Development, testing is not an occasional activity or one that is only done at the end of the project. Testing drives the development and is constantly done.

Ensure that the testers and developers communicate and collaborate constantly. This is a very different model than the one found in many traditional frameworks. Many frameworks build a wall between the developers and testers. There is simply no reason for the two groups to communicate. In Agile Development this is not true. Agilists require that testers and developers work together on a daily basis. Tests are run throughout the entire project, not just at the end.

Failure Modes and Alternatives

Almost every project experiences challenges at one point or another. The key is how the team is positioned to overcome these challenges and the alternatives they choose. A common phrase in Agile is “Fail fast.” This phrase focuses the team on delivering something as fast as possible to the customer. The team can then obtain feedback on what they did correctly and incorrectly. Then, they can make adjustments. This basic process requires that the entire organization be willing to accept mistakes. However, this does not mean there is willingness to accept every kind of mistake. The concepts surrounding Agile Development contend that by making early mistakes often the errors will be much smaller, and smaller mistakes are easier and cheaper to fix. This is a preference towards failing conservatively allowing the team to invent and gain valuable knowledge through experience rather than simply researching. Agile Development understands that most of us are creatures of habit. Most of us tend to fall into predictable patterns and stay there. A goal of Agile Development is to prevent people either from doing the same thing over and over again just because that is what they did in the past or from becoming totally inconsistent. The goal is to find a middle ground where the team examines their practices at regular intervals and constantly improves.



Page 313

Slide 315

Alistair Cockburn asserts that great teams get that way because they are good at looking around and seeing what others are doing. They understand that projects do not exist in isolation, and they learn from others and from their environment. They cannot be set in their ways. A great team is one that is capable of changing and adapting to their environment and to the changing needs of their organization. Teams that meet these standards are able to take pride in their work and achieve fantastic results. There are a number of other characteristics successful Agile teams display that help them determine when problems occur and what they should do about those problems.

Agile teams respond to project challenges with discipline and tolerance: They are disciplined with their processes and tolerant towards different ideas. They start with something concrete and tangible before moving to the unknowns. Rather than reinvent everything, Agile teams copy the best ideas from others and alter the solutions as needed. They also spend a lot of time watching and listening to others to learn from the mistakes other teams make. They embrace extensive processes that support concentration and communication amongst team members and customers. They allow the team members to take assignments that match their individual personality and use all the talents of the team to the organization’s maximum advantage. Great Agile teams also take the time to create reward systems that preserve the fun and joy of the team. If the team is not having fun they will become distracted and eventually lose focus. In many cases, the successful Agile team combines its rewards and uses processes that ensure that everyone on the team receives lots of feedback.

Control Charts

A tool often used by teams across all methodologies is the Control Chart. A Control Chart is used when there is a process that produces multiple units. The easiest example is a manufacturing process such as the Acme Widget Factory. Imagine tracking the output from one of the organization’s production lines. As each widget is completed, it is measured to ensure it meet specific weight guidelines. The team has defined an optimal weight as well the most and least each widget can weigh and still meet Acme’s quality standards. The image below shows a sample of the chart for this scenario. On the graph, notice the three variables that appear on the left. The X with the line over it represents the Mean of the distribution. This is defined as the sum of the values divided by the count.



Page 314

316-317

Below the mean is the Lower Control Limit. This is the lowest weight a widget can have and still be considered to have met the quality standards. The UCL represents the Upper Control Limit, or the most a widget can weigh and still meet the quality standards. On the far right are six additional legend items. The special character represents Sigma, or Standard Deviation. It represents a consistent and calculated distance away from the Mean. At one Standard Deviation away from the Mean 68% of the cases occur. At two Standard Deviations on either side of the Mean 95% of the cases occur, and at three Standard Deviations away from the Mean 99% of the cases occur. We say the process is “in control” when all the cases appear within the control limits. These limits are often established via contract as contract specifications or requirements, customer expectations, or specification limits. When discussing Control Charts, a common concept is the Rule of Seven. The Rule of Seven say that if a Control Chart ever shows seven consecutive cases either above or below the Mean, then the Mean has shifted. In the example chart there are seven consecutive cases above the Mean, but they are not consecutive so the Mean does not need to be recalculated.

Continuous Integration

Many software development projects struggle when it comes time to integrate the new product with the existing code base. Typically, this integration only occurs once at the very end of the project. This provides the team with only a single chance to get it right. If there are any problems, the project quickly degenerates. In Agile Development, the team continuously integrates their output. If there is a problem in an Agile project, therefore, the team is able to discover it more quickly and adapt as necessary. A number of tools make this processes easier, including the following:

Source Code Control System — This is a common tool used in software development. It’s a software application that allows a team of developers to manage code development. In many ways it acts like a librarian, allowing team members to check-in and check-out code components. Many such systems also provide automated unit tests along with other functions that make it easier for a team of developers to work together efficiently.

Build tools — In developer parlance, "build" consists of the process through which a project starts from files and other assets under the developers' responsibility and results in a software product in its final or "consumable" form. This may include compiling source files into compressed formats (jar, zip, etc.) and it also includes the production of installers, the creation or updating of database schema or data, and so on. The build is "automated" to the extent that these steps are repeatable and require no direct human intervention, and can be performed at any time with no information other than what is stored in the source code control repository. A build tool is any application that automates or assists with this process.

Test Tools — Most software development today includes the use of software applications that automate the testing process. These tools improve the consistency and quality of many aspects of the testing process.



Page 315

Slide 318

Slide 319-321

Scheduler or Triggers — A Scheduler or a Trigger can be as simple as a listening application that looks for the occurrence of defined events before starting a predefined process or an application that starts a program at specified times. This is often done as part of a testing sequence.

Notifications — It can dramatically improve the delivery times for a development team when team members are automatically informed about system changes, component check-ins or test results.

Some people who are not familiar with continuous integration question its value, but Agilists contend there are a number of reasons to use continuous integration beginning with the fact that continuous integration allows the team to receive an early warning when code is flawed or broken. When this happens, the team is able to fix integration problems as they individually occur, rather than having to deal with all of them at once. It also provides the team with immediate feedback about the built features, since these requirements are much more frequently tested and—should a mistake be made—the code can quickly be reverted back to previous iterations. This prevents mistakes from compounding and makes them easier to find.

The business also benefits from continuous integration because it reduces system setup time, allows the development team to use their development hardware as a build server, and reduces the time needed to create automated testing.

Risk-Based Spike

Sometimes an Agile project team faces a User Story feature or requirement that necessitates a technology or an implementation that the team has never seen before. In these situations, the team needs a way to experiment and determine the best solution. Remember that in Agile Development the team is working in fixed length iterations with a requirement to deliver fully-tested features in every iteration. Delivering production ready features when the team needs to experiment usually puts undue pressure on the team that is impractical. A better solution is the Risk-Based or Research Spike. A spike is a short iteration or sprint undertaken by the team to investigate a specific issue. The spike can result in an answer or solution, a recommendation or a decision. The concept of a spike works because it follows the Agile concept of failing fast.

Test Driven Development

Test Driven Development is one of the most important concepts within Agile Development. It represents a dramatic departure from the test scheme used in linear development. In linear development, the test process is conducted by a group of people outside the development team, typically called the Quality Assurance Group. They are often the most frustrated people involved in the project. They are frustrated because they often only receive the code at the last possible moment when there is little or no time left in the schedule. When this happens, testing suffers and the customer ends up getting a finished product with multiple errors and missing requirements. This happens because the testers are compressed into the last phase of the project and are asked to design and complete



Page 316

Slide 322

Slide 323

unit and integration tests together in little time. In Test Driven Development, the Development Team is responsible for the testing—but this is not the biggest difference. There are two additional differences that are significant. The first distinction with Test Driven Development is that in TDD the tests are written BEFORE any code is ever written. Then code is written to pass the specific test. The second major difference is that the tests are conducted in every iteration and not just at the end of the project. Every iteration is required to deliver fully tested features. In TDD the focus is on Unit Tests, which are tests of small, functional pieces of code. These tests are commonly automated.

Unit tests are the focus for a number of reasons. One reason is that such tests make it easier for the team to find software bugs. By focusing the tests on the individual code components the team is able to see smaller units of functionality and therefore smaller errors. Unit Tests also make it easier to maintain the overall code base. The team gains the ability to more easily have full code coverage. It is easier to design and develop the code, to deliver early and often, and it is much, much easier to track team member performance. Many developers and project managers struggle with TDD because it seems completely opposite to everything they have ever experienced. The notion of building tests before writing any code and only then writing the code that passes the specific tests seems to open the door for tons of missed requirements. However, in practical application the opposite is true. TDD allows the team to develop simple solutions to meet customer needs, and to only add complexity when the project requirements demand greater complexity. The phrase that Agilists use to describe this aspect of TDD is Red, Green, Refactor.

Red, Green, Refactor describes the basic process developers go through when using TDD. The first step is the developer writes a test that if met proves a feature meets a specific requirement. Once the test is written, the developer runs the test and it must fail. The test must fail because no code is yet written to meet the specific requirements. This is the Red stage. Once the test has failed, the developer writes the specific code that will pass the test. The developer runs the test again and continues to write code and run the test until the test passes. Getting to the point where the test passes is the Green stage. Finally, all the developers on the team work to Refactor the code. This is the process of finding ways to improve code that already works. We will talk more about refactoring shortly.

Central to making TDD successful is this idea of making the test fail BEFORE any code is written—to prove the code is actually what causes the test to be passed. This concept is a fundamental difference between TDD and traditional



Page 317

Slides 324-325

development. The other major difference between TDD and traditional development is the idea that the developer only writes enough code sufficient to pass the current test. Code is addressed one single test at a time with TDD.

As much as TDD can improve a team’s development efforts, it is not perfect and does not work for everything. Remember, TDD advocates automated unit tests. Areas such as security, multi-threading, user interface, or game development might require more substantial testing and development processes. Additionally, TDD’s unit tests do not replace other forms of testing.

There are a couple of common mistakes made by many people who are new to implementing Test Driven Development. First, in an effort to get the tests out of the way quickly, some developers try to write all their tests first. This typically causes several problems. Most project see a large number of feature changes as the project progresses. If the developer creates all their tests before writing code, there is often a large amount of time that is wasted when originally planned features are later dropped. Secondly, as developers go through the project’s iterations, they learn and improve all their processes—including how they execute tests. If the tests are written in the beginning, they cannot take advantage of this learning. Finally, writing all the tests first can result in developers writing code to pass more than one test at a time, which can create issues when debugging. The idea is to write only the test for the piece of code the developer is about to create. This allows the team to work in small incremental steps.

A second common mistake seen when organizations implement TDD is the tendency to have a separate Quality Assurance or QA group writing the unit tests. This is a result of a misguided need to make use of their skills. Remember, the developer is required to write the unit tests for the code they are about to write. When a separate QA department writes the unit tests, they slow down the process and create something other than TDD. The QA department needs to be delivering higher level tests than the developer using TDD.

If the organization is able to implement Test Driven Development properly, they likely will experience a number of advantages over traditional development frameworks. TDD allows the developer to better focus on the needs of the customer. This is because they must first fully understand the business need for the requirement before they can write the tests, and they can only write the code once they have completed the tests. TDD also provides the business with a foundational guarantee that at least some tests are in place and are used throughout the development process. Because these are unit tests, they often help the developer catch defects earlier in the process. This means the defects are less costly to repair. The TDD framework creates a highly modular process that is both flexible and extendable. In addition to the many advantages provided by TDD, there are a few disadvantages that go beyond the common errors made by those attempting to implement it.

As we have stressed, TDD pushes unit testing done by the developers (and views this as positive), but this does have drawbacks. First, some developers lack experience in testing, which causes them to struggle writing appropriate tests. Secondly, some functionality is simply difficult to test with unit tests. Higher



Page 318

levels of testing are simply required. There is absolutely nothing in TDD that prevents performing these higher level tests, but the required extra step sometimes gets missed. Furthermore, developers can become frustrated in TDD because they are required to maintain the tests. Lastly, many teams gain a false sense of success when they experience a high number of passed tested. It is key to remember that these are merely unit tests. The application still requires several additional layers of testing (for example, integration, acceptance and beta testing).

A concept that is closely related to Test Driven Development is Acceptance Test Driven Development or ATDD. Acceptance Test Driven Development moves the testing focus from the code to the business requirements. Just like TDD, ATDD requires that the tests be created before any code is written, and might use functional test frameworks such as FIT (Framework for Integrated Testing) or FitNesse. ATDD uses a four stage process:

Discuss the Requirements — During planning meeting, the developers must ask the customer for acceptance criteria.

Distill Tests in a Framework-Friendly Format — Once understood, the developers must organize the tests in a format that makes sense for the team and makes testing easy.

Develop the code and hook up the tests — The team then must write the code and attach it to the tests.

Demo Through Exploratory Testing — The process ends when the team demonstrates the completed functionality through exploratory testing in an attempt to learn more about the product and the needs of the organization.

Another closely related testing philosophy is Test First. In both these philosophies the testing is done at the unit level using automated tests written before any code has been written. Both philosophies also require the developer to conduct the testing at a functional level. The difference between the two philosophies is that in Test Driven Development, the code is refactored to improve its design (Red, Green, Refactor) whereas this step is skipped in the Test 1st model. Also, test 1st does not comment on any other activities in the development cycle. It is focused singularly on testing. The biggest difference between the two is the fact that in TDD, tests are used to drive the design and this does not happen in Test 1st.

Refactoring

For many Agile students, the single most difficult concept to grasp is refactoring. According to Martin Fowler and Kent Beck, who originally defined the term, refactoring refers to “a change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behavior... It is a disciplined way to clean up code that minimizes the chances of introducing bugs.” Scrum does not specifically demand that you refactor—just like it does not demand that you use Test Driven Development. However, most experienced practitioners of Scrum struggle to image doing Scrum without these two tools. Extreme Programming calls out both tools and asserts that no developer

Slide 326-329

Slide 330

Slide 331



Page 319

Slides 332-334

should ever be afraid of refactoring. Not only should you be unafraid to refractor, you should consider it part of your regular work. This is critical. Some inexperienced developers try to position refactoring as a separate task . This is an incorrect application of refactoring.

Refactoring is done to fill in short-cuts, eliminate duplication and dead code, and to make the design and logic clear. It is done to make better and clearer use of the programming language. to take advantage of information that you have now but that the programmer didn’t have then—or that they didn’t take advantage of then. Refactoring means to always simplify the code and make it easier to understand, and to always make it easier and safer to change in the future. The practice of refactoring is not as simple as it initially sounds. Fixing any bugs that you find along the way is not refactoring. Optimization is not refactoring. Tightening up error handling and adding defensive code is not refactoring. Making the code more testable is not refactoring—although this may happen as the result of refactoring. All of these are good things to do. But they aren’t refactoring. Programmers—especially programmers maintaining code—have always cleaned up code as part of their job. It’s natural and often necessary to get the job done. What Martin Fowler and others did was to formalize the practice of restructuring code and document a catalog of common and proven refactoring patterns by offering a number of goals and steps. Refactoring means protecting yourself from making mistakes by first writing tests where you can. Make structural changes to the code in small, independent and safe steps, and test the code after each of these steps to ensure that you haven’t changed the behavior, in order to be certain that it still works the same, it just looks different. Refactoring patterns and refactoring tools in modern IDEs make refactoring easy, safe and cheap.

Refactoring is supposed to be a practice that supports making changes to code. You refactor code before making changes so that you can confirm your understanding of the code and make it easier and safer to put your change in. Regression test your refactoring work. Then make your fix or changes. Test again. Afterwards, refactor more code to make the intent of the changes clearer. Test everything again. Refactor, then change. Or, change, then refactor. As the team progresses, they might use a number of different types of refactoring including the following:

Yuck — This refers to code that works but looks unsatisfactory. This is about making small improvements. You make changes because you find the code lacks elegance and requires rework to make it more appealing.

The Not Understood — This refers to code that you look at and cannot easily understand what it is doing. Sometimes a developer examines code written either by themselves or others and struggles to understand what it is doing. Agile development attempts to create self-documenting code that can be



Page 320

understood by any developer. When a developer looks at code that fails this basic test, it must be refactored.

New Insights — As the team works through the iterations of their project, they learn new information, and new requirements are added or are changed. This new information can impact the existing requirements or necessitate that the developer write new functionality.

Planned Refactoring — Planned refactoring occurs whenever the team adds refactoring to the project plan as a deliverable. Martin Fowler argues that this should hardly ever be done, because it represents a failure of the team to do their refactoring in small enough pieces to be part of the normal development process and be constant. As a general rule, planned refactoring requires justification, and it is considered to be evidence that the team is not doing enough of the other (correct) kids of refactoring.

Long Term Refactoring — This occurs when the team is trying to get closer to a large, long term goal. In order to achieve this objective they must get some vision of where they want the project to be in the future. To accomplish this, the team must use a gradual process—but it does not require significant planning since the very notion of refactoring is tied to working in small steps.

The Design Stamina Hypothesis

Many students of Agile Development see refactoring and contend that it represents hidden inefficiencies through rework. This is not the case according the originators of the concept. In response to this, they point to an idea that most software developers intrinsically believe in, called the Design Stamina Hypothesis. Rather than try to explain Fowler’s notion in my words, let’s examine what Fowler himself says about the topic on his website at http://martinfowler.com/bliki/DesignStaminaHypothesis.html.

From time to time I have indirect conversations about whether good software design is a worthwhile activity. I say these conversations are indirect because I don't think I've ever come across someone saying that software design is pointless. Usually it's expressed in a form like "we really need to move fast to make our target next year so we are reducing <some design activity>".

In there is a notion that design is something you can trade off for greater speed. Indeed, I've come across the impression a couple of times that design effort is tolerated to keep the programmers happy even though it reduces speed.

If it were the case that putting effort into design reduced the effectiveness of programming I would be against it. In fact I think most software developers would be against design if that were the case. Developers may disagree on what exactly is good design, but they are in favor of whatever brand of good design they favor because they believe it improves productivity. (And by "design" here I mean either up-front design or Agile's approach, i.e., planned or evolutionary design.)

Design activities certainly do take up time and effort, but they payoff because they make it easier to evolve the software into the future. You can save short-term time

Slide 335



Page 321

by neglecting design, but this accumulates Technical Debt, which will slow your productivity later. Putting effort into to the design of your software improves the stamina of your project, allowing you to go faster for longer.

One way of visualizing this is the following pseudo-graph.

The pseudo-graph plots delivered functionality (cumulative) versus time for two imaginary stereotypical projects: one with good design and one with no design. The project that does no design expends no effort on design activities, whether they be up front design or Agile techniques. Because there's no effort spent on these activities this project produces function faster initially.

The problem with no-design, is that by not putting effort into the design, the code base deteriorates and becomes harder to modify, which lowers the productivity, which is the gradient of the line. Good design keeps its productivity more constant so at some point (the design payoff line) it overtakes the cumulative functionality of the no-design project and will continue to do better.

I call this a hypothesis because it is a conjecture, there is no objective proof that this phenomenon actually occurs. In scientific terms it's not a very good hypothesis because it's hard to test. We cannot measure productivity nor can we measure design quality.

But despite it being only a hypothesis, it's also an axiom for many people, including myself. We may not have objective proof that this effect occurs but many of us feel that this explains what we see qualitatively in the field. It's an axiom for me as it's the assumption that underpins my entire career as a writer about software design. If design doesn't actually improve productivity in some way, most of my writings are worthless.

I'm sure it sounds strange to many people to treat a hypothesis as an axiom, but it's a common thing to do. I look at it that I use my judgment to assess that the



Page 322

hypothesis is true, but can do so without ignoring the objective weakness of the hypothesis. I'd love to find a way to prove it and almost as much to refute it.

The hypothesis has a corollary, which comes from the design payoff line. If the functionality for your initial release is below the design payoff line, then it may be worth trading off design quality for speed; but if it's above the line then the trade-off is illusory. When your delivery is above the design payoff line neglecting design always makes you ship later. In technical debt terms it's like taking out a loan but not using the principal for so long that by the time you use it you've paid out more in interest payments.

This raises the question of where that line is. Even with people who accept the design stamina hypothesis there are substantial, and important, differences over where the payoff line sits. I take the view that it's much lower than most people think: usually weeks not months. But again this can only be a judgment call.

This leads to a consequence for Technical Debt. Technical Debt is a fantastic analogy and I use it frequently. But the design payoff line reminds us that taking out a Technical Debt is only worth doing up to a certain point. Not just do we have to consider whether delivered value is greater than the interest payments, we also have to judge whether the delivery is above the payoff line in the first place. The key with Fowler’s hypothesis is to remember it is exactly that: a hypothesis. It is not based on any kind of scientific research or quantitative data.

As we conclude the discussion of refactoring one question has not been answered: Why refactor? If your answer is to improve code or application quality, produce cleaner code, increase professionalism, or its just the right thing to do, you are wrong. Refactoring is simple economics. Refactoring allows the Development Team to deliver more functionality more quickly. This is the only reason anyone should want to refactor.

Problem Solving

Since this domain is called Problem Detection and Resolution, a logical area of concern is solving project problems. Fortunately, Agile Development provides a relatively simple model to do this. It begins with a basic three step model that requires the Agilist to gather data and then generate insights before deciding what to do. Do not think that this is all there is to the model, however. Agile expands on each of these notions with a series of definitions, processes, and tools.

The first step of the process is to gather data. As you can probably imagine, there are a lot of different ways to gather data about the issues faced by a project. Some examples include the following:

Timeline — This is a simple tool where the team is asked to think about the project from a time-based perspective: First, this happens then this, then this. The linear nature of the timeline allows team members to capture information that might otherwise be missed.

Triple Nickels — This tool is used to help decide how to phase in an iteration, release, or project retrospective. The team begins by forming small groups. In

Slide 336

Slide 337-339



Page 323

the groups, each person has five minutes to brainstorm and write down ideas individually. At the end of five minutes, each person passes the paper to the person on his or her right. That person has five minutes to write down ideas that build on the ideas already written on the paper. The process is repeated until the paper returns to the original writer. Each person then reads the ideas listed on the paper. Then the group debriefs the using the following questions:

What did you notice while you wrote ideas? What surprised you? What met your expectations? How? What is missing from these lists? What ideas and topics should we examine further?

Color Code Dots — This technique helps a group discover how people experienced events on the timeline where emotions ran the gamut from high to low. First, all the events are placed on a timeline and the team does a quick review of what happened. Then individuals use colored dots to show where their personal energy was high or low. If you facilitate such a meeting, it is best to begin the activity by saying, “Now that we’ve seen the facts, let’s see how it was to be doing this work.” Provide each individual with dots in two colors. Start with seven to ten dots per person, but have more available. Explain which color indicates high energy and which indicates low energy. Ask each person to use the dots to show where their energy was high and where their energy was stalled, flagging, or low. After everyone places their dots on the timeline, review the results and discuss possible improvements.

Mad, Sad, Glad — In this process, the participants each separately write notes on observations they have made regarding the previous sprint. These notes should be brief and should be written on small index cards. Examples might be “Renderer optimization completed ahead of schedule,” or “JIRA task descriptions are not very clear.” The notes can be on good or bad observations. They can reflect changes in this sprint in particular or in a persistent issue. Importantly, they should not be limited to only actions of the team members. For example, an observation might be “Still waiting for IT to grant access to the shared folder.” This activity is timeboxed to 10 or 15 minutes. The next step is that participants each describe their cards and place each card on the whiteboard. The description of each card should be very brief and should contain only enough so that the team members understand the meaning of the card. Furthermore, the team members must not interrupt each other, except to ask for further clarification (i.e. there should be no acceptance or rejection of ideas at this stage). Next, the whiteboard is divided into 3 columns titled Glad, Sad and Mad (alternatively, smiley faces can be used). Each note must then be placed into one of the columns based on how that observation makes the person feel. Obviously Sad and Mad both cover negative issues. The distinction is useful because the Mad column encourages team members to think of issues that may be external to the team, but which nonetheless impacted the sprint. Even an issue as apparently off-topic as difficulty finding a parking space in the morning could be something that affects many team members and could potentially be actioned. Placing cards on the board should be timeboxed to 10 or 15 minutes. The cards are then



Page 324

grouped and issues which essentially refer to the same thing are moved physically together. A single person must take responsibility for performing this grouping and this should take less than 5 minutes. The next step is that all the participants should vote on which (grouped) issues to discuss further. The quickest way to perform this vote is that each person marks the cards that they wish to discuss (for example, with a circle) and every person can only mark a limited number of cards. A typical limit is 5 cards. This voting can be performed in parallel, so less than 10 minutes should be adequate for this stage. Finally, the “chair” of the retrospective (often the Scrum master), leads a discussion on the issues in descending order of the number of votes. At this point participants can agree or disagree with the observation—but the discussion should be primarily focused on actions that can be performed in the next sprint. Even in the case of Glad issues there may be actions that can build on that success. The discussion ends when the 1 hour is up, or when all the issues have been discussed (whichever happens first).

Locate Strengths — The goal of this exercise is to identify strengths so that the team can build on them in the next iteration. It also provides a much needed balance when an iteration, release, or project hasn’t gone as expected. Team members interview each other about high points on the project. The goal is to understand the sources and circumstances that created those high points. Once the exercise is complete, review the results to discover themes.

Satisfaction Histograms — This exercise is used to highlight how satisfied team members are with a focus area. It provides a visual picture of the current status in a particular area in order to help the team have deeper discussions and analysis. It also acknowledges the differences in perspectives that exists among team members. Introduce the activity by saying “Today we’ll create a baseline measure of our level of satisfaction with the way we work together. We can repeat this activity in future iteration retrospectives to track our progress.” Then show the flip charts to the team, read the definitions, and hand each team member an index card with the following instructions written on it: “Please write a number on your card that tells your level of satisfaction on the team right now. Then fold the card and put it in a pile.” Once all the cards are turned in, stir the pile of cards and ask for a volunteer to color in the graph as you read them. Read the number on each card. Wait for the tally before going on to the next. Finally, read the results from the graph and ask for comments.

Team Radar — This activity is designed to help the team gauge how well they are doing on a variety of measures, such as, engineering practices, team values, or other processes. The process for the Team Radar begins when the facilitator introduces the activity by saying, “We agreed on these [fill in the factors] as important to our work. Let’s assess how well we are doing, using a scale of 0--10. Zero means not at all, and 10 means as much as possible.” Post the flip chart with the blank radar graph. Ask each team member to approach the chart and place a dot to show their rating for each factor. Next, lead a short discussion about how the factors affect the work of the team. Consider asking questions such as the following: Where do you see us following these? Where



Page 325

do you not see us following these [fill in the factors]? Use the short discussion as a segue to generating insights. Save the completed flip chart graph. Run the activity again two or three iterations later. Compare the two charts as a progress measure.

Like to Like — The Like to Like exercise is designed to help team members recall their experiences during the iteration (release or project) and to hear that others may have perceived it differently. In this exercise, team members take turns judging which events or factors about their iteration are the best fits for Quality Cards. As the cards are evaluated, team members learn about each other’s perspectives on the same events or conditions. The exercise begins by asking each team member to write on at least nine index cards. Three or more cards should include things to stop doing, three or more cards should include things to keep doing, and three or more cards should indicate things to start doing. While team members are writing, shuffle the deck of colored Quality Cards and lay the pile face down on a table. When the game cards are ready, invite the team to stand around the table. Choose one person to start as Judge. The Judge turns over a Quality Card from the pile and puts it face up on the table. All other team members look in their game cards for the one that most closely matches the Quality Card and then place their matching cards face down. The last card down is disqualified and returns to its owner’s hand. This keeps the game moving. The Judge stirs the players’ cards, turns them over one at a time, and reads them. He or she chooses the card that makes the best match with the Quality Card. The author of that card wins the Quality Card. The role of Judge passes left to the next person, and another Quality Card is turned over. After six to nine rounds (or whenever everyone runs out of cards), the game ends. The person with the most Quality Cards wins. Debrief the activity with the four-step method.

The second step in the problem solving process is to generate insights. Again, there are a number of tools that may be used. The simplest of these is old-fashioned brainstorming. Get the entire group together and have an open dialogue about what went right and wrong. As the discussion progresses, make sure to document the ideas expressed.

Another common tool use to generate insights is Five Whys. It involves asking the question why at least five times in order to discover the root cause of problems. It was originally developed by Sakicki Toyoda and typically makes use of one of two techniques.

Fishbone Diagrams — The team identifies factors that are causing or affecting a problem situation, and then looks for the most likely causes. After they’ve identified the most likely causes, they look for ways they can make changes or influence those factors. To create the diagram the facilitator draws a fishbone diagram and writes the problem or issue at the fish’s head. Include the five W’s—What, Who, When, Where, and Why. Label the “bones” of the fish with categories. The team then goes through each branch and brainstorms about the category, being careful to constantly ask “Why is this happening?” Stop when the group is branching out into areas outside their control. The



Page 326

team should also not be afraid to add more branches as necessary. This technique is often called a Cause and Effect Diagram, or an Ishikawa Diagram.

Tabular Format — The second technique is called the Tabular Format and works much the same way as the Fishbone Diagram, but is executed using a spreadsheet program such as Excel.

Other techniques the team might use to generate insights include prioritizing with dots or simply taking the time to identify themes.

Once the team is done generating their insights, it is time to move to the last step and decide what to do. This step is about picking an action that the team will execute. There are a number of potential tools that teams may use to determine what to do. Some examples include the following:

Short Subjects — The team brainstorms lists of ideas for actions that are based on titles that have been put on different flip charts. The titles are things like the following: What Worked Well/ Do Differently Next Time or WWWDD, Keep/Drop/Add, Stop Doing/Start Doing/Keep Doing, Smiley/Frowny, or Plus/Delta.

Slide 340

Slide 343



Page 327

Slide 344-346 SMART Goals — SMART stands for Specific, Measurable, Attainable, Relevant, and timely. When goals have these characteristics they are more likely to be achieved. The first step in this process is to introduce the activity by leading a short discussion on the importance SMART goals. Point out that goals that aren’t specific, measurable, relevant, and timely tend to fizzle. Point to the SMART characteristics written on a white board or flip chart. Offer an example of a SMART goal: “Our goal is to pair program at least 5 hours a day starting next Monday. We’ll rotate pairs daily. We’ll create a chart with the pairing schedule, and review it at our next retrospective.” Contrast this goal with a non-SMART goal: “We should pair more.” Notice here that it is helpful to choose an example that isn’t related to the experiments or improvements the team is working on. Form groups around each of the items that the team prioritized to work on. Ask each group to develop a SMART goal for the initiative, and identify 1--5 action steps to accomplish the goal. Monitor the activity. Ask each group to report their goal and plan. After each report have the group confirm whether or not the goals are, in fact, SMART. Invite the group to offer refinements.

Retrospective Planning Game — Team members work individually or in pairs to brainstorm all the tasks that are necessary to complete an experiment, improvement, or recommendation. After brainstorming, team members eliminate redundant tasks and fill in the gaps. The tasks are arranged in order and the team members each sign up for tasks they will complete. Introduce the activity by saying, “We’re going to work on generating all the tasks needed to have our experiment succeed.” Then recap the experiment noting possible improvements or recommendations. Here are the steps:

Form pairs unless there are fewer than eight people, in which case do this individually. Hand out sticky notes or index cards and markers. Ask the group to write one task per card and to leave the bottom half blank. Show them an example.

Form pairs of pairs (or pairs if the previous step was done individually). Have the groups compare tasks, eliminate duplicates and write any new tasks they realize are missing. It’s okay to re-write or consolidate as needed. If the group is larger than 16, have the groups of four form groups of eight and do another round of comparing, adding, and eliminating duplicates before proceeding to the next step.

Invite the group to post and cluster the tasks on a whiteboard or wall. If they’ve used cards, they can cluster them using a table. Once again, compare, look for duplicates, and add any new tasks that the team realizes are missing. Leave room on the left side of the wall or whiteboard. The team will use this in the next step when they order the tasks.

Order the cards. Start by asking: “Which task must be done first?” Move that task to the extreme left of the working surface. Then ask, “Are there any tasks that can be done simultaneously with this task?” Place those above or below the first task. Ask which task needs to be



Page 328

done next. Place that to the right of the first task.

Invite team members to sign up for tasks by writing their names on the bottom half of the task cards. Or, if it’s more appropriate, bring the tasks into the next iteration planning meeting.

Circle of Questions — This activity requires team members to engage in a question asking and answering process to find consensus. Invite team members to sit in a circle. Introduce the activity by saying, “Sometimes the best way to find answers is to ask questions. We’ll ask questions to find what we want to do as a result of what we’ve learned in this retrospective. We’ll go around the circle until we are satisfied with our answers or until at least [timebox] minutes have passed.” Turn to the person on your left and ask a question. You might start with the following: “From your perspective, what is the highest priority for us to try in the next iteration?” The team member should answer this question from his or her perspective to the best of his or her knowledge and ability. Then that team member becomes the questioner, turning to the person on his or her left to ask a question that extends the previous discussion or starts a new one. The new respondent answers and then asks the question, and so on around the circle until the group is satisfied that their questions have been heard and considered, and a consensus for the action has emerged.

There are a number of other ideas as well, but they all focus on getting the team to share ideas and find commonality.

Before moving to the last chapter, complete the exam that follows. Make sure to score at least 90%.



Page 329

Exercise 11— Problem Detection &

Resolution

Problem Detection & Resolution Exercise 1. According to PMI®, a problem occurs whenever:

A. Something costs significantly more than planned. B. Something doesn't go as planned. C. Something takes significantly longer than planned. D. Something causes a significant project risk to occur.

2. Which of the following is NOT a core task found in the problem detection and resolution area?

A. Create an open and safe environment by encouraging conversation and experimentation, in order to surface problems and impediments that are slowing the team down or preventing its ability to deliver value.

B. Identify threats and issues by educating and engaging the team at various points in the project in order to resolve them at the appropriate time and improve processes that caused issues.

C. Maintain a visible, monitored, and prioritized list of threats and issues in order to elevate accountability, encourage action, and track ownership and resolution status.

D. Communicating project status and results by maintaining a risk register that is regularly reviewed by the team.

3. The simplest definition of cycle time is:

A. The amount of time it takes to get things done. B. The amount of time it takes the team to execute an iteration. C. The amount of time it takes for a process to complete. D. The amount of time it takes to deliver the project.

4. Which of the following does agile constantly work to reduce?

A. Throughput B. Cycle time C. Effort D. Costs

5. The relationship between cycle time, work in progress, and throughput is described by which of the following formulas?

A. Cycle Time = WIP / Throughput B. WIP = Cycle Time / Throughput C. Throughput = WIP / Cycle Time D. Cycle Time = WIP * Throughput

6. As a project progresses what happens to the value of potential changes?

A. The value of any change increases and the costs rise. B. The value of any change decreases and the costs also decrease. C. The value of any change increases as the costs decrease. D. The value of any change decreases as the costs rise.

7. When working an agile project, which of the following represents previously unknown requirements or features that may be added to the product backlog?

A. Risks B. Changes C. Defects D. Test cases



Page 330

8. Defects that the Daily Stand Up misses are called:

A. Missed defects B. Extended features C. Escaped defects D. Backlog adds

9. Why are escaped defects the most expensive kind of defects to fix?

A. Escaped defects represent new functionality. B. Escaped defects require the team to repair functionality they thought was already

completed. C. Escaped defects require the team to repair functionality already put into production. D. Escaped defects represent functionality already evaluated and rejected by the

customer, but now requiring completion.

10. Which of the following is NOT a common metric used to promote the desired behavior to ensure expected deliver?

A. Tracking tests passed and customer acceptance. B. Automating tests C. Conformance test counts D. Constant testing

11. The concepts of agile development requires the team to "fail fast." Which of the following statements about this concept is NOT true?

A. Failing fast is a conservative approach. B. Failing fast allows the team to gain valuable knowledge through experience. C. Failing fast is a research-based approach. D. Failing fast requires the entire organization to accept mistakes.

12. Which of the following is NOT an assertion made by Alistair Cockburn about how teams become great?

A. Great teams are good at looking around and seeing what others are doing. B. Great team able learn from others and from their environment. C. Great teams are capable of changing and adapting to their environment and the needs

of the organization. D. Great teams are always disciplined and refuse to ever fail.

13. Over the last two and a half months your team has measured the number of defects produced by a process. In each instance, the number of defects has been fewer than the process mean. Which of the following statements concerning your control chart is true?

A. You are now below the lower control limit. B. The control chart mean has shifted. C. You are now above the upper control limit. D. The process is in control.

14. You are part of a team leading a $5 million USD information technology project. In the last three months each of the team's daily reports has shown its defect count was below the upper control limit and above the lower control limit. Which of the following statements about your project is true?

A. The project is in control. B. The project is at risk due to a high defect rate. C. The project defect rate is still too high. D. The project is being managed using principles found in manufacturing and not agile

development.



Page 331

15. Which of the following is NOT a common tool used by agile teams to continuously integrate?

A. Source code control systems B. Build tools C. Risk-based spikes D. Test tools

16. When an agile team must develop a user story that requires a technology or implementation the team has never seen before which of the following is the best thing to do?

A. Iteration zero B. A risk-based spike C. Continue the iteration as planned. D. Continue the iteration, but limit the number of stories.

17. In Test Driven Development who is responsible for testing?

A. The product owner B. The scrum master C. The quality assurance team D. The development team

18. In Test Driven Development when are the tests written?

A. Before any code is written. B. Before any user stories are written. C. Immediately after the user stories are written. D. Immediately after the code is written.

19. Which of the following describes the process of Test Driven Development?

A. Green, Yellow, Red B. Refactor, Red, Green C. Red, Yellow, Green D. Red, Green, Refactor

20. In which of the TDD basic process steps does the code fail the test?

A. Red B. Yellow C. Green D. Refactor

21. Within TDD Which of the following ideas are critical to making the process work?

A. That the tests are approved by the product owner. B. Every developer reviews the tests. C. The test must be failed before the code is written. D. The code is improved through the process.

22. Your team is completing a software development project and the team is using TDD for all the testing. To improve the speed of the team, you right all of the tests up front. Which of the following is true?

A. Time will be wasted rewriting tests as requirements change. B. The team will likely fail to improve their process. C. The team will experience issues debugging the code. D. The team will write suboptimal code.



Page 332

23. Which of the following is NOT an advantage of test driven development?

A. TDD allows the developer to better focus on the needs of the customer. B. TDD also provides the business with a foundational guarantee that at least some tests

are in place. C. TDD ensures the proper focus on customer quality and timely delivery. D. The TDD framework creates a highly modular process that is both flexible and

extendable.

24. Which of the following is a common risk seen with Test Driven Development?

A. The team develops code in isolation. B. Some functionality is difficult to test with unit tests. C. The quality assurance department is made to feel out of place. D. Required higher level tests are prevented.

25. Which of the following is NOT a common risk from Test Driven Development?

A. Customers become confused by the TDD testing protocols. B. Some developers lack experience in testing which causes them to struggle writing

appropriate tests. C. Developers sometimes become frustrated in TDD as they are required to maintain the

tests. D. Many teams gain a false sense of success when they experience a high number of

passed tested.

26. Which of the following is NOT a stage found in the Acceptance Test Driven Development?

A. Define the requirements. B. Distill tests in a framework friendly format. C. Develop the code and hook the tests. D. Demo through exploratory testing.

27. Which of the following is a commonality between TDD and Test First?

A. Both models focus on unit testing. B. Both models refactor code to improve design. C. Both models comment on other activities in the development cycle. D. Both models use testing to drive the design.

28. Which of the following statements concerning refactoring is true?

A. Refactoring is a change made to the structure of software to make it easier to understand & cheaper to modify by changing its behavior.

B. Refactoring is a disciplined way to clean up code that minimizes the chances of introducing bugs.

C. When done correctly, Scrum requires the team refactor their code. D. Typically, refactoring is not considered part of a developer's regular work.

29. As a developer, you look at your code and find that although it passes the unit tests it is inefficient and un-elegant. In this situation what kind of refactoring is required?

A. Yuck B. The not understood C. Planned Refactoring D. Long term refactoring



Page 333

30. What kind of refactoring is your team using when refactoring is added to the project as a specific deliverable?

A. Yuck B. The not understood C. Planned refactoring D. Long term refactoring

31. According to Martin Fowler, "The problem with no-design, is that by not putting effort into the design, the code base deteriorates and becomes harder to modify, which lowers the productivity, which is the gradient of the line. Good design keeps its productivity more constant so at some point (the design payoff line) it overtakes the cumulative functionality of the no-design project and will continue to do better." This idea is called what?

A. The Fowler Design Hypothesis B. The Design Stamina Hypothesis C. The Agile Design Corollary D. The Fowler Corollary

32. What group data gathering technique is the team using if the facilitator asks the team to think about the project from a time-based perspective?

A. Triple nickels B. Color code dots C. Timeline D. Mad sad glad

33. What group data gathering technique is the team using if is debriefed using the question, "what did you notice while you wrote ideas?"


34. Your team decides it needs to quickly discover what opinions are held by people on a project where emotions run the gambit from high to low. Which of the following is most likely to be effective?


35. Your team is in its Sprint Retrospective. It has been decided that the team needs to set a baseline for how happy everyone else with the team. Which of the following tools would be most effective in this situation?

A. Mad, Sad, Glad B. Locate strengths C. Satisfaction histograms D. Team Radar

36. If the team needs to determine how well they are doing on a variety of measures which of the following tools is best?

A. Mad, Sad, Glad B. Locate strengths C. Satisfaction histograms D. Team Radar



Page 334

37. The team needs a tool during their retrospective to help them recall their experiences during the iteration and hear how other team members experienced the iteration. Which of the following tools is best for this task?

A. Team radar B. Like to like C. Satisfaction histograms D. Locate strengths

38. Which of the following is NOT a tool your team might use to decide what to do once it has generated insights?

A. Short subjects B. SMART goals C. Circle of questions D. Corona of possibilities

39. Which of the following is NOT a step found in the Retrospective Planning Game?

A. Work individually or in pairs to generate all the tasks. B. Form pairs C. Cluster the pairs D. Form pairs of pairs



Page 335

Problem Detection & Resolution Exercise Answers 1. Answer B. LGd course manual p. 309 - PMI® refers to situations where things do not go as

planned as “problems” and outlines two core aspects of the domain, problem detection and resolution. The first part is all about determining that a problem exists and the second is concerned with fixing the issues discovered.

2. Answer D. LGd course manual p. 309 - The five tasks found in the problem detection and resolution area include: Create an open and safe environment by encouraging conversation and experimentation, in order to surface problems and impediments that are slowing the team down or preventing its ability to deliver value. Identify threats and issues by educating and engaging the team at various points in the project in order to resolve them at the appropriate time and improve processes that caused issues. Ensure issues are resolved by appropriate team members and/or reset expectations in light of issues that cannot be resolved in order to maximize the value delivered. Maintain a visible, monitored, and prioritized list of threats and issues in order to elevate accountability, encourage action, and track ownership and resolution status. Communicate status of threats and issues by maintaining threat list and incorporating activities into backlog of work in order to provide transparency.

3. Answer A. LGd course manual p. 309 - Cycle Time represents the amount of time it takes to get things done. The concepts and uses surrounding Cycle Time are closely related to Work in Progress or WIP.

4. Answer B. LGd course manual p. 310 - Agile Development works to constantly reduce both WIP and Cycle Times. It attempts to have less going on at a single moment and to get those items done as quickly as possible.

5. Answer A. LGd course manual p. 310 - Agile Development works to constantly reduce both WIP and Cycle Times. It attempts to have less going on at a single moment and to get those items done as quickly as possible. The relationship between Cycle Times, WIP, and Throughput is defined by the formula: Cycle Time = WIP / Throughput.

6. Answer D. LGd course manual p. 310 - A core axiom for this area is that as time progresses on a project the value of any change reduces. At the same time the cost to make the change rises. At some point the value of making the change becomes less than the cost to make it and the change should not be made. The reason for this rule is that the longer a project goes, the more investment of time, money, and resources has occurred.

7. Answer B. LGd course manual p. 310 - Leaders must also ensure they understand the difference between changes and defects. Both cause the team to adjust often requiring additional time and money. Changes are previously unknown requirements or features that may cause changes to the project requirements.

8. Answer C. LGd course manual p. 310 - The Daily Stand Up is used to identify most defects. However, the Daily Stand Up is not perfect. Defects that the Daily Stand Up misses are called Escaped Defects. Escaped Defects represent the most expensive kind of defects to fix. They require the team to repair functionality they believe was already completed.

9. Answer C. LGd course manual p. 310 - The Daily Stand Up is used to identify most defects. However, the Daily Stand Up is not perfect. Defects that the Daily Stand Up misses are called Escaped Defects. Escaped Defects represent the most expensive kind of defects to fix. They require the team to repair functionality they believe was already completed.



Page 336

10. Answer C. LGd course manual p. 311 - Fitness for Purpose defines whether or not the product will meet the intended business need. This concept ties back to the Agile concept of the Definition of Done, Sprint and Release Goals. Each of these requires the team to think about what they will do to ensure the quality and value of the product meets the business’ needs. Establishing metrics to ensure expected delivery is critical, and there are a number of metrics often used to promote the desired team behavior. These include: Tracking tests passed and customer acceptance. Automating tests. Constant testing. Ensure the testers and developers communicate and collaborate constantly.

11. Answer C. LGd course manual p. 311 - A common phrase in Agile is, “Fail fast.” This phrase focuses the team on delivering something as fast as possible to the customer. The team can then obtain feedback on what they did correctly and incorrectly. Then, they can make adjustments. This basic process requires the entire organization be willing to accept mistakes. However, this does not mean a willingness to accept every kind of mistake. The concepts surrounding Agile Development contend that by making early mistakes often the errors will be much smaller, and smaller mistakes are easier and cheaper to fix. This is a preference towards failing conservatively allowing the team to invent and gain valuable knowledge through experience rather than simply researching.

12. Answer D. LGd course manual p. 311 - Alistair Cockburn asserts great teams get that way because they are good at looking around and seeing what others are doing. They understand that projects do not exist in isolation so they must be able learn from others and from their environment. They also cannot be set in their ways. A great team is one that is capable of changing and adapting to their environment and the needs of the organization. Teams that meet these standards are able to take pride in their work and achieve fantastic results.

13. Answer B. LGd course manual p. 312 - Although several of the options might be true, the only one you can say for sure is true is that the mean of the control chart has shift due to the Rule of Sevens that states whenever you have seven consecutive cases either above or below the mean the mean has shifted.

14. Answer A. LGd course manual p. 312 - When cases appear above the lower control limit and below the upper control limit we say the process is "in control."

15. Answer C. LGd course manual p. 314 - Risk-based spikes are critical to agile development, but they are NOT key to continuous integration.

16. Answer B. LGd course manual p. 314 - Sometimes an Agile project team faces a User Story, feature or requirement that requires a technology or implementation the team has never seen before. In these situations the team needs a way to experiment or determine the best solution. Remember, in Agile Development the team is working in fixed length iterations with a requirement to deliver fully tested features in every iteration. Delivering production ready features at the same time the team needs to experiment usually puts undue pressure on the team that is impractical. A better solution is the Risk-Based or Research Spike. A spike is a short iteration or sprint undertaken by the team to investigate a specific issue. The spike can result in an answer or solution, recommendation or decision. The concept of a spike works because it follows the Agile concept of failing fast.

17. Answer D. LGd course manual p. 314 - In Test Driven Development the Development Team is responsible for the testing, but this is not the biggest difference. There are two additional differences that are significant. The first distinction with Test Driven Development is that in TDD the tests are written BEFORE any code is ever written. Then code is written to pass the specific test. The second major different is that the tests are conducted in every iteration and not just at the end of the project. Every iteration is required to deliver fully tested features.



Page 337

18. Answer A. LGd course manual p. 314 - In Test Driven Development the Development Team is responsible for the testing, but this is not the biggest difference. There are two additional differences that are significant. The first distinction with Test Driven Development is that in TDD the tests are written BEFORE any code is ever written. Then code is written to pass the specific test. The second major different is that the tests are conducted in every iteration and not just at the end of the project. Every iteration is required to deliver fully tested features.

19. Answer D. LGd course manual p. 315 - Red, Green, Refactor describes the basic process developers go through when using TDD. The first step is the developer writes a test that if met proves a feature meets a specific requirement. Once the test is written, the developer runs the test and it must fail. The test must fail because no code is yet written to meet the specific requirement(s). This is the Red stage. Once the test has been failed, the developer writes the specific code that will pass the test. The developer runs the test again and continues to write code and run the test until the test passes. Getting to the point where the test passes is the green stage. Finally, all the developers on the team work to refactor the code. This is the process of finding ways to improve code that already works.

20. Answer A. LGd course manual p. 315 - Red, Green, Refactor describes the basic process developers go through when using TDD. The first step is the developer writes a test that if met proves a feature meets a specific requirement. Once the test is written, the developer runs the test and it must fail. The test must fail because no code is yet written to meet the specific requirement(s). This is the Red stage. Once the test has been failed, the developer writes the specific code that will pass the test. The developer runs the test again and continues to write code and run the test until the test passes. Getting to the point where the test passes is the green stage. Finally, all the developers on the team work to refactor the code. This is the process of finding ways to improve code that already works.

21. Answer C. LGd course manual p. 315 - Red, Green, Refactor describes the basic process developers go through when using TDD. The first step is the developer writes a test that if met proves a feature meets a specific requirement. Once the test is written, the developer runs the test and it must fail. The test must fail because no code is yet written to meet the specific requirement(s). This is the Red stage. Once the test has been failed, the developer writes the specific code that will pass the test. The developer runs the test again and continues to write code and run the test until the test passes. Getting to the point where the test passes is the green stage. Finally, all the developers on the team work to refactor the code. This is the process of finding ways to improve code that already works.

22. Answer D. LGd course manual p. 316 - There are a couple of common mistakes made by many new to implementing Test Driven Development. First, In an effort to get the tests out of the way more quickly, some developers try to write all their tests first. This typically causes several problems. Most project see a large number of feature changes as the project progresses. If the developer creates all their tests before writing code there is often a large amount of time that is wasted from planned features that are dropped. Secondly, as developers go through the project’s iterations they learn and improve all their processes including how they execute tests. If the tests are written in the beginning they cannot take advantage of this learning. Finally, writing all the tests first allows developers to write code to pass more than one test at a time which can create issues when debugging.

23. Answer C. LGd course manual p. 316 - If the organization is able to implement Test Driven Development they likely will experience a number of advantages over traditional development frameworks. TDD allows the developer to better focus on the needs of the customer as they must first fully understand the business need for the requirement before they can write the tests, and they can only write the code once they have completed the tests. TDD also provides the business with a foundational guarantee that at least some tests are in place and used throughout the development process. Because these are unit tests, the often help the developer catch defects earlier in the process which makes them less costly to repair. The TDD framework creates a highly modular process that is both flexible and extendable. In addition to the many advantages provided by TDD, there are a few disadvantages that go beyond the common errors made by those attempting to implement it.



Page 338

24. Answer B. LGd course manual p. 316 - As much as TDD pushes unit testing done by the developers and this is seen as a positive, it can also be seen as a negative. Requiring developers to do their own testing adds pressure and can be a negative as well. This occurs because for two reasons. First, some developers lack experience in testing which causes them to struggle writing appropriate tests. Secondly, some functionality is simply difficult to test with unit tests and higher levels of testing is required. There is absolutely nothing in TDD that prevents these higher level tests, but the required extra step sometimes gets missed. Developers sometimes become frustrated in TDD as they are required to maintain the tests.

25. Answer A. LGd course manual p. 316 - As much as TDD pushes unit testing done by the developers and this is seen as a positive, it can also be seen as a negative. Requiring developers to do their own testing adds pressure and can be a negative as well. This occurs because for two reasons. First, some developers lack experience in testing which causes them to struggle writing appropriate tests. Secondly, some functionality is simply difficult to test with unit tests and higher levels of testing is required. There is absolutely nothing in TDD that prevents these higher level tests, but the required extra step sometimes gets missed. Developers sometimes become frustrated in TDD as they are required to maintain the tests.

26. Answer A. LGd course manual p. 317 - ATDD uses a four stage process: Discuss the Requirements — During planning meeting the developers must ask the customer for acceptance criteria. Distill Tests in a Framework-Friendly Format — Once understood, the developers must organize the tests in a format that makes sense for the team. To make sense, it must also be organized in a way that makes testing easier for the team. Develop the code and hook up the tests — The team then must write the code and attach it to the tests. Demo Through Exploratory Testing — The process ends as the team continuously demonstrates the completed functionality through exploratory testing in an attempt to learn more about the product and the needs of the organization.

27. Answer A. LGd course manual p. 317 - In both TDD and Test First the testing is done at the unit level using automated tests written before any code. Additionally, both require the developer to conduct the testing at a functional level. However, there are some differences. In Test Driven Development, the code is refactored to improve its design (Red, Green, Refactor). This step is skipped in the Test 1st model. Test 1st also does not comment on any other activities in the development cycle. It is focused singularly on testing. The biggest difference between the two is the fact that in TDD, tests are used to drive the design and this does not happen in Test 1st.

28. Answer B. LGd course manual p. 317 - Refactoring represents, “a change make to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behavior… It is a disciplined way to clean up code that minimizes the chances of introducing bugs” according to Martin Fowler and Kent Beck who originally defined the term. Scrum does not specifically demand that you refactor just like it does not demand you use Test Driven Development.

29. Answer A. LGd course manual p. 318 - There are a number of types of refactoring that include: yuck; the not understood; new insights; planned refactoring; long-term refactoring. Of these Yuck represents refactoring where you look at code and it works, but find it unsatisfactory. This is about making small improvements. You make changes because you find the code lacks elegance and requires rework to make it more appealing.

30. Answer C. LGd course manual p. 319 - There are a number of types of refactoring that include: yuck; the not understood; new insights; planned refactoring; long-term refactoring. Planned refactoring occurs whenever the team adds refactoring to the project plan as a deliverable. Martin Fowler, who created the concept of refactoring, says it should hardly ever be done because it represents a failure of the team to do their refactoring in small enough pieces to be part of the normal development process and be constant. As a general rule, planned refactoring requires justification, and is considered evidence that the team is not doing enough of the other (correct) kids of refactoring.



Page 339

31. Answer B. LGd course manual p. 319 - The Design Stamina Hypothesis states that the problem with no-design, is that by not putting effort into the design, the code base deteriorates and becomes harder to modify, which lowers the productivity, which is the gradient of the line. Good design keeps its productivity more constant so at some point (the design payoff line) it overtakes the cumulative functionality of the no-design project and will continue to do better.

32. Answer C. LGd course manual p. 321 - There are a lot of different ways to potentially gather data about the issues faced by a project. The timeline is a simple group tool where the team is asked to think about the project from a time-based perspective. First, this happens then this, then this. The linear nature of the timeline allows team members to capture information that might otherwise be missed.

33. Answer A. LGd course manual p. 321 - Triple nickels is used to gather data or decide what to do phase in an iteration, release, or project retrospective. The team begins by forming small groups. In the groups, each person has five minutes to brainstorm and write down ideas individually. At the end of five minutes, each person passes the paper to the person on his or her right. That person has five minutes to write down ideas that build on the ideas already written on the paper. Repeat until the paper returns to the original writer. Ask each person to read the ideas listed on the paper. Then debrief the group using these questions: What did you notice while you wrote ideas? What surprised you? What met your expectations? How? What is missing from these lists? What ideas and topics should we examine further?

34. Answer B. LGd course manual p. 322 - Color code dots allow the group to quickly discover opinions about how people experienced events on the timeline where emotions run the gambit from high to low using sticky dots. After all the events are on the timeline and the team has done a quick review, individuals use colored dots to show where their personal energy was high or low). Set up the activity by saying “Now that we’ve seen the facts, let’s see how it was to be doing this work.” Provide each individual with dots in two colors. Start with seven to ten dots per person but have more available. Explain which color indicates high energy and which indicates low energy. Ask each person to use the dots to show where energy was high and where energy was stalled, flagging, or at low ebb. After everyone has placed their dots review the results and discuss what it means for possible improvements.

35. Answer C. LGd course manual p. 323 - Satisfaction histograms represent exercises used to highlight how satisfied team members are with a focus area. It provides a visual picture of current status in a particular area to help the team have deeper discussions and analysis. It also acknowledge differences in perspective among team members. Introduce the activity by saying “Today we’ll create a baseline measure of our level of satisfaction with the way we work together. We can repeat this activity in future iteration retrospectives to track our progress.” Then show the flip charts to the team, read the definitions, and hand out index cards or other identical small slips of paper, one to each team member with the instructions, “Please write a number on your card that tells your level of satisfaction on the team right now. Then fold the card, and put it in a pile here.” Once all the cards are turned in, stir the pile of cards, and ask for a volunteer to color in the graph as you read them. Read the number on each card. Wait for the tally before going on to the next. Finally, read the results from the graph and ask for comments.

36. Answer D. LGd course manual p. 323 - A team radar is an activity that helps the team gauge how well they are doing on a variety of measures, such as, engineering practices, team values, or other processes. The process for the Team Radar begins when the facilitator introduces the activity by saying, “We agreed on these [fill in the factors] as important to our work. Let’s assess how well we are doing, using a scale of 0--10. Zero means not at all, and 10 means as much as possible.” Post the flip chart with the blank radar graph. Ask each team member to approach the chart and place a dot or some other mark that shows their rating for each factor. Next, lead a short discussion about how the factors affect the work of the team. Consider asking questions such as the following: Where do you see us following these [fill in factors]? Where do you not see us following these [fill in the factors]? Use the short discussion as a segue to generating insights. Save the completed flip chart graph. Run the activity again two or three iterations later.



Page 340

37. Answer B. LGd course manual p. 324 - The Like to Like exercise is designed to help team members recall their experiences during the iteration (release or project), and hear that others may have perceived it differently. In this exercise team members take turns judging which events or factors about their iteration are the best fits for quality cards. As the cards are evaluated, team members learn about each other’s perspective on the same events or conditions. The exercise begins by asking each team member to write at least nine index cards for playing the Like to Like game: three or more cards with things to stop doing three or more cards with things to keep doing and three or more things to start doing. While team members are writing, shuffle the deck of colored “quality” cards and lay the pile face down on a table. When the game cards are ready, invite the team to stand around the table. Choose one person to start as “judge.” The “judge” turns over a “quality” card from the pile and puts it face up on the table. All other team members look in their game cards for the one that most closely matches the “quality” card and place their cards face down. The last card down is disqualified and returns to its owner’s hand. This keeps the game moving. The “judge” stirs the players’ cards, turns them over one at a time, and reads them. He or she chooses the card that makes the best match with the “quality” card. The author of that card wins the “quality” card. The role of “judge” passes left to the next person, and another “quality” card is turned over. After six to nine rounds (or whenever everyone runs out of cards), the game ends. The person with the most “quality” cards wins. Debrief the activity with the four-step method.

38. Answer D. LGd course manual p. 324 - Once the team is done generating their insights it is time to move to the last step and decide what to do. This step is about picking an action that the team will execute. There are a number of potential tools teams may use to determine what to do. Some examples include: Short subjects, SMART goals; The retrospective planning game; and the circle of questions.

39. Answer C. LGd course manual p. 326 - In the retrospective planning game team members work individually or in pairs to brainstorm all the tasks necessary to complete an experiment, improvement, or recommendation. After brainstorming, team members eliminate redundant tasks and fill in gaps. The task are arranged in order, and team members sign up for tasks they will complete. Introduce the activity by saying, “We’re going to work on generating all the tasks needed to have our experiment succeed.” Then recap the experiment (improvement, or recommendation). Here are the steps: Work individually or in pairs to generate all the tasks. Form pairs; Form pairs of pairs; Invite the group to post and cluster the tasks on a whiteboard or wall. If they’ve used cards, they can cluster them using a table; Order the cards; and Invite team members to sign up for tasks.

Chapter 10 — Continuous Improvement


Page 341

Slide 348

Slide 349

Page 341

Continuous Improvement

Continuous Improvement Overview The last domain found in the PMI-ACP® outline is Continuous Improvement. If you are already a PMP®, or have received some other project management training you already know that PMI® places great emphasis on the idea of continuous improvement. It represents the notion that we never, ever achieve perfection. There is always something we can do better. It’s unfortunate that sometimes experienced project leaders forget this concept and get trapped by their process. It is equally unfortunate when Agilists believe that somehow they created the notion of continuous improvement. We all need to do improve continually, but what is the most efficient way to achieve that desired end? Here is where Agile Development provides a critical advantage.

As a domain for the PMI-ACP® Exam, Continuous Improvement has six tasks that are organized in a single group. These tasks include:

To ensure team effectiveness within established organizational guidelines and norms, tailor and adapt the project process by periodically reviewing and integrating team practices, organizational culture, and delivery goals.

To continually enhance the effectiveness of the team, project, and organization, improve team processes by conducting frequent retrospectives and improvement experiments.

Seek feedback on the product by incremental delivery and frequent demonstrations in order to improve the value of the product.

Create an environment of continued learning by providing opportunities for people to develop their skills in order to develop a more productive team of generalizing specialists.

To increase individual efficiency & team effectiveness, challenge existing process elements by performing a value stream analysis and removing waste.

To avoid re-occurrence of identified problems and improve the effectiveness of the organization as a whole. create systemic improvements by disseminating knowledge and practices across projects and organizational boundaries.

Retrospectives Are Key

Continuous improvement is really all about the process that is used to produce the product or the service of the project and not the product or service itself. The idea is that by constantly improving the processes it will lead to better products or services of the project. The primary tool used by Agilists to make these improvements is a process review that occurs at regular intervals. In Scrum and several other Agile methodologies these periodic reviews are called Retrospectives, and they are absolutely critical to Agile’s success. Retrospectives



Page 342

Slide 350

Slide 351

allow the team to constantly improve their productivity, capability, and quality. The Retrospective may sounds a little too good to be true. In actuality, doing Retrospectives well does lead to all these results. The problem is that they are very difficult to do well. At the end of the day, it is all about working and communicating with people. Few Agile teams start out doing Retrospectives well. It takes time, effort and a lot of practice to see results. Because of this, many Agile coaches and authors make a nice living simply by focusing on Retrospectives.

Retrospective Steps

Superficially, retrospectives seem rather easy. Get the team together at the end of each iteration and talk about what went right and what went wrong. Pick one or two of the things that went wrong and figure out how to make them better in the next iteration. Oh yeah, and don’t forget to not let any of the things that went right or wrong slip in the future. Unfortunately, the reality is often quite different. As soon as a group of people starts talking about what went wrong, there is always a risk of someone taking the conversation to mean that it went wrong because of them. It is at this point that any hope of organizational learning falls flat. To address this, and to create the best possible environment for organizational learning, Agile Development establishes structures around the Retrospective. These structures offer teams a great deal of flexibility, but also create much needed boundaries.

Every Retrospective uses the same basic four-step process. These steps include setting the stage, gathering data, generating insights, and closing the Retrospective. What each step looks like in a practical sense is largely defined by the team, but there are some basics. For the purposes of this discussion, we will be using the notion of a Retrospective as defined in Scrum. That meeting is designed to occur at the end of each Sprint and be 90 minutes or less in length. The Retrospective is attended by all the members of the Development Team plus the Scrum Master. There is a lot of debate over whether the Product Owner should attend the Retrospective. The Scrum Guide says they should as a member of the team. However, many practitioners argue the Product Owner does not attend the Retrospective, to allow the team to talk openly and honestly about how the project is going.

The Scrum Master attends primarily as a facilitator, and begins the meeting by checking in with each member of the development team. The facilitator asks a few simple questions about the emotional state of each team member, making sure to not allow anyone to say “I’m fine” and have that be the end of the conversation. This is an opportunity for a good facilitator to empathize with each team member and to show consideration and compassion for their well-being. It is also important that every member of the team clearly understands what an appropriate topic of conversation is for the meeting. A common tool for this is called Focus On / Focus Off.

The idea behind Focus On / Focus Off is to engage the team in a brief conversation about things that they should talk about or focus on and things that are off limits,



Page 343

Slide 352

or should have the team’s focus off. The facilitator must get the team to focus on asking probing questions without advocating. They must be willing to participate in a dialogue based on this inquiry without entering into a debate. The goal is for the team to have an open, non-threatening conversation that never escalates into an argument. The goal is to promote understanding. Individuals should never feel the need to become defensive. Successful facilitators can get team members to use language such as us, we or together, and avoid terms like I, me, or alone. They promote the idea that we are one team and must work together to achieve success.

Another exercise that can help the team get into the proper frame of mind to complete the Retrospective is ESVP. In this exercise, each participant anonymously reports his or her attitude toward the retrospective as an Explorer, Shopper, Vacationer, or Prisoner (ESVP). The retrospective leader then collects the results and creates a histogram to show the data. Finally, the facilitator guides a discussion about what the results mean for the group. Typically, the ESVP exercise goes through a series of specific steps that begin when the facilitator explains that they are taking a poll to learn about how people view their participation in the retrospective. The facilitator then shows the team the blank histogram and defines the major terms in ESVP as follows:

Explorers are eager to discover new ideas and insights. They want to learn everything they can about the iteration/release/project.

Shoppers will look over all the available information and be happy to go home with one useful new idea.

Vacationers aren’t interested in the work of the retrospective but are happy to be away from the daily grind. They may pay attention some of the time but they are mostly glad to be out of the office.

Prisoners feel that they’ve been forced to attend and would rather be doing something else.

The facilitator then distributes slips of paper or small index cards for people to record their attitude toward learning in the retrospective. They then instruct the team to fold their paper in half for privacy. As people finish writing and folding, the facilitator collects the slips and shuffle them. One of the participants is asked to make tick marks on the histogram as you read the slips. After the facilitator reads each slip, they put them in their pocket to prevent anyone from guessing who made each choice by examining the writing. When all the slips are read, the facilitator must ensure they are torn up and thrown away. It is important that the facilitator is conspicuous about this so people know that no one will try to identify how people responded from the handwriting. The facilitator then asks the group, “What do you make of this data?” and leads a brief discussion about how the attitudes in the room will affect the retrospective.

After the facilitator has checked in with each member of the team and has ensured that they are in a mental position to be part of the team, it is time to move on to the next step. This is confirming the working agreement for the meeting. Think of a working agreement as a simple set of rules used by the team to ensure that



Page 344

Slide 355-356

everyone is focused on the right things and that everyone treats the other members of the team with respect.

With the ground rule or working agreements in place, it is time to gather data. This step uses all of the games and other techniques described previously in this course. Once the team has its quantifiable data that they trust to be true, they are able to generate insights and then decide what to do.

The final step in the process is to close the Retrospective. The facilitator has a number of engaging methods they can use to summarize the outcomes of the Retrospective. Examples include:

Plus / Delta or Ben Franklin T

Helped, Hindered, Hypothesis

Return on Time Invested

Appreciations

Each of these exercises is focused on getting the team to describe positive outcomes of the Retrospective.

Pre-Mortem

Most Scrum teams do some type of post-mortem after each sprint. Most of the literature today calls these activities Retrospectives which has a more positive connotation. The term post mortem is Latin for “occurring after death.” After training exercises, the Army conducts after-action reviews, affectionately called AARs. For informal AARs (formal AARs have a proscribed format that is expected to be followed) Gary Klein argues three questions elicit the most participation – what went well, what did not go well, and what could have been done better. This same format is often effective in sprint retrospectives.

A pre-mortem retrospective follows a very different format. It asks the participants to fast forward in time after the release, and assume that the project was a failure. Klein’s suggestion is to take two minutes and allow each participant to privately compile a list of why the project failed. He then surveys the group and compiles a consolidated list of why the project failed. Finally, after compiling the master list, he asks everyone in the room to think up one thing that they could do to help the project. Ideally the team is more attuned to what could go wrong and is willing to engage in risk management.

In concept the idea makes a ton of sense. It forces the team to be honest with themselves about risks, to temper over-confidence, and ultimately to be more proactive. On the other hand a pre-mortem is one more meeting and one more activity that is not directly contributing to the project.

Pre-Mortems typically have just a few rules:

The Pre-Mortem is 2 hours of uninterrupted time.

All stakeholder MUST be present.



Page 345

Slide 357

The Pre-Mortem must be a face-to-face meeting.

One person does nothing but take notes.

Just like there are many different ways to conduct a Retrospective, there are a number of different exercises that may be used for a Pre-Mortem. However, most of the time the process looks somewhat similar, even if it doesn’t totally align with Klein’s notion of the Pre-Mortem. Generally, the team begins by spending an hour listing every potential cause of a particular problem. Then the team picks the top 10 causes or problems. The goal is to focus on the show-stoppers—those problems that could kill the project. However, it is almost equally as important that the team picks problems that are likely to happen. They should discard problems they have no control over. The second hour is spent creating proactive solutions for these problems and defining a backup plan.

As you complete your studies for the PMI-ACP® Exam it is important that you remember that not every project needs to be an Agile project. Agile Methodologies provide a number of key advantages over linear methods, and many of the concepts found in Agile can be applied to any project without all the methodology. The projects that best align to Agile Development are ones where there isn’t 100% agreement at the beginning about what must be delivered, and the teams knowledge concerning the tools and implementation is also not perfect. These two factors cause projects to first become complicated and then become complex depending on the number of people involved and the level of technology. Such instances scream for an Agile solution.

We hope you have found this course useful as you prepare for the exam. As always, should you have questions don’t hesitate to contact us.



Page 346

Exercise 12 —Continuous Improvement

Continuous Improvement Exercise 1. Which of the following is NOT a task found in the continuous area?

A. Tailor and adapt the project process by periodically reviewing and integrating team practices, organizational culture and delivery goals.

B. Improve team processes by conducting frequent retrospectives and improvement experiments.

C. Seek feedback on the product by incremental delivery and frequent demonstrations. D. Maintain a visible, monitored and prioritized list of threats and issues in order to

elevate accountability, encourage action & track ownership.

2. Which of the following is NOT a step in the retrospective process?

A. Set the stage B. Generate insights C. Close the retrospective D. Review the results

3. All of the following EXCEPT ______ attend the scrum retrospective?

A. The product owner B. The scrum master C. The development team D. The customer

4. When using the ESVP exercise what does the S stand for?

A. Skeptics B. Shoppers C. Scouts D. Sycophants

5. When using the ESVP exercise within a retrospective, which of the roles is eager to discover new ideas and insights and wants to learn everything they can about the iteration/release/project?

A. Explorers B. Shoppers C. Vacationers D. Prisoners

6. Within the ESVP exercise, which of the roles will look over all the available information, and will be happy to go home with one useful new idea?

A. Explorers B. Shoppers C. Vacationers D. Prisoners

7. When using the ESVP exercise which of the defined roles are not interested in the work of the retrospective, but are happy to be away from the daily grind and may pay attention some of the time, but they are mostly just glad to be out of the office?

A. Explorers B. Shoppers



Page 347

C. Vacationers D. Prisoners

8. Which of the following is NOT a rule for pre-mortems?

A. The Pre-Mortem is 2 hours of uninterrupted time. B. All stakeholder MUST be present. C. The scrum master must lead the meeting. D. One person does nothing but take notes.

9. As a PMI member you have a responsibility to follow PMI's code of Conduct. It is critical that you know this code them emphasizes which of the following?

A. Ethics, morality, honesty, and responsibility B. Respect, morality, honesty, and transparency C. Responsibility, transparency, ethics, morality D. Responsibility, honesty, respect, fairness

10. You are brought into the organization as a consultant to help the organization both implement Scrum and tailor it to the organization. What advice should you give this organization FIRST?

A. It is critical that the organization tailors any agile methodology to how the business works.

B. The organization should tailor the process in a pilot environment first. C. The organization should try Scrum based on the rules before attempting any

customization. D. It is critical that the organization uses process tailoring as part of its adoption process.

11. You are called on to help your team conclude it retrospective. Which of the following are tools you likely might choose to use?

A. ESVP, Planning Poker, Remember the Future, Triple Nickels B. Color Code Dots, Triple Nickels, Mad Sad Glad, Ben Franklin T C. Appreciations, Return on Time Invested, Ben Franklin Ts, Helped Hindered

Hypothesis D. Team radar, Appreciations, Locate Strengths, Return on Time Invested

12. Which of the following is the BEST definition of an agile information exchange?

A. A focused face-to-face communication tool to facilitate knowledge sharing. B. A tool designed to convey project information electronically. C. A communication tool designed to promote transparency. D. A tool designed to accurate resource utilization.

13. Each of the following is NOT a common practice considered part of continuous improvement?

A. Paired programming B. Retrospectives C. Planning poker D. Daily stand-ups

14. Your team has just completed its sprint review and begun its retrospective. Which of the following represent the best order of steps?

A. Set the stage, gather data, generate insights, decide what to do, and close the retrospective.

B. Determine the goal, gather data, set the stage, generate insights, and close the retrospective.

C. Gather data, set the goal, generate insights, decide what to do, and close the



Page 348

retrospective. D. Set the goal, generate insights, decide what to do, and close the retrospective.

15. You are acting as an Agile Coach and have been asked by your client when they should collect lessons learned. What is the BEST answer to this query?

A. During the retrospective. B. During the sprint review. C. Throughout the project. D. Only when the project struggles.



Page 349

Continuous Improvement Exercise 1. Answer D. LGd course manual p. 340 - As a domain for the PMI-ACP® Exam, Continuous

Improvement has six tasks that are organized in a single group. These tasks include: Tailor and adapt the project process by periodically reviewing & integrating team practices, organizational culture, & delivery goals in order to ensure team effectiveness within guidelines & norms. Improve team processes by conducting frequent retrospectives and improvement experiments in order to continually enhance the effectiveness of the team, project, and organization. Seek feedback on the product by incremental delivery and frequent demonstrations in order to improve the value of the product. Create an environment of continued learning by providing opportunities for people to develop their skills in order to develop a more productive team of generalizing specialists. Challenge existing process elements by performing a value stream analysis and removing waste in order to increase individual efficiency and team effectiveness. Create systemic improvements by disseminating knowledge and practices across projects and organizational boundaries in order to avoid re-occurrence of identified problems and improve the effectiveness of the organization as a whole.

2. Answer D. LGd course manual p. 340 - Every Retrospective uses the same basic four-step process. These steps include setting the stage, gathering data, generating insights, and closing the Retrospective.

3. Answer A. LGd course manual p. 340 - The Retrospective is attended by all the members of the Development Team plus the Scrum Master. The Product Owner does not attend the Retrospective to allow the team to talk openly and honestly about how the project is going. The Scrum Master attends primarily in the role as a facilitator and begins the meeting by checking in with each member of the development team.

4. Answer B. LGd course manual p. 342 - In the ESVP exercise each participant anonymously reports his or her attitude toward the retrospective as an Explorer, Shopper, Vacationer, or Prisoner (ESVP). The retrospective leader then collects the results and creates a histogram to show the data.

5. Answer A. LGd course manual p. 342 - Within the ESVP exercise explorers are eager to discover new ideas and insights. They want to learn everything they can about the iteration/release/project.

6. Answer B. LGd course manual p. 342 - Within the ESVP exercise shoppers will look over all the available information, and will be happy to go home with one useful new idea.

7. Answer C. LGd course manual p. 342 - Within the ESVP exercise Vacationers aren’t interested in the work of the retrospective, but are happy to be away from the daily grind. They may pay attention some of the time, but they are mostly glad to be out of the office.

8. Answer C. LGd course manual p. 342 - Pre-Mortems typically have just a few rule: The Pre-Mortem is 2 hours of uninterrupted time. All stakeholder MUST be present. The Pre-Mortem must be a face-to-face meeting. One person does nothing but take notes.

9. Answer D. PMI’s Code of Ethics and Professional Conduct focuses on Responsibility, Respect, Fairness, and Honesty.

10. Answer C. LGd course manual p. 344 - A good rule with any new process or method is to



Page 350

implement the basic process before attempting any customization. This allows the team to understand how the basic process is supposed to work, learning its specific ins and outs before attempting any customization.

11. Answer C. LGd course manual p. 343 - The final step in the process is to close the Retrospective. The facilitator has a number of engaging methods they can use to summarize the outcomes of the Retrospective. Including: Plus/Delta or Ben Franklin T; Helped, Hindered, Hypothesis; Return on Time Invested; & Appreciations. Each of these exercises is focused on getting the team to describe positive outcomes of the Retrospective.

12. Answer A. LGd course manual p. 343 - Agile information exchanges facilitate knowledge sharing. They are face-to-face methods not focused any kind of resource optimization, but instead are focused on the exchange of information.

13. Answer C. LGd course manual p. 341- Many agile practices aid in continuous improvement. Some of which include ideas like paired programming, retrospectives, sprint reviews, other demonstrations, daily stand ups, team boards, and others.

14. Answer A. LGd course manual p. 341 - Every Retrospective uses the same basic four-step process. These steps include setting the stage, gathering data, generating insights, and closing the Retrospective. What each step looks like in a practical sense is largely defined by the team.

15. Answer C. LGd course manual p. 340 - Lessons learned represent a common term used by PMI. They represent those key lessons that often transcend a single project or phase. The team should constantly be looking for these keys whenever they occur as opportunities to improve.

ACP Exam PrepMartin [email protected]

Agenda

• The Process

• The Exam

• Agile Principles & Mindset– Basics

– Scrum

– XP

– FDD

– DSDM

– Crystal

– Lean

– Kanban

– SAFe

– Nexus

– LeSS

– DAD

• Value Driven Delivery

• Stakeholder Engagement

• Boosting Team Performance

• Adaptive Planning

• Problem Detection & Resolution

• Continuous Improvement

v. 10.2 ‐ © Copyright and all rights reserved – 2020 Looking Glass Development, LLC. 2

1

2

The Process

Application ProcessApplication Submission

You have 90 days to complete your application once you start it.

Application Completeness Review10 days when submitted online

Applicant Payment ProcessYou cannot schedule the exam until

you pay the certification fees.

Audit ProcessIf your application is selected for

audit you have 90 days to collect the requested materials. PMI will process

the audit in 5‐7 days.

Exam SchedulingYou cannot schedule the exam until

you pay the certification fees.

The ExamYou have one year from the date of

application acceptance to pass exam. You can take the exam 3 times in that

period.

Renewal3 year renewal period requiring 30

PDUs.v. 10.2 ‐ © Copyright and all rights reserved – 2020

Looking Glass Development, LLC. 4

3

4

ACP Qualifications

Education +

General Project

Experience +Agile Project Experience +

Training in Agile Practices

High School Diploma,Associates Degree or equivalent

2,000 hours (12 months) working on projects in the last 5 years. Hours must be non‐overlapping.

1,500 hours (8 months) working on project teams using agile methodologies in the last 3 years in addition and separate from the 2,000 hours of general PM experience.

21 contact hours in agile practices.

PMPs and PgMPs will not have to prove their general project management experience.


Scheduling Your Exam

To Find a Testing Center

• Online: https://home.pearsonvue.com/pmi• Select Find Test Center

• Enter ZIP Code

To Schedule Your Exam• Select Login from Pearson website

• As if April 1, 2019 ACP is available proctored online:

https://home.pearsonvue.com/pmi/op


5

6

Rescheduling/Cancelling

• Within 30 days $70 charge.

• Within 2 days forfeit entire fee.

• “Extenuating Circumstances”– Medical emergency

– Military deployment

– Death in immediate family

– Illness in immediate family

– Natural disaster

• Work related circumstances will not be accepted.


Fees• 1st Take Fees

– PMI Members: $435

– Non‐PMI Members: $495

• Retakes– PMI Members: $335

– Non‐PMI Members $395

• Refunds: $200 if test not scheduled or taken within exam period.


7

8

The Exam

Exam Results

• An overall pass/fail score.

• Each topic area is assigned one of three levels of proficiency.

– Proficient

– Moderately Proficient

– Below Proficient


9

10

The Exam

• Total Questions: 120

• Scored Questions: 100

• 3 Hours to take the exam.

• No scheduled breaks, but you are allowed one bio break.

• Exam preceded by an optional tutorial.

• Exam followed by optional survey.


Exam Breakdown

Percentage of Questions

Agile Tools & Techniques 50%

Agile Knowledge & Skills 50%

Total: 100%


11

12

The ExamTools and Techniques 50% of Exam

Communications Including but not limited to: information radiator, team space, agile tooling, osmotic communications for co‐located and/or distributed teams, daily stand‐ups.

Planning, Monitoring & Adapting Including but not limited to: retrospectives, Scrum/Kanban boards, time‐boxing, iteration and release planning, WIP limits, burn down/up charts, cumulative flow diagrams, process tailoring.

Agile Estimation Including but not limited to: relative sizing/story points, wide band Delphi/planning poker, affinity estimating, ideal time.

Agile Analysis and Design Including but not limited to: product roadmap, user stories/backlog, story maps, progressive elaboration, wireframes, chartering, personas, agile modeling.

Product Quality Including but not limited to: frequent verification and validation, test‐driven development/test first development, acceptance test‐driven development, definition of done, continuous integration.

Soft Skills Negotiation Including but not limited to: emotional intelligence, collaboration, adaptive leadership, negotiation, conflict resolution, servant leadership.


The Exam

Tools and Techniques 50% of ExamValue‐based Prioritization Including but not limited to: return on investment

(ROI)/net present value (NPV)/internal rate of return (IRR), compliance, customer‐valued prioritization, minimally marketable feature (MMF), relative prioritization/ranking.

Risk Management Including but not limited to: risk‐adjusted backlog, risk burn down graphs, risk‐based spike.

Metrics Including but not limited to: velocity, cycle time, earned value management (EVM) for agile projects, escaped defects.

Value Stream Analysis Including but not limited to: value stream mapping.


13

14

Test Breakdown

Level % of Knowledge & Skill Content / % of Exam

Level 1 (18 knowledge/skills) 65% / 33%




Knowledge & Skills 50% of Exam

Level 1 (33% of Total Examination Questions)

• Active listening

• Agile Manifesto values & principles

• Assessing & incorporating community & stakeholder values

• Brainstorming techniques

• Building empowered teams

• Coaching & mentoring within teams

• Communications management

• Feedback techniques for product (e.g. prototyping, simulation, demonstrations, evaluations)

• Incremental delivery

• Knowledge sharing

• Leadership tools & techniques

• Prioritization

• Problem‐solving strategies, tools, & techniques

• Project & quality standards for Agile projects

• Stakeholder management

• Team motivation

• Time, budget, & cost estimation

• Value‐based decomposition & prioritization


15

16


• Agile frameworks & terminology

• Building high‐performance teams

• Business case development

• Colocation (geographic proximity) / distributed teams

• Continuous improvement processes

• Elements of a project charter for an Agile project

• Facilitation methods

• Participatory decision models (e.g. input‐based, shared collaboration, command)

• PMI’s code of Ethics & Professional Conduct

• Process analysis techniques

• Self assessment

• Value‐based analysis



• Agile contracting methods

• Agile project accounting principles

• Applying new Agile practices

• Compliance (organization)

• Control limits for Agile projects

• Globalization, culture, & team diversity

• Agile games

• Principles of systems thinking (e.g. complex adaptive, chaos)

• Regulatory compliance

• Variance & trend analysis

• Variations in Agile methods & approaches

• Vendor management


17

18

Key Readings• Agile Retrospectives: Making Good Teams Great, Esther Derby, Diana Larsen, Ken

Schwaber.• Agile Software Development: The Cooperative Game – 2nd Edition, Alistair Cockburn.• The Software Project Manager’s Bridge to Agility, Michele Sliger & Stacia Broderick.• Coaching Agile Teams, Lyssa Adkins.• Agile Project Management: Creating Innovative Products – 2nd Edition, Jim Highsmith.• Becoming Agile: …in an Imperfect World, Greg Smith & Ahmed Sidky.• Agile Estimating and Planning, Mike Cohn.• The Art of Agile Development, James Shore.• User Stories Applied: For Agile Software Development, Mike Cohn.• Agile Project Management with Scrum, Ken Schwaber.• Lean‐Agile Software Development: Achieving Enterprise Agility, Alan Shalloway, Guy

Beaver, James R. Trott.• Effective Project Management: Traditional, Agile, Extreme, Robert Wysocki.• Exploring Scrum: The Fundamentals, Dan Rawsthorne with Doug Shimp.• Kanban In Action, Marcus Hammarberg, Joakim Sunden.• Kanban: Successful Evolutionary Change for Your Technology Business, David J.

Anderson.


Domain Breakdown

Domain% of Itemson Exam

1. Agile Principles & Mindset 16%

2. Value‐Driven Delivery 20%

3. Stakeholder Engagement 17%

4. Team Performance 16%

5. Adaptive Planning 12%

6. Problem Detection & Resolution 10%

7. Continuous Improvement (Product, Process, People)

9%


19

20

Agile Principles & Mindset

Agile Principles & MindsetDomain Tasks

1. Advocate for agile principles by modeling those principles & discussing agile values in order to develop a shared mindset across the team as well as between the customer & the team.

2. Help ensure that everyone has a common understanding of the values & principles of agile & a common knowledge around the agile practices & terminology being used in order to work effectively.

3. Support change at the system or organization level by educating the organization & influencing processes, behaviors, & people in order to make the organization more effective & efficient.

4. Practice visualization by maintaining highly visible information radiators showing real progress & real team performance in order to enhance transparency & trust.

5. Contribute to a safe & trustful team environment by allowing everyone to experiment & make mistakes so that each can learn & continuously improve the way he or she works.

6. Enhance creativity by experimenting with new techniques & process ideas in order to discover more efficient & effective ways of working.

7. Encourage team members to share knowledge by collaborating & working together in order to lower risks around knowledge silos & reduce bottlenecks.

8. Encourage emergent leadership within the team by establishing a safe & respectful environment in which new approaches can be tried in order to make improvements & foster self‐organization & empowerment.

9. Practice servant leadership by supporting & encouraging others in their endeavors so that they can perform at their highest level & continue to improve.


21

22

PMBOK Guide vs. Agile

• PMBOK® Guide is the umbrella framework.

• Agile represents a family of lifecycles sometimes called methodologies or frameworks.

• Agile methodologies fit within the PMBOK® Guide.


The Basics of PM


23

24

The Four Types of Life Cycles• Predictive life cycle – The “traditional” approach. It is a linear

process with the majority of planning upfront then executed in a single sequential pass. They take advantage of things that are known and proven. The plan drives the work. Value is only delivered at the end.

• Iterative life cycle – An approach that allows feedback for unfinished work to improve and modify future outcomes. Prototypes and proofs are planned, and the outputs are intended to modify the plans at the beginning. When complexity is high or when there are frequent changes or scope is unknown.

• Incremental life cycle – An approach that provides finished deliverables in steps that the customer may use immediately. Here we plan to deliver successive subsets of the overall project. The team may deviate from the original vision. It uncovers hidden or misunderstood requirements.

• Agile life cycle – An approach that is BOTH iterative and incremental to refine work items AND deliver frequently. Here we plan and re‐plan as more information becomes available.


The Four Types of Life CyclesCharacteristics

Approach Requirements Activities Delivery Goal

Predictive Fixed Performed once for the entire project

Single delivery Manage costs

Iterative Dynamic Repeated until correct

Single delivery Correctness of solution

Incremental Dynamic Performed once for a given increment

Frequent smaller deliveries

Speed

Agile Dynamic Repeated until correct

Frequent smaller deliveries

Customer value via frequent delivery and feedback


25

26

The Four Types of Life Cycles

27v. 10.2 ‐ © Copyright and all rights reserved – 2020 Looking Glass Development, LLC.

Pre

dic

tive

Ite

rati

veIn

cre

me

nta

lA

gile

Analysis

Pla

n

Pro

toty

pe

Eval

uat

e

Bu

ild

Dep

loy

Pla

n

Pro

toty

pe

Eval

uat

e

Bu

ild

Pla

n

Pro

toty

pe

Eval

uat

e

Bu

ild

Pla

n

Pro

toty

pe

Eval

uat

e

Bu

ild

3 to 24 monthsA

nal

ysis

Des

ign

Co

de

Test

Dep

loy

Design Code Test DeployR

elea

se

Pla

nn

ing

Spri

nt

Pla

nn

ing

Spri

nt

Spri

nt

Rev

iew

Ret

rosp

ecti

ve

Daily Scrum

Spri

nt

Pla

nn

ing

Spri

nt

Spri

nt

Rev

iew

Ret

rosp

ecti

ve

Daily Scrum

Spri

nt

Pla

nn

ing

Spri

nt

Spri

nt

Rev

iew

Ret

rosp

ecti

ve

Daily Scrum

Rel

ease

Pla

nn

ing

Spri

nt

Pla

nn

ing

Spri

nt

Spri

nt

Rev

iew

Ret

rosp

ecti

ve

Daily Scrum

An

alys

is

Des

ign

Co

de

Test

Dep

loy

An

alys

is

Des

ign

Co

de

Test

Dep

loy

An

alys

is

Des

ign

Co

de

Test

Dep

loy

1 to 3 months 1 to 3 months 1 to 3 months 1 to 3 months

1 to 3 months 1 to 3 months 1 to 3 months 1 to 3 months

2 to 6 weeks 2 to 6 weeks 2 to 6 weeks 2 to 6 weeks

The Four Types of Life Cycles


Incremental

Predictive

Agile

Iterative

Degree of Change

Freq

uen

cy o

f D

eliv

ery

Low

Low

High

Hig

h

27

28

Two Types of Agile• Iteration‐based Agile

– Team works in iterations to deliver features.

– Works from most important feature to least.

– Team does NOT address even all the features in an iteration at once.

• Flow‐based Agile

– Team pulls features from the backlog based on its capacity to start work rather than on an iteration‐based schedule.

– Team defines its workflow with columns on a task board and manages the work in progress for each column.

• Agile life cycles are those that fulfill the principles of the Agile Manifesto.


Agile is Iterative & Incremental• Incremental development – is a staging &

scheduling strategy in which the various parts of the system are developed at different times or rated and integrated as they are completed.

• Iterative development – is a rework scheduling strategy in which time is set aside to revise and improve parts of the system.

Alistair Cockburn

Overview


29

30

Strategies to Implement Agile

• Adopt a formal agile approach. Learn the approach in detail & then tailor it.

• Implement changes to project practices that fits the project context to get progress on a core value or principle.


Agile in Context


Lean

AgileKanbanScrumBan

AUPCrystal

Scrum

XPFDD

DSDM

31

32

Agile Methodologies

• 16 different frameworks/methodologies are “Agile”• Most common include:

– Scrum– Extreme Programming– Feature‐Driven Development (FDD)– Dynamic Systems Development Method (DSDM)– Crystal (Crystal Clear, Crystal Yellow, Crystal Orange…)

• Closely related concepts include:– Lean software development– Kanban

• Exam focuses on Scrum & XP although others might appear.


Iterative & Incremental Approaches

• Very short feedback loops

• Frequent adaptation of process

• Reprioritization

• Regularly updated plans

• Frequent delivery


33

34

The Effects of WIP & “Best Resourcing”

Deliverable X

Option 1 A A

Option 2 A C A

Deliverable Y

Option 1 B B

Option 2 B B C

Deliverable Z

Option 1 C C

Option 2

• In Option 1 the best resource for the deliverable attempts to do each task for the feature and nothing gets delivered.

• In Option 2 resourcing is applied based upon availability and two features are delivered.



1960 1966 1972 1978 1984 1990 1996

USAF & NASAX‐15 hypersonic jet

Iterative Incremental Delivery

1950s‐1960s

Tom GilibAdaptive iterations, fast time to market

1976

Gerald Weinberg Small increments, customer‐driven

feedback

1980

Barry BoehnSpiral Model

1985

Hirotaka Takeuchi & IkujiroNonaka

The New New Product Development Game

1986

Fred Brooks

Mythical Man Month

1975

Fred Brooks

No Silver Bullet ‐ Essence and

Accident in Software

Engineering

1986

Ken Schwaber & Jeff SutherlandScrum Framework

1990

DSDM Consortium ‐

Dynamic System Development

Method

1994

Booch, Jacobson & RumbaughRational Unified Process

1995

Beck, Cunningham, & JeffriesExtreme Programming

1996

Jeff de LucaFeature Driven Development

1997

Alistair CockburnCrystal Family

1998

Robert CharetteLean Development

2000

35

36

The Beginning of Agile• February, 2001 in Snowbird, Utah

Overview

Kent Beck Mike Beedle

Arie van Bennekum Alistair Cockburn

Ward Cunningham Martin Fowler

James Grenning Jim Highsmith

Andrew Hunt Ron Jeffries

Jon Kern Brian Marick

Robert C. Martin Steve Mellor

Ken Schwaber Jeff Sutherland

Dave Thomasv. 10.2 ‐ © Copyright and all rights reserved – 2020


Overview

Agile Development Values…• Individuals & Interactions OVER Processes & Tools

• Customer Collaboration OVER Contract Negotiations

• Responding to Change OVER Following a Plan

• Working Software OVER Comprehensive Documentation


37

38

The 12 Principles of Agile Software1. 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 face‐to‐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.

Overview


The Heartbeat of Agility


39

40

Must, Wants & Needs

Needed Features36%

Rarely Used Features, 19%

Never Used Features

45%

Role of the ProductOwner is to cut offthe project beforewe do what won’tbe used.


Key Terms Pairing – Two developers working together at one workstation. One

writes the code while the other reviews each line as they go.

Swarming – The entire team swarms around a single feature or story e.g. everyone works together on a single story or feature at the same time. It sets a WIP limit of 1.

Mobbing – Combines the concepts of pairing and swarming. The entire team works off of a single keyboard on a single feature.

Mini‐waterfalls – team addresses all of the requirements in a given period, then attempts to do all of the design, then moves onto do all of the execution.

Fishbowl window – Long‐lived video conference link that allows non‐collocated team members to watch each other throughout the day to reduce collaboration lag.

Scrum Basics


41

42

Scrum Basics• Based on industrial process theory

– Self‐organization

– Emergence

• Defined Process Control vs. Empirical Process Control – Defined Processes ‐ Repeatable processes such as in

manufacturing. Leads to commoditization. In projects often leads to rework.

– Empirical Processes ‐ Complex processes where it is difficult to have consistent processes. Focuses on 3 keys.


Foundation• Visibility – The aspects of the process that affect

the outcome must be visible to those controlling the process & what is seen must be true.

• Inspection – The various aspects of the process must be examined frequently enough that unacceptable variances in the process can be detected.

• Adaptation – If one or more of the processes are determined out of control the processes change.

Scrum Basics


43

44

The Scrum Roles• Product Owner – Responsible for representing

interests of all stakeholders, obtaining funding, defining initial requirements, ROI, and objectives (Product Backlog).

• The Development Team – Develops the functionality. Is self‐managing, self‐organizing, and cross functional.

• Scrum Master – Responsible for the Scrum process, teaching Scrum to everyone, implementing Scrum so it fits with culture, and that everyone follows Scrum rules & practices.

Scrum Basics


Team Members

• C – Committed

• F – Focused

• O – Open

• R – Respected & Respectful

• C – Courageous

• E ‐ Extreme


45

46

Key Scrum Artifacts

• Serves as a Charter or 5 Line

• Required to begin any project.

• Never longer than a single page.

• Includes 5 key pieces of information: Need, justification, success criteria, prioritization, constraints & assumptions.


A Product / Project Vision

Product Backlog

Key Scrum Artifacts

• A prioritized list of items to be delivered.

• Each item is “relatively independent” of the others.

• Backlog may bereprioritized at anytime.

• Items = User Stories or PBIs• PBI = Product Backlog Item


47

48

Product Backlog

Key Scrum Artifacts

• New requirements are prioritized by your project stakeholders and added to the stack in the appropriate place.

• Fundamentally a single person needs to be the final authority when it comes to requirement prioritization (PO).

• The PO is responsible for representing all other stakeholders.• The backlog is initially filled as the result of requirements

envisioning efforts at the beginning of the project called "populating the backlog".

• Each iteration the team pulls an iteration's worth of work off the top of the stack and commits to implementing it by the end of the iteration.


Product BacklogKey Scrum Artifacts

• Project stakeholders have the right to define new requirements, change their minds about existing requirements, and even reprioritize requirements as they see fit.

• Stakeholders are responsible for making decisions and providing information in a timely manner. On some projects a business analyst, often in the role of product owner, may take on this responsibility.

• The priorities of non‐requirement work items are either negotiated by the team with stakeholders or are addressed as part of slack time within the schedule.


49

50

Scrum Basics

Scrum = 3 Roles + 4 Artifacts + 5 Meetings

Sprint Retrospective Not more than 2 hours for a 30 day sprint. Not more

than 1 hour to plan.

2 – 6 Week Sprints

Sprint Tasks

Sprint

Backlog

Sprint end date & deliverables do not

change

Daily ScrumEvery 24 Hours


Backlog

Ranked Product

Vision

PO, SM & Teamconduct Sprint

Planning Meeting

• 1/2 to complete grooming.

• 1/2 to define tasks & task estimates in ½ or full days. No task longer than 1 day.

Shippable Product

Release P

lann

ing

Sprint ReviewNot longer than 4 hours for a 30 day sprint nor

more than 1 hour to plan.

The Daily Sprint Schedule


51

52

The Basics of PM

Sprint Planning MeetingPO speak to the sprint goal.

Acceptance criteria.

Team forecasts number of stories.

Team breaks PBIs into tasks.

Estimate tasks: 0.5 / 1.

Build sprint burndown and task board.

53v. 10.2 ‐ © Copyright and all rights reserved – 2020

Looking Glass Development, LLC.

The Basics of PM

The Daily ScrumShort status meeting aligned with tasks.

10 to 15 minutes in length.

Standing meeting.

Done in front of visual progress artifact.

Team reports to each other.

Key questions…



53

54

The Basics of PM

Iteration‐Based vs Flow‐Based Agile Iteration‐based Agile questionsWhat did I complete yesterday?

What am I going to complete today?

What impediments do I have?

Flow‐based Agile questions:What do we need to do to advance this piece of work?

Is anyone working on anything that is not on the board?

What do we need to finish as a team?

Are there any bottlenecks or blockers to the flow of work?



The Basics of PM

Sprint ReviewSummary of sprint by PO.

PO demonstrates every acceptance criteria of every story delivered.

Gather feedback from stakeholders and incorporate into product backlog.

Update release plan and discuss next step.



55

56

The Basics of PM

Sprint RetrospectiveThe most important Scrum meeting.

Important to change something in every sprint.

Remember: “It’s not a lesson learned until you do something about.”

Work on only the 2 most important lessons.



PBI To Do In Progress Validate Impeded Done

TaskTaskTaskTaskTaskTask

PBI 1

PBI 2

PBI 3

PBI 4


TaskTask


TaskTaskTask

Tech DebtTech DebtTech DebtTech DebtTech Debt

Tech DebtTech Debt

Tech DebtTech DebtTech DebtTech Debt


TaskTask

TaskTaskTaskTaskTask

Tech Debt

The Basic Team Board or Scrum Board

Technical Debt

57

58

PBI To Do In Progress Validate Impeded Done


Adding Kanban to Scrum

Technical Debt

5 23

TaskTaskTaskTask

TaskTaskTask

TaskTaskTaskTaskTask

TaskTask

TaskTaskTask

PBI

PBI

PBI

PBI

PBI

Iteration 0• Used by some Scrum teams, but not part of

official process.

• Iteration 0 produces the architecture and feature list

• No useable functionality is produced in Iteration 0

• Iteration or milestone plan is critical to completion

Scrum


59

60

Overview• XP is a methodology that introduces checkpoints

when new requirements can be adopted to improve productivity.

• Iterations of 1 to 2 weeks in length.

• Created by Kent Beck @ Chrysler with Ward Cunningham & Ron Jeffries.

• 12 practices grouped into four (4) areas.

Extreme Programming


Basics

• XP’s Focus is on:

– Goals

– Activities

– Values

– Principles

– Practices

Extreme Programming


61

62

Basics– Goals – Produce high quality software. XP does this

through short development cycles.

– Activities

• Listening ‐ Programmers must listen to customers & understand the business processes.

• Designing – Software must be designed as components without complexity or dependencies between components.

• Coding – Is the meat of the methodology. It is the most important part according to XP advocates.

• Testing

Extreme Programming


Core Values• Simplicity – Reduce complexity, extra features & waste. “Find

the simplest thing that could possibly work.”

• Communication – All the team members know what is expected of them & what others are working on.

• Feedback – The team must get impressions & suitability early. It’s about “failing fast.”

• Courage – The team has to be willing to put its work out there for others to see. Use pair programming & share code.

• Respect – The team is accountable to each other for results.

Extreme Programming


63

64

Basics– Principles

• Assume Simplicity – This is about treating every problem as if its solution were extremely simple.

• Embrace Change – Do not work against change, embrace it.

– Practices (4 areas)

• Fine Scale Feedback

• Continuous Process

• Shared Understanding

• Programmer Welfare

Extreme Programming


Core Practices ‐ Fine Scale Feedback• Paired Programming – Two programmers work together

at one workstation. One programmer writes while the other reviews & thinks strategically. Pairs are not fixed & change often.

• The Planning Game – XP’s main planning process. Occurs once per iteration (typically once per week) Incudes two parts: Release Planning & Iteration Planning.

Extreme Programming


65

66

Fine Scale Feedback‐ Release Planning• Focused on determining which requirements are

included in which near‐term release & when they should be delivered.

• Customer & developer are part of this.• Includes three (3) phases:

– Exploration Phase – Customer provides a short list of high‐value requirements for the system that are written as User Stories.

– Commitment Phase – Business & developers commit to the functionality to include & next release date.

– Steering Phase – Plan can be adjusted, new requirements added, existing requirements changed or removed.

XP Core Practices


Fine Scale Feedback ‐ Iteration Planning• Focused on planning the tasks & activities of the

developers.

• Customer is NOT part of this.

• Includes three (3) phases:– Exploration Phase – The requirements are translated

to specific tasks & recorded on task cards.

– Commitment Phase – The tasks are assigned to programmers & the task durations estimated.

– Steering Phase – Tasks are performed & the results then matched with the original User Story.

XP Core Practices


67

68

Core Practices ‐ Fine Scale Feedback• Test Driven Development – Tests are written before code

is written. Tests are automated.– Write unit tests.

– Fail tests. Programmers verify the tests fail.

– Write code. Programmers write minimal amount of code to pass tests.

– Pass tests. Code is tested to ensure passage.

– Refactor. Remove any code smells from the code.

• Whole Team – The customer does not always pay the bill, but always uses the system. Customer must be on hand at all times to answer questions.

XP Core Practices


XP Core Practices – Continuous Process• Continuous Integration – XP employs continuous

integration & requires the use of a repository loading it every few hours. Integration tests are run automatically.

• Design Improvement – Only code what is needed today. When problems occur refactor code to make it simpler & more generic.

• Small Releases – Frequent small releases to test are encouraged. Quality is maintained through continuous integration.

Extreme Programming


69

70

Core Practices – Shared Understanding• Coding Standards – An agreed upon set of rules that the

entire team follows for a consistent style & format. XP advocates self‐documenting code that reduces the need for code comments.

• Collective Code Ownership – Any pair of developers can make changes to any code & everyone is responsible for all code.

• Simple Design – “Simplest” is best approach to software design.

• System Metaphor – It is a story that everyone can understand about how the system works. It creates a naming convention that allows customers to guess what class/methods do.

Extreme Programming


Core Practices ‐ Programmer Welfare• Sustainable Pace – Programmers should not work more

than 40 hours per week & no two weeks in a row should have overtime.

• A key enabler of this concept is frequent code merges of code that is always executable. This code must constantly be tested to ensure it is of a high quality.

Extreme Programming


71

72

The Extreme Programming Workflow


1. Envision ‐ conversations With the customer.

2. Speculate – StoriesAre generated

3. Explore ‐ Developers use PairedProgramming to develop

code.

SourceControl

Local

Integratio

n

Ch

eck‐

In

Test

Code

Refactor

Continuousintegration

5. Close ‐ Customer Acceptance Testing

4. Adapt

The Basic Steps• Envision – determine the product vision, project

community, and how the team will work together.

• Speculate – develop a feature‐based release, milestone, and iteration plan to deliver on the vision.

• Explore ‐ deliver tested features in a short timeframe, constantly seeking to reduce the risk and uncertainty of the project.

Extreme Programming


73

74

The Basic Steps• Adapt – review the delivered results, the

current situation, and the team’s performance, and adapt as necessary.

• Close – conclude the project, pass along key learnings and celebrate

Extreme Programming


XP vs. Scrum

Scrum• Teams work in sprints of 2

to 6 weeks.

• Teams do NOT allow changes into their sprints.

• Scrum teams control the order of work, but are informed by the PO.

• Scrum doesn’t prescribe any engineering practices

Extreme Programming• Teams work in iterations of

1 to 2 weeks.

• So long as work has not started on a feature it may be changed or replaced.

• XP teams work on a strict priority order as defined by the customer.

• XP prescribes TDD, automated testing, pair programming, simple design


75

76

Feature‐Driven Development (FDD)• Created by

– Peter Coad – A leader in the Object Oriented Programming Movement.

– Jeff De Luca – Co‐wrote book with P. Coad. IBM Project Manager. Then founder of Nebulon Corp. in Australia.

• Reference books

– Java Modeling Color with UML (Last Chapter) 1999

– A Practical Guide to Feature‐Driven Development 2002

• Origins

– Singapore Bank where Peter & Jeff worked together.


Feature‐Driven Development (FDD)

Develop an

overall model

Build a feature

list

Plan by feature

Design by

feature

Build by feature


77

78

Feature‐Driven Development (FDD)• 1. Develop Overall Model – The team holds a

kickoff and walks through the scope of the system including all of its context.

– Detailed domain models are created for each modeling area by small teams and presented for peer review.

– One of the proposed models is selected to become area domain model.

– Domain area models are progressively merged into an overall model.


Feature‐Driven Development (FDD)• 2. Build Feature List – Knowledge from initial

modeling is used to identify the list of features by functionally decomposing the domain into subject areas.– Subject areas each contain business activities.

– Steps within each business activity form the basis for a categorized feature list.

– Features in this respect are small pieces of client‐valued functions expressed in the form “<action><result><object>”

– Features should not take more than two weeks to complete.


79

80

Feature‐Driven Development (FDD)• 3. Plan by Feature – In this step, a development plan is

created where ownership of features, or feature sets are assigned as classes to specific programmers.

• 4. Design by Feature – The Chief Programmer selects a small group of features to be developed in the next two weeks.

– A Design Package is produced for each feature.

– Detailed Sequence Diagrams for each feature are produced.

– Class & Method Prologues are written.

– The Design Inspection is held.v. 10.2 ‐ © Copyright and all rights reserved – 2020


Feature‐Driven Development (FDD)• 5. Build by Feature

– The class owners develop the code for their classes.

– Unit tests are conducted on the code.

– Code inspection is conducted.

– The feature is promoted to the main build.

• Return to step 3 and repeat the process.


81

82

Feature‐Driven Development (FDD)• Domain Object Modeling – The team explores & explains the domain of

the problem.

• Developing by Feature – Break the functions down into two‐week or shorter chunks & calling them features.

• Individual Class Ownership – Areas of code have a single owner (different from XP).

• Feature Teams – Small dynamically formed teams that vet designs & allow multiple designs to be evaluated.

• Inspections – Reviews that help ensure good‐quality design & code.

• Configuration Management – Labeling code, tracking changes, & managing source code.

• Regular Builds – Make sure new code integrates with existing.

• Visibility of Progress & Results – Track progress based on completed work.


Feature Driven Development (FDD)

Scrum• No formal process.

• No model requirements.

• Product Backlog

• Release plan provides initial view of when PBIs delivered.

• Entire process is iterative

FDD• Five specific steps.

• Creates overall model 1st

thing that is not working software.

• Feature List

• Plan by feature

• Only the last three (3) steps are iterative.


83

84

Dynamic Systems Development (DSDM)

• 1994 in order to add discipline to RAD.

• Designed to be compatible with ISO 9000 & Prince2

• Is iterative & incremental

• Fixes cost, quality & time at project outset.

• 2007 rebranded DSDM Atern.

• 2014 went back to just DSDM.

• Often used to provide overall project framework in conjunction with Scrum.


Dynamic Systems Development Method


Pizza & Cheese Diagram

85

86


Prerequisites for Using DSDM• Acceptance of the Atern philosophy before starting work.• Appropriate empowerment of the Solution Development

Team.• Commitment of senior business management to provide

the necessary Business Ambassador involvement.• Incremental delivery.• Access by the Solution Development Team to business

roles.• Solution Development Team stability.• Solution Development Team skills.• Solution Development Team size.• A supportive commercial relationship.


DSDM – Atern Philosophy


Any product must be aligned to clearly defined strategic goals & focus upon early delivery of real benefits to the business. This is best achieved when key stakeholders understand the business objectives, are empowered to an appropriate level & collaborate in order to deliver the right solution. The solution will be delivered in the agreed timescale, according to the priorities set by the business. The stakeholders must be prepared to deliver a fit‐for‐purpose solution. They must also be prepared to accept that change is inevitable as they understand more about the solution being developed.

87

88



ProjectManager

TeamLeader

BusinessVisionary

TechnicalCoordinator

BusinessSponsor

SolutionDeveloper(s)

SolutionTester(s)

BusinessAmbassador(s)

BusinessAnalyst(s)

BusinessAdvisor(s)

WorkshopFacilitator

AternCoach

Pro

ject

Solu

tion D

evelo

pm

ent

Oth

er

The Atern Team Model

Dynamic Systems Development MethodDSDM Eight Principles

• Focus on the business need.• Deliver on time.• Collaborate.• Never compromise quality.• Build incrementally from firm foundations.• Develop iteratively.• Communicate continuously & clearly.• Demonstrate control.


89

90


1. Focus on the Business Need• The main acceptance criteria is delivering

something that addresses the defined business need.– Clearly define the scope of the system.

– Understand the true business priorities.

– Establish a sound business case.

– Seek continuous business sponsorship & commitment.

– Guarantee the minimum usable subset of features.



2. Deliver on Time• Timebox the work.

• Focus on business priorities.

• Always meet deadlines.


91

92


3. Collaborate• Decisions must be made with users and

developers working together quickly.– Involve the right stakeholders, at the right time,

throughout the project.

– Ensure that the members of the team are empowered to make decisions on behalf of those they represent without waiting for higher‐level approval.

– Actively involve the business representatives.

– Build a one‐team culture.



4. Never Compromise Quality• Set the level of quality at the beginning.

• Ensure that quality does NOT become a variable.

• Design, document, & test appropriately.

• Build in quality by constant review.

• Test early & continuously.


93

94

Dynamic Systems Development Method5. Build Incrementally from Firm

Foundations• Strive for early delivery of business benefit

where possible.

• Continually confirm the correct solution is being built.

• Formally re‐assess priorities & ongoing project viability with each delivered increment.



6. Develop Iteratively• Focus on frequent delivery of products, with

assumption that to deliver something “good enough” earlier is always better than to deliver everything “perfectly” in the end. – Do enough design up front to create strong foundations.– Take an iterative approach to building all products.– Build customer feedback into each iteration to converge on

an effective business solution.– Accept that most detail emerges later rather than sooner.– Embrace change – the right solution will not evolve

without it.– Be creative, experiment, learn, evolve.


95

96


7. Communicate Continuously & Clearly• Communication & cooperation among all project

stakeholders is required to be efficient & effective.– Run daily team stand‐up sessions.

– Use facilitated workshops.

– Use rich communication techniques such as modelling & prototyping.

– Present iterations of the evolving solution early & often.

– Keep documentation lean & timely.

– Manage stakeholder expectations throughout the project.

– Encourage informal, face‐to‐face communication at all levels.



8. Demonstrate Control• Use an appropriate level of formality for

tracking & reporting.

• Make plans & progress visible to all.

• Measure progress through focus on delivery of products rather than completed activities.

• Manage proactively.

• Evaluate continuing project viability based on the business objectives.


97

98

Crystal Overview• An entire family of methodologies.

• Developed by Alistair Cockburn in mid‐1990s.

• Based on observations of successful teams that did not follow formal methodologies.

• Avoids strict or rigid processes found in other methodologies.


Crystal

Cockburn Differentiated Between…

• Methodologies – Sets of elements (e.g. practices or tools).

• Techniques – Skill areas (e.g. developing Use Cases).

• Policies – Dictate organizational musts.


99

100

Crystal

Crystal Methods Focus on…

• People

• Interaction

• Community

• Skills

• Talents

• Communications


Crystal• Versions scale according to team size.• The color denotes the weight:• Crystal Clear ‐ 2‐6 people• Crystal Yellow – 7 – 20 people• Crystal Orange – 10 – 40 people• Crystal Orange Web• Crystal Red ‐ up to 80 people• Crystal Maroon• Crystal Diamond• Crystal Sapphire


Lightweight, not mission critical

Heavy, mission critical

101

102

CrystalCommon Crystal 7 Properties

• Frequent delivery

• Reflective improvement

• Close or osmotic communication

• Personal safety

• Focus

• Easy access to expert users

• Automated tests, configuration management, frequent integration


CrystalFrequent Delivery

• Software released in iterations weekly or quarterly.

• Possible to have multiple iterations per release.

• Problems found and fixed early on.

• Customers get to ensure the project is going the way they want it to go.


103

104

CrystalReflective Improvement

• Developers dedicate time to improving the development process.

• Reflection workshops are held every few weeks to help find processes that are working & which ones need to be modified.

• Iteration helps determine if a process is working or not.


Crystal

Close or Osmotic Communication

• Development teams MUST be in the same room.

– Developers do not need to break concentration to move somewhere else.

– Information flows quickly through the team.

– Communication overhead is reduced.


105

106

CrystalPersonal Safety

• Team members must be able to speak freely in a group without being ridiculed.

Focus• Focus on a task long enough for progress to be

made.– 2 hour periods where the developers have no

interruptions.

– Developer assigned to a project for at least 2 complete days.

• Clear definition and goals of the project.v. 10.2 ‐ © Copyright and all rights reserved – 2020


Crystal

Easy Access to Expert Users• Developers work with experts in the field of

the project who will also be end‐users.

• Expert will answer questions and suggest solutions or improvements.

• Minimum: meet once a week for 2 hours and be reachable by phone.


107

108

Crystal

Automated Tests, Configuration Management Frequent Integration

• Spot errors and problems that arise from changes being made.

• Done regularly

– Problems spotted early on.

– Problems are less likely to grow.


Lean Software Development (LSD)

1. Eliminate Waste

2. Amplify Learning

3. Defer Decisions

4. Deliver as fast as

possible

5. Empower the Team

6. Build Integrity In

7. See the Whole


1. Eliminate WasteYou must first recognize waste before eliminating it.• Unnecessary code and functionality.• Delay in the software development process.• Unclear requirements.• Avoidable process repetition (often caused by insufficient testing).• Bureaucracy.• Slow internal communication.

2. Amplify Learning• The accumulation of defects is prevented by running tests as soon

as the code is written.• More time is spent trying new ideas than writing documentation.• Mockups and prototypes are regularly presented to the customer

to gather requirements.• The use of short iterations is key and done in conjunction with

refactoring and integration testing.• Set‐based development concentrates on communicating the

constraints of the future solution and not the possible solution promoting the solution birth via dialogue with the customer.

3. Decide as Late as PossibleThe best results are achieved with an options‐based approach using facts instead of assumptions or predictions.• Planning focus is on the different options and adapting to the

current situation.• Planning focus includes clarifying confusing situations and

establishing rapid action patterns.• The team must decision options as soon as information is

available.

4. Deliver as Fast as PossibleTo survive you often must be the fastest. The sooner a product is delivered without major defects, the faster customer feedback is obtained and incorporated into the next iteration.• Customers value rapid delivery of quality products.• The JIT ideology applies to software development.• The customer provides stories based on need, the developer

estimates time by story.• This changes the organization into a self‐pulling system.

5. Empower the TeamThe most effective teams use a Work‐Out Technique when the managers do NOT tell workers how to do their job.• Find good people and let them do their own job.• Encourage progress, catching errors, and removing impediments.• Discourage micro management.• People are more than just resources. They require motivation and

a higher purpose.• The developer should be given access to the customer.

6. Build Quality In• The customer needs to have an overall experience of the system.

This is called perceived integrity. How it is being advertised, delivered, deployed, accessed, how intuitive is it to use, what is its price, and how well does it solve problems.

• Conceptual integrity means the system’s separate components work well together as a whole with balance between flexibility, maintainability, efficiency and responsiveness.

• Refactoring is about keeping simplicity, clarity, minimum amounts of features in the code.

• Integrity is verified through testing to ensure the system does what the customer expects.

7. See the WholeSoftware systems are a product of their interactions and not just a sum of parts.• Defects accumulate during the development process.• By decomposing big tasks into smaller ones and standardizing the

stages of development defect root causes can be found and eliminated.

• Think big, act small, fail fast, learn rapidly.

109

110

Lean Software Development (LSD)Key Tools & Concepts

• Translation of Lean Manufacturing to IT.• Originated by Mary & Tom Poppendieck.• Pull Systems ‐ Kanban• Queuing Theory ‐ The mathematical study of waiting

lines, or queues. In queueing theory a model is constructed so that queue lengths and waiting time can be predicted.

• Value Stream Mapping• Set‐Based Development• Seeing Waste • Motivation• Measurements


Lean Software Development (LSD)Seven Wastes (TIMWOOD)

• Transportation – Each time a product is moved it stands the risk of being damaged, lost, or delayed.

• Inventory – Raw materials, WIP, or finished goods represent capital outlays that have not yet produced an income.

• Motion – Refers to the damage that the production process inflicts on the entity that creates the product.

• Waiting – Whenever goods are not in transport or being processed, they are waiting.

• Over‐Processing – Occurs any time more work is done on a piece than is required by the customer.

• Over‐Production – Occurs when more product is produced than is required at a time by the customer.

• Defects – Whenever they occur, extra costs are incurred reworking the part, rescheduling production, etc.


111

112

Kanban

• Means signboard in Japanese.

• It is a scheduling system used in Lean Production to improve the JIT flow.

• Kanban limits WIP by defining the maximum number of stories to be worked at a time.

• Typically, it uses a series of columns showing value being added to work flowing left to right.


Kanban• Best used when a team or organization is in need

of:– Flexibility – The team is NOT bound by timeboxed and

will work on the highest priority item in the backlog.

– Focus on continuous delivery – Teams are focused on flowing work through the system to completion and NOT beginning new work until WIP is completed.

– Increased productivity and quality – Both factors are improved by limited WIP.

– Increased efficiency – Checking each task for value added or non‐value added activities and remove all non‐value added activities.


113

114

Kanban• Best used when a team or organization is in

need of:

– Team member focus – Limiting WIP allows the team to focus on the current work.

– Variability in workload – When there is unpredictability in the way work arrives teams cannot make predictable commitments therefore it becomes critical to manage WIP.

– Reduction in waste – Transparency makes waste visible so it can be removed.


Kanban

• It’s a pull system to take work when capacity is available instead of pushing work.

• Taiichi Ohno developed Kanban at Toyota in 1953.

• Best book is KANBAN – Successful Evolutionary Change for Your Technology Business by David J. Andersson.


115

116

Kanban

Five Core Principles of Kanban• Visualize the Workflow – Have some way to

visualize the workflow.

• Limit WIP – Keep the amount of WIP low.

• Manage Flow – Track the flow through the system.

• Make Process Policies Explicit

• Improve Collaboratively


Task/Kanban Board

BacklogSelected

(5 Max) Ongoing DoneAcceptance

(5 Max)

Deploy(15 Max)

Develop (3 Max)

Story

Story

Story

Story

Story

Story

Story

Story

Story

Story

Story

Story

Story

Story Story

Story

Story

Story

Story

Story

Story


117

118

Scrum vs. KanbanScrum

• Scrum Boards reset before each sprint.

• Scrum Boards typically have To‐Do, In Progress, Validate, Impeded & Done.

• Scrum Boards change infrequently.

Kanban• Kanban doesn’t use

timeboxed iterations (sprints) so it uses a continuous flow of work with new work added when there is capacity.

• Kanban Boards tend to have more columns.

• Kanban Boards change frequently.


Teams often start with Scrum and add Kanban which leads to them not doing Scrum “by the book” any longer.

Test Your Assumption• You must know which methodology is best for which

situation:– Scrum as a basic Agile starting point.– XP is ruthless in testing.– FDD offers robust & specific modeling techniques– DSDM offers suitability filters for how well a process fits a

project.– Crystal works on projects of different sizes & complexities.– Kanban for modification & adaptation.– Cockburn’s Shu‐Ha‐Ri Model

• Shu ‐ Obey the rules • Ha ‐ Consciously move away from the rules• Ri ‐ Unconsciously find your own path

• Critical to align team size & methodology• Project visibility


119

120

Scaling Agile• Most Agile life cycles are designed for small

teams and projects.

• Several techniques are available to scale Agile:

– Scaled Agile Framework (SAFe)

– Nexus

– Large Scale Scrum (LeSS)

– Disciplined Agile Delivery (DAD)


SAFe 5.0



121

122

SAFe 5.0 What’s New?



SAFe 5.0

Level I ‐ Portfolio• Strategic themes connect portfolio or

organizational strategic objectives.

• Budgeting for each ART or Program done at this level.

• Epics are created to fund cross ART training or deliverables.

• Use Kanban system at this level to represent ARTs.



123

124

SAFe 5.0Level II ‐ Program

• 50 – 125 people called an Agile Release Train (ART) is the specific program. If team misses one train they can catch the next one.

• Program Increment (PI) are the time boxed increments.• Each PI is 5 iterations by default. 4 are focused on the backlog,

1 is PI Iteration for Planning. This is used to deal with the unexpected or creative. Run Inspect and Adapt Workshop where the team works to improve process.

• Has a separate program backlog that represents larger features that are broken down to create the team backlog. Owned by Product Manager.

• Guided by a Release Train Engineer (RTE) is program manager.• Train System Architect facilitates process of developing

infrastructure for future PIs.125

v. 10.2 ‐ © Copyright and all rights reserved – 2020 Looking Glass Development, LLC.

SAFe 5.0SAFe Core Values

• Alignment ‐ Communicate the mission by establishing and expressing the strategy and vision. Provide relevant briefings and participate in Program Increment (PI) planning and backlog review and preparation.

• Build‐in Quality ‐ Demonstrate commitment to quality by refusing to accept or ship low quality work. Support investments in capacity planning to maintain and reduce technical debt.

• Transparency ‐ Visualize all relevant work. Take ownership and responsibility for errors and mistakes. Admit missteps and support others who acknowledge and learn from theirs. Never punish the messenger; instead, celebrate learning.

• Code Quality ‐ Many leaders participate specifically as Business Owners in prioritization, PI execution, and reflection. All leaders help adjust scope to assure demand matches capacity. They aggressively remove impediments and demotivators.



125

126

SAFe 5.07 Competencies of a Lean Enterprise

• Lean Agile Leadership ‐ Advancing and applying Lean‐Agile leadership skills that drive and sustain organizational change by empowering individuals and teams to reach their highest potential

• Team & Technical Agility ‐ Driving team Agile behaviors as well as sound technical practices including Built‐in Quality, Behavior‐Driven Development (BDD), Agile testing, Test‐Driven Development (TDD), and more.

• Agile Product Delivery – Building high‐performing teams‐of‐teams that use design thinking and customer‐centricity to provide a continuous flow of valuable products using DevOps, the Continuous Delivery Pipeline, and Release on Demand.



SAFe 5.07 Competencies of a Lean Enterprise

• Enterprise Solution Delivery – Building and sustaining the world’s largest software applications, networks, and cyber‐physical solutions.

• Lean Portfolio Management – Executing portfolio vision and strategy formulation, chartering portfolios, creating the Vision, Lean budgets and Guardrails, as well as portfolio prioritization, and roadmapping.

• Organizational Agility – Aligning strategy and execution by applying Lean and systems thinking approaches to strategy and investment funding, Agile portfolio operations, and governance.



127

128

SAFe 5.0

7 Competencies of a Lean Enterprise• Continuous Learning Culture – Continually

increasing knowledge, competence, and performance by becoming a learning organization committed to relentless improvement and innovation.



SAFe 5.0

130

SAFe House of Leanv. 10.2 ‐ © Copyright and all rights reserved – 2020


129

130

SAFe 5.0



SAFe 5.0



131

132

SAFe 5.0SAFe Configurations

• Essential SAFe is the basic building block for all other

SAFe configurations and is the simplest starting point for implementation. It brings the core competencies of Lean‐Agile Leadership, Team and Technical Agility, and DevOps and Release on Demand to the enterprise.




• Large Solution SAFe brings the Business Solutions and

Lean Systems Engineering competency to those building the largest and most complex solutions. This configuration supports multiple Agile Release Trains (ARTs) and suppliers.



133

134


• Portfolio SAFe applies the Lean Portfolio Management

competency to align portfolio execution to the enterprise strategy, and organizes development around the flow of value through one or more value streams.




• Full SAFe is the most comprehensive version that

integrates all five core competencies to support enterprises that build and maintain a portfolio of large, integrated solutions.



135

136

SAFe 5.0



SAFe 5.0

Level III Team

• Uses Kanban, Scrum or Scrumban.

• 2 week iterations.

• Not every sprint produces a potentially shippable increment.

• Changes some terms which Schwaber and others don’t like.



137

138

Nexus

What is Nexus?• Nexus – Is a unit of development in Scaled

Professional Scrum.

• Nexus – Is also a framework consisting of roles, events, artifacts, and techniques that bind the work of 3 to 9 Scrum teams.

• Nexus – Is an exoskeleton that rests on top of multiple Scrum teams to create an Integrated Increment.


Nexus


139

140

Nexus

Nexus Consists of…• Roles are the same as Scrum.

• Adds one new role the Nexus Integration Team:

– Product Owner(s)

– Scrum Master(s)

– Nexus Integration Team Members


NexusNexus Process Flow

• All Scrum teams use the same, single product backlog.

• Refine the product backlog.• Nexus Sprint planning

– Backlog items reviewed– PBIs assigned to teams & they create their Sprint

backlog.– Each Scrum team plans its own sprint.– Teams align sprint goal(s) to Nexus goal(s).

• Team develops features.


141

142

Nexus

Nexus Process Flow• Nexus Daily Scrum:

– Was the previous day’s work successfully integrated? If not, why?

– What new dependencies have identified?

– What information needs to be shared across teams in the Nexus.

– Each team then holds its own Daily Scrum.


Nexus

Nexus Process Flow• Nexus Sprint Review – All teams meet with

Product Owner to review the integrated increment. Adjustments may be made to the backlog.

• Nexus Sprint Retrospective– Shared challenges are discussed.

– Each team holds its own retrospective.

– Teams meet & agree on how to visualize & track the identified actions.


143

144

Nexus

Each Retrospective Should…• Was any work left undone? Did the Nexus

generate technical debt?

• Were all artifacts, particularly code, frequently (as often as every day) successfully integrated?

• Was the software successfully built, tested, & deployed often enough to prevent the overwhelming accumulation of unresolved dependencies?


Nexus

Refinement Meetings• The greater the complexity & dependencies,

the more the Product Backlog items must be refined to remove dependencies.

• Helps to forecast which team will deliver each item.

• Identifies dependencies across teams.


145

146

LeSS

Overview• Large‐scale Scrum is regular Scrum applied to

large‐scale development.

• Created by Craig Larman and Bas Vodde.

• There are two frameworks depending on project size:

– Framework 1 – Projects up to 10 teams.

– Framework 2 – Larger projects.

• Is an organizational design framework.v. 10.2 ‐ © Copyright and all rights reserved – 2020


LeSSLeSS / Scrum Commonalities

• A single Product Backlog (because it’s for a product, not a team).

• One Definition of Done for all teams.

• One Potentially Shippable Product Increment at the end of each Sprint.

• One Product Owner.

• Many complete, cross‐functional teams (with no single‐specialist teams).

• One Sprint.


147

148

LeSSLeSS / Scrum Differences

• Sprint Planning Part 1: In addition to the one PO, it includes people from all teams. Let team members self‐manage to decide their division of Product Backlog Items. Team members also discuss opportunities to find shared work and cooperate.

• Sprint Planning Part 2: Held independently (and usually in parallel) by each Team, though sometimes for simple coordination and learning two or more Teams may hold it in the same room.

• Daily Scrum: This is also held independently by each Team, though a member of Team A may observe Team B’s Daily Scrum, to increase information sharing.

• Overall PBR: There may be an optional and short overall Product Backlog Refinement (PBR) meeting that includes the one PO and people from all teams. Purpose is to decide which teams are likely to implement which items and therefore select those items for later in‐depth single‐team PBR. It is also a chance to increase alignment with the Product Owner and all teams.


LeSSLeSS / Scrum Differences

• Product Backlog Refinement: The only requirement in LeSS is single‐team PBR, the same as in one‐team Scrum. But a common and useful variation is multi‐team PBR, where two or more Teams are in the same room together, to increase learning and coordination.

• Sprint Review: In addition to the one Product Owner, it includes people from all teams, and relevant customers/users and other stakeholders. For the phase of inspecting the product increment and new items, consider a “bazaar” or “science fair” style: a large room with multiple areas, each staffed by team members, where the items developed by teams are shown and discussed.

• Overall Retrospective: This is a new meeting not found in one‐team Scrum, and its purpose is to explore improving the overall system, rather than focusing on one Team. The maximum duration is 45 minutes per week of Sprint. It includes the Product Owner, Scrum Masters, and rotating representatives from each Team.


149

150

Disciplined Agile DevelopmentOverview

• A people‐first, learning‐oriented, hybrid agile approach to IT solution delivery.

• Makes use of Scrum, Agile Modeling, XP, UP, Kanban, Lean Software Development, Outside In Development & others.

• Looks at full, end‐to‐end delivery life cycle from project initiation to solution delivery.

• Provides technical practice advice like XP as well as modeling, documentation, & governance.

• Less prescriptive than Scrum by being more goal‐driven. Provides significant advice & alternatives.


Disciplined Agile Development

Overview• Draws from Unified Process (UP).

• Projects divided into three phases:

– Inception

– Construction

– Transition

• Scott Ambler creator

• Now Part of PMI®


151

152

Disciplined Agile Development7 Principles of DAD


Delight Customers

Be Awesome

Pragmatism

Context Counts

Choice is Good

Optimize Flow

Enterprise Awareness

Disciplined Agile DevelopmentThe Backlog

• Go beyond functional requirements. Teams often must complete non‐requirement related work such as take training, review products of other teams, address defects. These need to be on the backlog.

• Take a risk‐value approach. Common risks include the need to come to stakeholder consensus early in the project, or the need to prove that your architecture strategy, actually works. DAD teams look at their work item stack early in the project, typically during the Inception or Iteration 0 to identify requirements which exhibit these technically risky features.


153

154


The Backlog• Model a bit ahead. What if a work item is very

complex, requiring a bit more thinking that what generally occurs in an iteration planning session? DAD teams adopt the Look‐Ahead Modeling practice and look ahead an iteration or two and invest the time to explore complex upcoming items to reduce the overall project risk. Modeling a bit ahead is called backlog grooming in Scrum.



Lifecycle Versions• Agile/Basic – Based on Scrum, but extended to

provide a streamlined strategy from beginning to end.

• Lean/Advanced – Based on Kanban.

• Continuous Delivery – Stable team based on Kanban and Lean.

• Exploratory/Lean Startup – Base on Lean Startup strategies


155

156


Primary Roles:

• Team Lead

• Product Owner

• Architecture Owner

• Team Member

• Stakeholder

Primary roles occur on all DAD projects regardless of scale.

Secondary Roles

• Specialist

• Independent Tester

• Domain Expert

• Technical Expert

• Integrator

Secondary roles only occur at scale & sometimes are only temporary.


Roles

T

e

a

m


DAD vs. Scrum• DAD places more emphasis on architecture &

technical risk reduction.

• Adds the role of Architecture Owner.

• Changes names in Scrum such as Scrum Master becoming Team Lead.

• Is far less prescriptive


157

158




DAD vs. ScrumBlades


159

160


Scrum of Scrums• Many scrum teams working on the same

project.

• Each team identifies one person who attends the scrum of scrum meeting.

• Meeting designed to coordinate the work.


PMOsProject Management Office (PMO) —Centralizes the management of projects. Typical 3 structures:

Supportive – Providing a consultative role by providing templates, best practices, training, access to information, & lessons learned.Controlling – Provide support & require compliance.Directive – Take control of the projects by directly

managing the projects.

An Agile PMO is value‐driven based on a customer collaboration mindset and is invitation‐oriented.


161

162

PMOsOften, Agile PMOs become centers of excellence providing:Development and implementation of

standards.Training, mentoring and organizational

learning.Multi‐project management.Stakeholder managementRecruiting, selecting, and evaluating team

leaders.Executing specialized tasks for projects.


Organizational Structure


Differentiation vs. IntegrationThe need for specialized areas ofexpertise (Production,Marketing, Finance, etc.). Thelevel of differentiationhinges on the needs of theorganization.

The need for coordinated andcross-functional efforts to accomplish organizational tasks.

163

164

Organizational StructureMany factors influence structure including:

Geography

Size of project deliverables

Allocation of people to projects

Procurement‐heavy organizations


Organizational Structure


Weak Matrix

Balanced Matrix

Strong Matrix

165

166

Value‐Driven Delivery

Value‐Driven DeliveryDomain Tasks – Define Positive Value

1. Define deliverables by identifying units that can be produced incrementally in order to maximize their value to stakeholders while minimizing non‐value added work.

2. Refine requirements by gaining consensus on the acceptance criteria for features on a just‐in‐time basis in order to deliver value.

3. Select & tailor the team’s process based on project & organizational characteristics as well as team experience in order to optimize value delivery.


Domain Tasks – Avoid Potential Downsides4. Plan for small releasable increments by organizing requirements into minimally marketable

features/minimally viable products in order to allow for the early recognition & delivery of value.

5. Limit increment size & increase review frequency with appropriate stakeholders in order to identify & respond to risks early on & at minimal cost.

6. Solicit customer & user feedback by reviewing increments often in order to confirm & enhance business value.

167

168

Value‐Driven DeliveryDomain Tasks – Prioritization

7. Prioritize the units of work through collaboration with stakeholders in order to optimize the value of the deliverables.

8. Perform frequent review & maintenance of the work results by prioritizing & maintaining internal quality in order to reduce the overall cost of incremental development.

9. Continuously identify & prioritize the environmental, operational, & infrastructure factors in order to improve the quality & value of the deliverables.


Domain Tasks – Incremental Development10. Conduct operational reviews &/or periodic checkpoints with stakeholders in order to obtain feedback &

corrections to the work in progress & planned work.

11. Balance development of deliverable units & risk reduction efforts by incorporating both value producing & risk reducing work into the backlog in order to maximize the total value proposition over time.

12. Re‐prioritize requirements periodically in order to reflect changes in the environment & stakeholder needs or preferences in order to maximize the value.

13. Elicit & prioritize relevant non‐functional requirements (such as operations & security) by considering the environment in which the solution will be used in order to minimize the probability of failure.

14. Conduct frequent reviews of work products by performing inspections, reviews, &/or testing in order to identify & incorporate improvements into the overall process & product or service.

Value‐Driven Delivery• Value‐Driven Delivery – Focusing on delivering real business value. The

most important features first.

• Consider technical dependencies & risks.

• Common mantra in Agile.

• Even safety and regulatory compliance projects can be expressed in terms of business value by considering the business risk and impact of not undertaking them.

• If value then is the reason for doing projects, value driven delivery is the focus of the project throughout the project planning, execution, and control processes.

• It is the big picture view, the wearing of the sponsor’s hat when making decisions. By assuming this viewpoint, there is an opportunity to incorporate unique technical insights, such as technical dependencies or risk reduction steps, into the selection of features for a release that the sponsor may not be aware of.


169

170

Value‐Driven DeliveryAssessing Value

• Focus on when to use these tools

• Payback Period

• Return on Investment (ROI)

• Benefit / Cost ratio (BCR or BCI)

• Future Value

• Present Value

• Net Present Value (NPV)

• Internal Rate of Return (IRR)


Value‐Drive DeliveryAssessing Value

Discounting or Present Value – Value today of funds available in the future.

PV = FV / (1 + i)n

– If you want $1,000 in three (3) years how much do you have to invest today at 8% to receive your $1,000?

– End of Yr. 1 = $1,000 / (1 + 8%) = $925.93– End of Yr. 2 = $925.93 / (1 + 8%) = $857.34– End of Yr. 3 = $857.34 / (1 + 8%) = $793.83– Project Costs: $500– $793.83 ‐ $500 = $293.83 = NPV


171

172


Assessing Value• Net Present Value – Present Value minus

Present Cost.

• Internal Rate of Return ‐ Average rate of return earned over the life of the project. It is where NPV = 0.



Planning Value• Chartering

– Exists in Agile projects.

– Focused on what not how.

– Shorter document, typically one page.


173

174

Value‐Driven DeliveryValue Stream Mapping

• Lean Manufacturing technique• Uses visual maps of process• 6 Step process:

1. Identify the product or service that you are analyzing.2. Create a value stream map of the current process, identifying

steps, queues, delays, & information flows.3. Review the map to find delays, waste & constraints.4. Create a new value stream map of the desired future state of

the process, optimized to remove or reduce delays, waste & constraints.

5. Develop a roadmap for creating the optimized state.6. Plan to revisit the process in the future to continually improve.


Value‐Driven DeliveryValue Stream Mapping

YouYou & friend

eat cake

YouYou & friend

eat cakeCake

selectionBakery counter

Checkout lineUnpack &

slice

YouYou & friend

eat cakeCake



slice

Bakers Sales

YouYou & friend

eat cakeCake



slice

Bakers Sales

Value Add

Nonvalue Add 15 minutes

1 minute

4 minutes 6 minutes

2 minutes 2 minutes 2 minutes 10 minutes

5 minutes


175

176


Value Stream Mapping• Total Cycle Time = Value Added Time + Non‐Value

Added Time

• TCT = (1+2+2+2+10) + (4+6+15+5) = 47 Minutes

• Process Cycle Efficiency =

• PCE = = 36%

Total Value Added TimeTotal Cycle Time

1747



• Calculate the process cycle efficiency for each row. NonValue Add Value Add Total Time Efficiency

11 4

10 6

8 7

3 8

5 9

7 12

9 10

9 5

4 13


177

178


• Calculate the process cycle efficiency for each row. NonValue Add Value Add Total Time Efficiency

11 4 15 27%

10 6 16 38%

8 7 15 47%

3 8 11 73%

5 9 14 64%

7 12 19 63%

9 10 19 53%

9 5 14 36%

4 13 17 76%


Value‐Driven Delivery• Poppendieck’s 7 Lean Wastes Manufacturing

to Software.Waste Description Example

Partially Done Work Work started, but not completed; partially done work can entropy

• Code waiting for testing• Specs waiting for development

Extra Processes Extra work that does not add value • Unused documentation• Unnecessary approvals

Extra Features Features that are not required, or are thought of as “nice‐to‐haves”

• Gold‐plating• Technology features

Task Switching Multitasking between several different projects when there are context‐switching penalties

• People on multiple projects

Waiting Delays waiting for reviews and approvals • Waiting for prototype reviews• Waiting for document

approvals

Motion The effort required to communicate or move information or deliverables from one group to another; if teams are not co‐located, this effort may need to be greater

• Distributed teams• Handoffs

Defects Defective documents or software that needs correction • Requirements defects• Software bugs


179

180


• Customer‐valued prioritization

– Working on the things that yield the greatest return for the customer.

– Scrum = Product Backlog

– FDD = Feature list

– DSDM = Prioritized Requirements List


Value‐Driven Delivery• MoSCoW Prioritization Schemes

• Monopoly Money = to total project budget

• 100 Point Method – Used with Use Cases from Leffingwell & Widrig

• Kano Analysis – Customer satisfaction & product development theory developed in the 1984 by Professor Noriaki Kano designed to classify customer preferences into three categories.


181

182

Value‐Driven DeliveryKano Analysis

• Performance Needs – These requirements can both satisfy & dissatisfy customers. They are at the top of the customers’ mind. Customers will also talk about them readily when asked what is important. You must choose the correct ones of these.

• Basic Needs – Having these requirements will NOT result in customer satisfaction, but NOT having them will result in dissatisfaction. Customers don’t give these items a thought unless they are absent. They are sometimes referred to as MUST HAVES.

• Excitement Needs – Customers are delighted when these are delivered, but their absence doesn’t cause dissatisfaction. They are often called UNIQUE SELLING or VALUE PROPOSITIONS.


Value‐Driven DeliveryKano Analysis


183

184


• Requirements Prioritization Model– By Karl Wiegers– Measures benefit, penalty, cost & risk of each feature.– Scores from 1 to 9

• Relative Prioritization ‐ A simple list removes the categories that people tend to fixate on from the debate and allows the focus of the discussion to be on priorities. It also provides a framework for deciding if and when to incorporate changes. When change is requested, the team can ask the business representatives, "What items are more important than this change?"


Value‐Driven DeliveryProduct Roadmaps

• A high level, strategic plan that supports the purpose and vision of the product.

• Is used to align stakeholders and keep them aligned.

• Roadmaps fall into two categories: Feature‐Based & Goal‐Oriented.– Goal Oriented Roadmap

– Now‐Next‐Later Roadmap

– Storymap


185

186

Value‐Driven DeliveryGoal‐Oriented Roadmaps

• Focuses on the goals or benefits of the product.

• Goals are expressed in terms of the business: increasing revenue, decreasing costs, increasing users, etc.


Time

Release #1Release Goal 1.A‐ Feature / User Story 1.A.1‐ Feature / User Story 1.A.2‐ Feature / User Story 1.A.3

Release Goal 1.B‐ Feature / User Story 1.B.1‐ Feature / User Story 1.B.2





Value‐Driven DeliveryGO Product Roadmaps


DateThe release date or timeframe

Date or timeframe

Date or timeframe

Date or timeframe

Date or timeframe

Release NameThe name of the new release

Name/version Name/version Name/version Name/version

GoalThe reason for creating the new release

Goal Goal Goal Goal

FeaturesThe high‐level features necessary to meet the goal

Features Features Features Features

MetricsThe metrics to determine if the goal has been met

Metrics Metrics Metrics Metrics

187

188

Value‐Driven DeliveryNow‐Next‐Later ‐Roadmaps


Now Next Later

Release 1

Release 2

Release 3

Iteration 1‐ Story 1‐ Story 2‐ Story 3



Iteration 4‐ Story 1‐ Story 2‐ Story 3 Iteration 5

‐ Story 1‐ Story 2‐ Story 3



Iteration 8‐ Story 1‐ Story 2‐ Story 3 Iteration 9

‐ Story 1‐ Story 2‐ Story 3




Now Next Later

Story 1

Story 2

Story 3

Story 4

Story 5

Story 6

Story 7

Story 8

Story 9

Story 10

Story 11

Story 12

Story 13

Story 14

Extend user time within application.Improve the user experience.Add users to platform.

Value‐Driven DeliveryA Sample Story Map


Epic 1

Sequence

TheBackbone

WalkingSkeleton

LessOptional

MoreOptional

Op

tio

nal

ity

Story

Story

StoryStory

StoryStory

StoryStory

Story

Story

Story

StoryStory Story

Story Story

Story Story

Story Story

Story Story

Story Story

Story

Story

Story

Story

Story

Story

Story

Story

Story

Story

Story

StoryStory

StoryStory

Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5 Sprint 6 Sprint 7 Sprint 8 Sprint 9

Release 1 Release 2 Release 3

Story

Epic 2 Epic 3 Epic 4 Epic 5 Epic 6 Epic 7 Epic 8 Epic 9

189

190

Value‐Driven Delivery• Risk – An uncertain event or condition that, if

realized, has a positive or negative impact on at least one project objective (such as schedule, cost, scope or quality).

• Risks can have one or more causes and one or more impacts.

• Negative risks are anti‐value.

Planning Process Group

11. Project Risk Management

11.1Plan Risk

Management

11.3Perform

QualitativeRisk Analysis

11.2Identify Risks

11.4Perform

QuantitativeRisk Analysis

11.5Plan Risk

Responses



Major Risk Classes• Known Risks ‐ Can be analyzed, possible to

plan. Contingency reserve or other plans.

• Unknown Risks ‐ Cannot be managed proactively. General contingency or management reserve.


191

192


Agile Helps Mitigate Risks• Schedule Risks ‐ In a linear model it can be a long

time before a product is ready for release. In Agile this can be shorter, sometimes a few weeks.

• Budget Risks – Agile estimates are no more accurate, but it is easier to manage.

• Cancellation Risk – Linear model projects tend to be cancelled late. An Agile project produces functionality quickly so the project can be cancelled.



Agile Helps Mitigate Risks• Scope Creep – In linear model projects scope is

added without any being removed. The backlog forces hard decisions.

• Requirements Error – Linear model projects specify requirements long before they are delivered. An incorrect requirement can generate significant effort before the error is discovered.

• Technology Risks – Many projects require unproven technologies. A linear model extends the time it takes to discover failed tech. Agile allows for rapid discovery.


193

194


Agile Helps Mitigate Risks• Security Risks – Linear model projects often take

significant time before system security can be tested. Agile projects test security quickly, often and at regular intervals.



Plan

CheckAct

Do

Successful Agile projects areboth business & risk driven


195

196


Expected Monetary Value (EMV)• Calculates the average outcome when future

events are uncertainCost Probability Product

Optimistic Outcome $150,000 .20 $30,000Likely Outcome $225,000 .50 $112,500Pessimistic Outcome $300,000 .30 $90,000

$ 232,500



Decision Tree Analysis

ChoiceEvent

ChanceEvent

ChanceEvent

60%

40%

20%

80%

Outcome EMV$250K $150K

-$100K -$40K

-$45K -$9K

$100K $80K

Conservative EMV = $71,000

Aggressive EMV = $110,000


197

198


OTS or Develop

OTS

Develop

Well received

Rejected

Well received

Rejected

$ - 250K

$ - 350K

65%$550K

35%$ -100K

85%$500K

15%-60K

$ 300K

$ - 350K

$ 150K

$ - 410K

$ 195K

$ -123K

$ 128K

$ -61.5K

OTS$ 72K

Develop$ 66.5K

A.Cost ofChoice

B.Probability

&Outcome

C.Outcome

MinusCost in B.

D. C * Probability in B

E. Final Outcomes


Value‐Driven Delivery• Use EMV to determine risk value

• Insert risks into backlog with requirements sorted by cost.

Prioritized Risk List

Risk 1$10,000 x 60% = $6,000

Risk 2$7,000 x 50% = $3,500

Risk 3$6,000 x 50% = $3,000

Risk 4$5,000 X 20% = $2,000

Risk 5$3,000 x 33% = $1,000

PrioritizedRequirements

Requirement 1$6,500

Requirement 2$5,000

Requirement 3$4,000

Requirement 4$3,000

Requirement 5$2,500

Requirement 6$1,000

Risk‐AdjustedBacklog

Requirement 1 $6,500

Risk 1 $6,000



Risk 2 $3,500


Risk 3 $3,000


Risk 4 $2,000


Risk 5 $1,000

+ =


199

200

Value‐Driven Delivery• You have been asked to establish an estimated project cost using Expected

Monetary Value (EMV). If the project has a best case estimate of U.S. $10,000 with a probability of 20%, a most likely case estimate of U.S. $12,000 with a probability of 50%, and a worst case estimate of U.S. $14,400 with a probability of 30% what is the EMV for the project?A. U.S. $12,320B. U.S. $12,400C. U.S. $13,010D. U.S. $13,260

• You have been asked to establish an estimated project cost using Expected Monetary Value (EMV). If the project has a best case estimate of U.S. $15,000 with a probability of 30%, a most likely case estimate of U.S. $19,500 with a probability of 50%, and a worst case estimate of U.S. $26,325 with a probability of 20% what is the EMV for the project?A. U.S. $19.190B. U.S. $19,515C. U.S. $20,110D. U.S. $20,350


Value‐Driven Delivery• You have been asked to establish an estimated project cost using Expected

Monetary Value (EMV). If the project has a best case estimate of U.S. $10,000 with a probability of 20%, a most likely case estimate of U.S. $12,000 with a probability of 50%, and a worst case estimate of U.S. $14,400 with a probability of 30% what is the EMV for the project?A. U.S. $12,320B. U.S. $12,400C. U.S. $13,010D. U.S. $13,260

• You have been asked to establish an estimated project cost using Expected Monetary Value (EMV). If the project has a best case estimate of U.S. $15,000 with a probability of 30%, a most likely case estimate of U.S. $19,500 with a probability of 50%, and a worst case estimate of U.S. $26,325 with a probability of 20% what is the EMV for the project?A. U.S. $19.190B. U.S. $19,515C. U.S. $20,110D. U.S. $20,350


201

202


Agile Contracting

• Traditional contracting attempts to fix scope & cost. This often leads to overruns

• Agile contracting fixes time & costs leaving scope flexible.

• This requires greater communication.Fixed

Variable

Costs Time

ScopeCostsTime

Scope



Agile Contracting• DSDM Contracting – Focuses on work being

“fit for business purpose” & passing tests rather than matching specifications.

• Jeff Sutherland – “Money for Nothing & Change for Free” suggests early termination options & flexibility in making changes. Standard fixed price contract + T&M for additional work + a “change for free” clause if they work with the team on every iteration.


203

204


Agile Contracting

• Graduated Fixed Price Contracts

– Thorup & Jensen

– Both parties share risk

– Hourly rates are defined based on delivery

Completion Graduated Rate Total Fee

Early $200 / Hour $150,000

On Time $180 / Hour $175,000

Late $160 / Hour $200,000


Value‐Driven DeliveryAgile Contracting

• Multi‐tiered structure – Fixed items placed in master agreement. Items subject to change placed in schedule of services.

• Emphasize value delivered – Relationship governed by fixed milestones or phase gates based on value‐driven deliverables.

• Fixed price increments – Decompose the scope into fixed price micro‐deliverables such as user stories.

• Not‐to‐exceed time and materials – Limits the overall budget to a fixed amount. Allows customer to exchange requirements


205

206

Value‐Driven DeliveryAgile Contracting

• Early cancellation option – Customer can cancel the contract with only a limited cancellation fee should they desire.

• Dynamic scope option – Customer has the option to vary project scope at specified points in the project.

• Team augmentation – Suppliers services are embedded directly into the customer’s organization. Customer funds the team not a specific scope.

• Favor full‐service suppliers – To diversify risk, customer uses multiple suppliers where each often focuses on a single area. This often creates engagement and communication risks.



Why not Gantt Charts & other software?

• Data accuracy perception increases.

• Barriers for stakeholder interaction increase.


207

208


Little’s Law

• The cycle time, how long we are going to have to wait for benefits, is proportional to the size of the queue or how much WIP we have.

WIP

Cycle Time

Things we’ve finishedThings we’ve started

Cumulative Flow Chart



• Demonstrations – Critical to confirming success.– We learn about the differences between what is

asked for and what was interpreted & built.

– We learn about new or adjusted functionality.

• IKIWISI – I’ll Know It When I See It.

• Agile favors empirical and value‐based measurements instead of predictive measurements.


209

210


PV

AC

EV

EAC

SLIPPAGE

COSTVARIANCE

SCHEDULEVARIANCE

NOW

BAC VALUE

TIME

Cumulative Cost Curve



Divided By Divided By

Actual Costs

In Alphabetical OrderEarned Value Planned Value

CV =

CPI =

= SV

= SPI

Minus Minus


Completed FeaturesPlanned Features

Earned ValueActual CostsSPI = CPI =

211

212

Value‐Driven DeliveryForecasting ‐ ETC

• ETC based on new estimate

• ETC based on atypical variances

– ETC = BAC‐EV

• ETC based on typical variances

– ETC = (BAC‐EV)/CPI

• ETC based on both the CPI & SPI

– ETC = (BAC‐EV)/(CPI*SPI)

BAC = Budget at CompletionBAC‐EV = Remaining Work

VAC = Variance at Completionv. 10.2 ‐ © Copyright and all rights reserved – 2020



Forecasting ‐ EAC• Using a new estimate

– EAC = AC + ETC

• Using remaining budget– EAC = AC + (BAC‐EV)

• Using CPI– EAC = AC + ((BAC‐EV)/CPI)

• Using both CPI & SPI– EAC = AC + ((BAC‐EV)/(CPI*SPI))


213

214

Value‐Driven DeliveryForecasting ‐ TCPI

• The calculated projection of cost performance that must be achieved on the remaining work to meet a specified management goal.

• Using BAC– TCPI = (BAC – EV) / (BAC – AC)

• Using EAC– TCPI = (BAC ‐ EV) / (EAC ‐ AC)

• VAC = BAC ‐ EAC



0

200

400

600

800

1000

1200

1400

1600

1800

2000

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

Work Remaining

Work Remaining / Rate = Days to Completion

Burndown Chart


215

216

Value‐Driven DeliveryTo show when the product will be released use a Burn Up Chart

Forecast

Forecast showing scope creep

Time

Pro

du

ctiv

ity



217

218

Stakeholder EngagementDomain Tasks – Stakeholder Engagement

1. Identify & engage effective & empowered business stakeholder(s) through periodic reviews in order to ensure that the team is knowledgeable about stakeholders’ interests, needs, & expectations.

2. Identify & engage all stakeholders (current & future) by promoting knowledge sharing early & throughout the project to ensure the unimpeded flow of information & value throughout the lifespan of the project.


Domain Tasks – Ensure Stakeholder Involvement3. Establish stakeholder relationships by forming a working agreement among key stakeholders in order to

promote participation & effective collaboration.

4. Maintain proper stakeholder involvement by continually assessing changes in the project & organization in order to ensure that new stakeholders are appropriately engaged.

5. Establish collaborative behaviors among the members of the organization by fostering group decision making & conflict resolution in order to improve decision quality & reduce the time required to make decisions.



Domain Tasks – Manage Stakeholder Expectations6. Establish a shared vision of the various project increments (products, deliverables, releases, iterations) by

developing a high level vision & supporting objectives in order to align stakeholders’ expectations & build trust.

7. Establish & maintain a shared understanding of success criteria, deliverables, & acceptable trade‐offs by facilitating awareness among stakeholders in order to align expectations & build trust.

8. Provide transparency regarding work status by communicating team progress, work quality, impediments, & risks in order to help the primary stakeholders make informed decisions.

9. Provide forecasts at a level of detail that balances the need for certainty & the benefits of adaptability in order to allow stakeholders to plan effectively.

219

220

Who is a Stakeholder?• Anyone with a vested interest in the project


Stakeholder ExamplesYour Boss Shareholders The Government

Senior Executives Alliance Partners Trade Associations

Your Coworkers Suppliers The Press

Your Team Lenders Interest Groups

Customers Analysts The Public

Prospects Future Employees The Community

Your Family Users Sponsors



• Key Aspects

• Get the right stakeholders

• Maintain their involvement

• Actively manage their interest

• Frequently discuss “DoD”

• Show progress and capabilities

• Candidly discuss estimates and projections


221

222


Wireframes• Used for quick mock‐ups

• Visual tool for stakeholders

• Low fidelity tool – quick &

cheap



Personas• Provide an archetypal description of users.

• Are grounded in reality.

• Generate focus.

• Are tangible and actionable.

• Are goal oriented, specific and relevant.

• Do not replace requirements, simply augment them.

• Allow developers to empathize with users.


223

224


Personas• 1st introduced by Alan Cooper.

• Software needs to be designed for a specific person.

• Personas are different than Roles from Use Cases.

– A customer is a role

– A customer who is named, has specific circumstances and needs is a persona.

• Testing requires multiple personas.v. 10.2 ‐ © Copyright and all rights reserved – 2020


Stakeholder EngagementPersona Example: Frances Miller

• Sixty‐seven year‐old Frances is the mother of four children and the grandmother of twelve. She lives in her own home, bakes a pie once a week so that she has something to serve for Sunday visitors (usually one of her children and their immediate family), and has two cats. The cats' names are Fred and Wilma, names given to them by four‐year old grandson Bobby. She likes to knit and do needlework, which she either gives away as presents to her family or donates to the annual sale to raise money for the church she belongs to.

• Every morning she goes for a one hour walk along the lake front when the weather is good. On bad days she'll go with her neighbor to the local mall where a group of senior citizens "Mall Stroll" each morning before sitting down at one of the restaurants for coffee or tea. For breakfast Frances prefers a cup of Earl Grey tea and two slices of whole‐wheat toast with her own home‐made preserves. Lunch is typically a bowl of soup or a sandwich and then she'll have the opposite for dinner.

• She is a middle‐class retiree living on a fixed income and has been a widow for ten years. Her mortgage has been paid off and she has one credit card which she seldom uses. She has been a customer of the bank for 57 years although has never used an automated teller machine (ATM) and never intends to. She has no patience for phone banking and does not own a computer. Every Monday at 10:30 am she will visit her local bank branch to withdraw enough cash for the week. She prefers to talk with Selma the branch manager or with Robert, a CSR who was a high‐school friend of her oldest son.


225

226

User Stories• User Stories represent features written from

perspective of end users.

• A collection of User Stories is called the product backlog.

• User Story estimates are built using Story Points, but Story Points DON'T answer the question, when will my product ship?



User Stories• User Stories always use the form, "As a...

(ROLE) I need to ... (FUNCTION) so that I may ... (SUCCESS CRITERIA).

• User Stories are always written in the language of the business.

• Each User Story MUST have acceptance criteria & be testable.



227

228

User Stories Examples• As a site member, I want to describe myself on my

own page in a semi‐structured way so that others can learn about me. That is, I can fill in predefined fields, but also have room for a free‐text field or two.

• As a Practitioner or Trainer, when I write an article for the site I want a small graphic shown with the article showing my CSP or CST status so that others know my certifications when reading. (For example, Amazon’s “Top 500 Reviewers” approach.)

• As a site member, I can mark my profile as private in which case only my name will appear so that no one can learn things about me I don’t want shared.



User Story Strengths• Encourages effective communication about

requirements through frequent face‐to‐face interactions.

• Avoids too much detail which can increase cost without any benefit [Forrester & Simula].

• Better adaptation to change.

• Acknowledges the fact that all requirements are NOT known at the beginning.



229

230

User Stories The 3 Cs• Card – The brief description must have meaning to

both the team and the product owner.

• Conversation – This is the most important part. The card is not enough to write code. The card leads to a conversation to ensure understanding.

• Confirmation – This is the success criteria. It gives us the high‐level criteria against which the resulting feature will be tested.



You Must INVEST in Your Stories• Independent – From other stories.

• Negotiable – Not set in stone.

• Valuable – Don’t do it if it’s not necessary.

• Estimatable – You must be able to come up with realistic numbers.

• Small – Size matters!

• Testable – You must be able to prove it works.



231

232


• Given, When, Then ‐ Another format for stories.

• Used for non‐functional or system based stories.

• Example:

– Given the account is valid and the account has a MovieCredit balance of greater than 0,

– When the user redeems credit for a movie,

– Then issue the movie and reduce the user’s MovieCredit balance.



Definition of Done (DoD)• Before anything is declared done…

– Coded – Has all the code been written?

– Tested – Are all unit, integration and customer tests finished?

– Designed – Has the code been refactored to the team’s satisfaction?


233

234


Effe

ctiv

enes

s

Richness/Temperature(cold) (Hot)

Paper

E‐Mail

Audiorecording

Videorecording

Face‐to‐face (F2F)at whiteboard

No question andanswer capability

Question andanswer capability

F2F is Best

*Source: Alistair Cockburn



• Information Radiators – A number of highly visible methods to display information including large charts, graphs, & summaries of project data.

• Sometimes called “Visual Controls”

• From Alistair Cockburn


235

236


Information Radiators Examples

• Average Cycle Time Charts

• Burndown or Burn‐Up Charts

• Cumulative Flow Diagram

• EVMS Diagram

• Velocity Tracking Chart – A bar or line graph displaying daily velocity



Agile Modeling• Lightweight, barely sufficient capturing the design

without a need for further polish.• Scott Ambler top expert – Agile modeling’s value

peaks earlier than traditional theory leads us to believe.

• Types:– Use case diagrams– Data models– Screen designs


237

238

• The Diagram

• The Write Up




• Soft Skills• Negotiation• Active listening – hearing what someone is really

trying to convey rather than just the words. Three levels of active listening:– Level 1 Internal Listening – Ask how is this going to

affect me?– Level 2 Focused Listening – Put yourself in the mind of

the speaker.– Level 3 Global Listening – Builds on level 2 to pick up

on physical and environmental indicators.


239

240


• Facilitation methods – Focus on:

– Goals

– Rules

– Timing

– Assisting

• Globalization, culture & team diversity

• Distributed teams

• Conflict resolution



Resolution Concern

Mode StylePersonal

Goals Relationships• Withdrawal • Lose ‐ Leave • Low • Low

• Smoothing • Yield – Lose • Low • High

• Compromising • Compromise • Medium • Medium

• Forcing • Win – Lose • High • Low

• Problem Solving

(Confronting)

• Integrative • High • High

Conflict Resolution


241

242

Stakeholder EngagementSpeed B. Leas Conflict Model

Level Name CharacteristicsLanguage

Type Atmosphere / Environment

Level 1 Problem to Solve

Information sharing & collaboration

Open & fact‐based • People have different opinions or misunderstandings.

• Conflicting goals or values.• Not comfortable, but not emotionally charged

either.

Level 2 Disagreement Personal protectiontrumps resolving the conflict

Guarded & open to interpretation

• Self‐protection becomes important.• Team members distance themselves from the

debate.• Discussions happen off‐line (outside the team

environment)• Good‐natured joking moves to half‐joking barbs.

Level 3 Contest Winning trumps resolving the conflict

Includes personal attacks

• The aim is to win.• People take sides.• Blaming flourishes.

Level 4 Crusade Protecting one’s own group becomes focus

Ideological • Resolving the situation is not good enough.• Team members believe that people “on the other

side” will not change and need to be removed.

Level 5 World War Destroy the other! Little or nonexistent

• “Destroy!” is the battle cry• The combatants must be separated• No constructive outcome can be had


Needs AssessmentGroup Decision Making

• Simple voting

• Thumbs up/down/sideways

• Highsmith’s Decision Spectrum

• Fist‐of‐Five Voting – Likeart Scale


243

244


Management Focus Leadership Focus

• Tasks/things • People

• Control • Empowerment

• Efficiency • Effectiveness

• Doing things right • Doing the right things

• Speed • Direction

• Practices • Principles

• Command • Communication

Management vs. Leadership


Stakeholder EngagementServant Leadership

• The practice of leading through service to the team, by focusing on understanding and addressing the needs and development of team members in order to enable the best team performance.

• A servant leader facilitates the team’s discovery and definition of agile.

• Servant leaders practice and radiate agile.


245

246

Stakeholder EngagementServant Leader’s Approach to Work

• Purpose – Work with the team to define the “why” or purpose so they can engage and coalesce around the goal for the project. The entire team optimizes at the project level, not the person level.

• People – Once the purpose is established, encourage the team to create an environment where everyone can succeed. Ask each team member to contribute across the project work.

• Process – Do not plan on following the “perfect” agile process, but instead look for the results. When a cross‐functional team delivers finished value often and reflects on the product and process, the teams are agile. It does not matter what the team calls its process.


Stakeholder EngagementServant Leaders…

• Shield team from interruptions.

• Remove impediments to progress.

• (Re)communicate project vision.

• Carry food & water.

• Manage relationships to build communication and coordination within the team and across the organization.


247

248

Stakeholder EngagementServant Leaders…

• Promoting self‐awareness.

• Listening.

• Serving those on the team.

• Helping people grow.

• Coaching vs. controlling.

• Promoting safety, respect, and trust.

• Promoting the energy and intelligence of others.


Stakeholder Engagement12 Principles for Leading Agile Projects

1. Learn the team members’ needs.2. Learn the project’s requirements.3. Act for the simultaneous welfare of the team and the project.4. Create an environment of functional accountability.5. Have a vision of the completed project.6. Use the project vision to drive your own behavior.7. Serve as the central figure in successful team development.8. Recognize team conflict as a positive step.9. Manage with an eye toward ethics.10. Remember that ethics is not an afterthought, but an integral part

of our thinking.11. Take time to reflect on the project.12. Develop the trick of think backwards.


249

250


Team PerformanceDomain Tasks – Team Formation

1. Cooperate with the other team members to devise ground rules & internal processes in order to foster team coherence & strengthen team members’ commitment to shared outcomes.

2. Help create a team that has the interpersonal & technical skills needed to achieve all known project objectives in order to create business value with minimal delay.


Domain Tasks – Team Empowerment3. Encourage team members to become generalizing specialists in order to reduce team size & bottlenecks, &

to create a high‐performing cross‐functional team.

4. Contribute to self‐organizing the work by empowering others & encouraging emerging leadership in order to produce effective solutions & manage complexity.

5. Continuously discover team & personal motivators & de‐motivators in order to ensure that team morale is high & team members are motivated & productive throughout the project.

251

252

Team PerformanceDomain Tasks – Team Collaboration & Commitment

6. Facilitate close communication within the team & with appropriate external stakeholders through co‐location or the use of collaboration tools in order to reduce miscommunication & rework.

7. Reduce distractions in order to establish a predictable outcome & optimize the value delivered.

8. Participate in aligning project & team goals by sharing the project vision in order to ensure the team understands how their objectives fit into the overall goals of the project.

9. Encourage the team to measure its velocity by tracking & measuring actual performance in previous iterations or releases in order for members to gain a better understanding of their capacity & create more accurate forecasts.



COCOMO

• Stands for Constructive Cost Model

• Correlation study looking at thousands of software projects between input variables and total project costs

• Results used as estimating technique

• COCOMO II has the following weighting factors…


253

254


33

10

4 31 1 1

0

5

10

15

20

25

30

35

PeopleFactors

ProductFactors

ComputerPlatformFactors

Tools &ProcessFactors

ScheduleConstraint

Factors

ProjectPresedence

Factors

DesignReuse

Factors

Weighting Factors for COCOMO Input Variables


Boosting Team PerformanceAdaptive Leadership

• The process of making gradual & meaningful change over time.

• Must determine which processes are essential.

• Terms comes from Heifetz & Linsky – challenges can be solved through additional expertise and information.

• Highsmith ‐Creative leadership includes embracing ambiguity, taking risks that disrupt the status quo, instituting new management styles, and faster decision making. Building operating dexterity includes simplifying whenever possible, managing systemic complexity (standardization in some cases), and promoting a fast and flexible mindset.”


255

256

Boosting Team PerformanceAdaptive Leadership – Purpose Alignment

Model

• Used at any level—strategy, project, and feature.

• The two dimensions are market differentiation (does this really make a difference) and mission criticality (is it something we have to do to succeed).


Boosting Team PerformanceAdaptive Leadership – Other Models

• Short Horizon Model

• The OODA Model

• Satir Change Model


257

258

Boosting Team PerformanceAdaptive Leadership ‐ Bruce Tuckman Model

• Adapting how we lead based on circumstances.

• Five stages:

– Forming

– Storming

– Norming

– Performing

– Adjourning or Mourning


Boosting Team PerformanceLeadership Styles

• Autocratic – They solicit little or no informational input from their group and make managerial decisions solely by themselves.

• Consultative Autocratic – Intensive information input is solicited, but these leaders keep all substantive decision‐making authority to themselves.

• Consensus Manager – They throw open the problem to the group and encourage the entire team to make the relevant decision.

• Shareholder Manager – (Poor Management) little or no information input and exchange takes place within the group context, yet the group is provided the authority for the final decision.


259

260


Theories of Management Style• The Leadership Contingency Model (Fielder)

– Holds that there is no best overall style.– Style is contingent on the situation.– Variables affecting the situation.

• Team leader ↔ Team member relations• Degree of task structure• Position of power



Theories of Management Style• The Situational Leadership Theory

(Hersey and Blanchard)

– Identifies four (4) leadership styles

• Delegating

• Participating

• Selling

• Telling


261

262

Boosting Team PerformanceEmotional Intelligence

• The ability to identify, assess, and influence the emotions of ourselves, other individuals, and groups.


Boosting Team PerformanceAbility‐Based EI Model

• Perceiving Emotions – the ability to detect and decipher emotions in faces, pictures, voices, and cultural artifacts—including the ability to identify one's own emotions. Perceiving emotions represents a basic aspect of emotional intelligence, as it makes all other processing of emotional information possible.

• Using Emotions – the ability to harness emotions to facilitate various cognitive activities, such as thinking and problem solving. The emotionally intelligent person can capitalize fully upon his or her changing moods in order to best fit the task at hand.

• Understanding Emotions – the ability to comprehend emotional language and to appreciate complicated relationships among emotions. For example, understanding emotions encompasses the ability to be sensitive to slight variations between emotions, and the ability to recognize and describe how emotions evolve over time.

• Managing Emotions – the ability to regulate emotions in both ourselves and in others. Therefore, the emotionally intelligent person can harness emotions, even negative ones, and manage them to achieve intended goals.


263

264

Boosting Team PerformanceGoleman’s Mixed EI Model

• Self‐awareness – the ability to know one's emotions, strengths, weaknesses, drives, values and goals and recognize their impact on others while using gut feelings to guide decisions.

• Self‐regulation – involves controlling or redirecting one's disruptive emotions and impulses and adapting to changing circumstances.

• Social skill – managing relationships to move people in the desired direction.

• Empathy ‐ considering other people's feelings especially when making decision.

• Motivation ‐ being driven to achieve for the sake of achievement.



Empowered Teams• Are self directing.

• Uses a servant leadership approach.

• “Team” is generally small – 10 to 20 people.

• Has complementary skills.

• Committed to a common purpose.

• Holds themselves mutually accountable.


265

266


High‐Performance Teams• Create a shared vision for the team.

• Set realistic goals.

• Limit team size to 12 or fewer members.

• Build a sense of team identity.

• Provide strong leadership.

Source: Frank LaFasto in Teamwork


Boosting Team PerformanceHigh‐Performance Teams

• Are self‐organizing

• Are empowered to make decisions

• Believe as a team they can solve any problem

• Committed to team success

• Owns its decisions and commitments

• Trust motivates them

• Consensus‐driven with full divergence then convergence

• Live in a world of constant constructive disagreementSource: Lyssa Adkins


267

268

The Daily Scrum• Stand up means STAND UP!

• Target 10 minutes, 15 max.

• Same time every day & don’t miss a day.

• Stand in front of the visual progress artifact.

• Everybody is present.

• No typing during the meeting.

• Concentrate on the 2nd & 3rd questions.

• Don’t talk to the ScrumMaster. Talk to the team.



One‐on‐One Coaching & Mentoring• Meet them half‐step ahead.

• Guarantee safety.

• Partner with managers.

• Create positive regard.



269

270



Brainstorming Techniques• Free‐for‐All

• Quiet Writing

• Round‐Robin

• Adkins recommends “Green Zone / Red Zone” Model



271

272


Green Zone• Takes responsibility for

circumstances of their life.

• Seeks to respond non‐defensively.

• Seeks solutions rather than blame.

• Welcomes feedback

• Communicates a caring attitude.

Red Zone• Blames others for the

circumstances of their life.

• Feels threatened or wronged.

• Triggers defensiveness in others.

• Does not seek or value feedback.

• Communicates a high level of disapproval & contempt.


Other Tools• Team Space

• Co‐located Teams – Use the Caves & Common Model where offices are used for limited private conversations & most time spent in common areas.

• Osmotic Communication – Means that information flows in the background and is absorbed by the team members. They pick up relevant information by osmosis. Requires sitting in the same room.



273

274

Adaptive Planning

Adaptive PlanningDomain Tasks – Levels of Planning

1. Plan at multiple levels (strategic, release, iteration, daily) creating appropriate detail by using rolling wave planning & progressive elaboration to balance predictability of outcomes with ability to exploit opportunities.

2. Make planning activities visible & transparent by encouraging participation of key stakeholders & publishing planning results in order to increase commitment level & reduce uncertainty.

3. As the project unfolds, set & manage stakeholder expectations by making increasingly specific levels of commitments in order to ensure common understanding of the expected deliverables.


Domain Tasks – Adaptation4. Adapt the cadence & the planning process based on results of periodic retrospectives about characteristics

&/or the size/complexity/criticality of the project deliverables in order to maximize the value.

5. Inspect & adapt the project plan to reflect changes in requirements, schedule, budget, & shifting priorities based on team learning, delivery experience, stakeholder feedback, & defects in order to maximize business value delivered.

275

276

Adaptive Planning

Domain Tasks – Agile Sizing & Estimation6. Size items by using progressive elaboration techniques in order determine likely

project size independent of team velocity & external variables.

7. Adjust capacity by incorporating maintenance & operations demands & other factors in order to create or update the range estimates.

8. Create initial scope, schedule, & cost range estimates that reflect current high level understanding of the effort necessary to deliver the project in order to develop a starting point for managing the project.

9. Refine scope, schedule, & cost range estimates that reflect the latest understanding of the effort necessary to deliver the project in order to manage the project.

10. Continuously use data from changes in resource capacity, project size & velocity metrics in order to evaluate the estimate to complete.


The Basic Agile Project Planning Process


Product Vision – Done Every Year.

Product Roadmap – Done every 6 months.

Release Planning – Done every 90 days.

Iteration Planning – Done every 2 to 6 weeks.

Daily Standup – Done every day.

277

278

Adaptive Planning

• Reducing non‐value added work suggests planning only once.

• The only way to successfully plan a project is to plan and re‐plan.

• This is adaptive planning

– Accepting early plans are inaccurate.

– Uncertainty drives the need to re‐plan.


Adaptive Planning

Timeboxing• Short, fixed duration periods of time in which

activities or work are undertaken.

• Examples include:

– The Daily Scrum Meeting is timeboxed to 15 minutes.

– Iterations or sprints are timeboxed to 2 – 6 weeks.

• Agile locks the time leg of the triangle.


279

280

Adaptive PlanningProgressive Elaboration

• The process of capturing more detail over time as information emerges.

• Where is it used?– Estimates– FBS / WBS– Plans – Acceptance criteria– Test scenarios

• Two Types– Prototypes– Rolling Wave Planning


Adaptive PlanningPrototyping

Prototyping assumes it is often difficult to know all the requirements at the beginning of the project.

Prototyping requires the developer to build a simplified version of the proposed system and present it to the customer as part of the development process.

The prototype should never be deployed!


281

282

Adaptive PlanningReasons to Prototype

Prototypes can be used to complete requirements analysis.

Prototypes can account for design uncertainty.

Prototypes can allow experimentation and comparison of multiple solutions.


Adaptive Planning

Dangers of Prototyping False Expectations – “the system is now

complete.”

Increased Expense – must develop prototype and production system.

Poorly Designed Systems – Prototyping focuses on rapid development which can lead to heavy layering and a failure to make global considerations.


283

284

Adaptive Planning

Rolling Wave Planning• Detailed planning is done for activities in the

near term & only high‐level planning is done for the activities to be performed far into the future.

• The project is iteratively planned.

• It is a multi‐step, intermittent process.


Adaptive Planning

Process Tailoring• Changing the process over time.

• Answering the questions:

– What is going well?

– What areas could use improvement?

– What should we be doing differently?


285

286

The Agile Pyramid

Minimum Viable Product (MVP)

Minimally Marketable Features (MMF)


The Agile Pyramid


Organizational Learning

Lean Thinking

Agile SoftwareDevelopment

XPScrum

Applicability

Mo

re p

hilo

sop

hic

alV

alu

e & id

ea b

ased

Mo

re p

ersp

ecti

ve

287

288

The Agile Test Pyramid


Unit Tests

Integration Tests

Acceptance Tests

GUI Tests

Beta

Adaptive Planning

Value‐Based Analysis• Process of considering the business value of work

items & then acting accordingly.

• When prioritizing the work, the highest business value is done first.

• In Value‐Based Analysis the costs must be offset.


289

290

Adaptive Planning

Value‐Based Decomposition & Prioritization

• Eliciting requirements from stakeholders, ranking the requirements, then pulling prioritized requirements into the development process.

• Requirements are initially course grained.


Adaptive Planning

Agile Games• Remember the Future

– Each stakeholder starts independently.– Spend 20 minutes writing stickies on what world looks like.– Stickies brought together on the wall, duplicates are

removed & items are grouped.

• Prune the Product Tree– Start by drawing a big tree.– Stakeholders add features as leaves to the tree.– Group leaves on branches.– Core features closer to the trunk.


291

292

Adaptive Planning

Agile Games• Speedboat

– A risk management exercise

– Done after Prune the Product Tree

– Draw picture of sailboat on water.

– Positive risks are placed above water “wind”

– Negative risks placed below water “drag”

– Big negative risks can be “rocks”


Adaptive Planning

Agile Games• Buy a Feature

– Divide group into

customers & team.

– Customers define

value

– Team define cost

– Move stories onto

chart.


PBI PBI PBI PBI PBI PBI PBI PBI

40

20

13

8

5

3

21

1 2 3 5 8 13 20 40

Va

lue

Cost

Play Now

293

294

Adaptive Planning

Agile Games• Bang for the Buck

– Prioritization exercise

– Done after team has estimated costs of features.

– Customers given $$$ and allowed to spend on features.

– Make sure some require combining $$$.


Adaptive Planning

Estimation• Agile estimation assumes complexity &

uncertainty.• Estimates are necessary for sizing & approvals,

calculating ROI, etc.• Holistic estimates require inclusion of

development, rollout, & sustainment costs.• Estimates should always be given as ranges.• Estimation must be done continuously.• Team members must do estimates.


295

296

Adaptive Planning

Estimation• Ideal Time ‐ Assumes resources 100% dedicated

• Relative Sizing – Often called T‐Shirt sizing.

• Story Points – Aggregates complexity & time.

• Fibonacci Sequence – Another comparison technique.

• Affinity Estimating – Process of grouping requirements into categories or collections. Used to group similarly sized user stories together.


Adaptive Planning

Affinity Estimating


Ride aBike

Ride aSkate‐board

Drive aCar

Ride aMotorcycle

Sail aBoat

Fly aPlane

Land theSpace

Shuttle

1 2 3 5 8 13 20 40

?

297

298

Adaptive Planning

Wideband Delphi & Planning Poker• Wideband Delphi

– Starts with group breaking down project into large components.

– Group raises questions & discusses.

– Anonymous estimates collected.

– Aggregate results on plot.

– Assumptions discussed & re‐estimated.

– Continue until reaching preset range.


Adaptive PlanningPlanning Poker


Release Planning / Planning Poker Session

Review card values with team

PO gives overview of User Story

@ same time, estimators show cards with their estimates

Team has consensus on value

All requirements

estimated

Move to next requirementLowest & highest estimate

give justification

Sprint Planning MeetingNoYes

No

Yes

299

300

Adaptive Planning

Estimation• ROM – Rough Order of Magnitude estimate.

Done early in project lifecycle. ‐25% to +75%.

• Definitive or Budget Estimate – Detailed estimate that is the final budget. ‐5% to +10%.


Adaptive Planning

Time & Cost Estimation• Determine the size

• Calculate the effort

• Convert effort into a schedule

• Calculate the cost


301

302

What Causes Project Delays?• Unfocused management

• A focus on task management

• Dependencies between steps cause delays to accumulate and advances to be wasted.

• Parkinson’s Law

Adaptive Planning


What Causes Project Delays?• The “safety” is misplaced

• Student Syndrome

• Lack of performance metrics

• Multi‐tasking

Adaptive Planning


303

304

Adaptive Planning

Planning Differences• Trial & demonstration uncover true requirements,

which then require replanning.

• Agile planning is less of an upfront effort & is done more throughout the entire project.

• Midcourse adjustments are the norm.

• Business cases & charters are largely the same.


Problem Detection & Resolution

305

306

Problem Detection & ResolutionDomain Tasks

1. Create an open & safe environment by encouraging conversation & experimentation, in order to surface problems & impediments that are slowing the team down or preventing its ability to deliver value.

2. Identify threats & issues by educating & engaging the team at various points in the project in order to resolve them at the appropriate time & improve processes that caused issues.

3. Ensure issues are resolved by appropriate team members &/or reset expectations in light of issues that cannot be resolved in order to maximize the value delivered.

4. Maintain a visible, monitored, & prioritized list of threats & issues in order to elevate accountability, encourage action, & track ownership & resolution status.

5. Communicate status of threats & issues by maintaining threat list & incorporating activities into backlog of work in order to provide transparency.



• Cycle Time – How long it takes to get things done.

• Cycle Time is closely related to WIP.

– WIP is money spent with no return.

– WIP hides bottlenecks & efficiency issues.

– WIP represents potential rework.

• Agile attempts to reduce WIP & Cycle Time

Cycle Time = WIP

Throughput


307

308


Dollars

Time

Cost vs. Value of Change



Escaped Defects

• Daily standup used to identify most defects.

• Those missed that make it to the customer are called Escaped Defects.

• Escaped Defects are most costly to fix.

• Escaped Defects Found Metric should scale down over time.


309

310


Quality Standards• Focus is “Fitness for Purpose” – What will the

team do to ensure the quality and value of the product?

• Common actions:– Measuring tests passed & customer acceptance.

– Automating tests.

– Constant testing.

– Ensure testers & developers collaborate.



Failure Modes & Alternatives• Making mistakes

• Preferring to fail conservatively

• Inventing rather than researching

• Being creatures of habit

• Being inconsistentAlistair Cockburn


311

312


Failure Modes & Alternatives

• Be good at looking around

• Be able to learn

• Be malleable

• Take pride in your work



Failure Modes & Alternatives• Counter with discipline & tolerance• Start with something concrete and tangible• Copy & alter• Watch & listen• Support concentration & communication• Create personality matched assignments• Use talent• Create rewards that preserve joy• Combine rewards• Provide lots of feedback


313

314

Problem Detection & Resolution• In Control – When ‘in control’ a process should not be

adjusted.

• Specification Limits – Customer expectations or contract requirements.

• What is the ‘rule of 7’?

X

UCL

LCL

3ơ2ơ1ơ

-1ơ-2ơ-3ơ


x

xx

x

x

x

x

x

x

x

xx


Continuous Integration

• Source code control system

• Build tools

• Test tools

• Scheduler or trigger

• Notifications


315

316

Problem Detection & ResolutionContinuous Integration

• Why use it?– Team receives early warning of bad or broken code.– Integration problems are fixed as they occur– The team receives immediate feedback– Ensures frequent unit testing– Code can be reverted back quickly

• Costs– Setup time– Hardware to act as a build server– Time to create automated testing


Problem Detection & ResolutionRisk‐Based Spike

• A short sprint undertaken by the team to investigate an issue.

• Can result in a solution, recommendation or decision.

• Follows notion of failing fast.

• Used to test new technology early.


317

318

Test Driven Development (TDD)

• Tests are written BEFORE the code.• A Unit Test is a test of a small, functional piece of

code.• Unit Tests are given priority in TDD.• Unit tests make it…

– Easier to find bugs.– Easier to maintain the code, but not test maintainability

or test readability.– Easier to have full code coverage.– Easier to design & develop code.– Easier to deliver early & often.– Easier to track performance.



Step 1: Write Function

Double calculateLoan (int amount, int months, float interest rate)

{

// …assume functionality

// …

}

Step 2: Write test(s)

calculateLoan (20000,60,5.0);

// is result 382.02

CalculateLoan(6000,12,10.0);

// is result 527.50?


Traditional Coding Model

319

320


Step 2: Write Code

Double calculateLoan (int amount, int months, float interest rate)

{

// …assume functionality

// …

}

Step 1: Write test(s)

calculateLoan (20000,60,5.0);

// is result 382.02

CalculateLoan(6000,12,10.0);

// is result 527.50?


The TDD Model


1. Red

2. Green

3. Refactor


321

322


• Must be able to make it fail. No code is written without a failed test. Tests MUST be run to ensure the failure state BEFORE writing any code.

• Running the test to prove failure is a fundamental difference of TDD.

• Make it work. Code must be as simple as possible. The code must ONLY pass that new test for which it was designed.

• Make it better. This means you must refactor.


Test Driven Development (TDD)• TDD doesn’t work for everything.

– Remember these are automated unit tests. Things like security, multi‐threading, UI, game development issues might require more.

– Unit testing does NOT replace other types of testing.

• Do NOT write ALL the tests first.– In the process write a single test, fail that test, write the code

to pass that test. These are very small steps.

• Separate tester or QA dept. does not write these tests.– A separate QA dept. should be doing a different level of

testing. It just slows down the process. It is not the same as TDD.


323

324

Problem Detection & ResolutionTest‐Driven Development

• Advantages– Focuses developer on needs of the customer.– Ensures at least some test are in place.– Helps catch defects early in cycle.– More modular, flexible & extendable.

• Disadvantages:– Unit tests usually done by developer.– Some functionality difficult to test with unit testing– Tests must be maintained.– Higher number of passed tests equal false sense of

success.



Acceptance Test‐Driven Development

• Also called ATDD

• Moves testing focus from code to business requirements.

• Tests created before coding.

• Might use functional test framework such as FIT (Framework for Integrated Testing) or FitNesse


325

326


Framework for Integrated Testing (FIT)• An open‐source tool for automated customer

testing.

• Customer provides examples of working process that are formatted in tables and saved as HTML using tools like Excel.

• Examples are connected with programmer written test fixtures & checked.

• Simple command line tool.

• Originally created in 2002 by Ward Cunningham.



FitNesse• A web server for automated testing.

Fitnesse.org

• A complete integrated development environment (IDE) – includes source code editor, built automation tools and a debugger.

• Uses a wiki for its front end – A website where users collaboratively modify content and structure directly from the web browser.


327

328

Problem Detection & ResolutionAcceptance Test‐Driven Development

• Four stages:– Discuss the requirements – during planning meeting

ask acceptance criteria.

– Distill tests in a framework‐friendly format.

– Develop the code and hook up the tests.

– Demo through exploratory testing.

• Regardless of method team must think about how the system will be tested before coding.



• Automated

• Functional Testing

• Testing by Programmers

• Testing @ Unit Level

• Testing Written Before Code

• Automated

• Functional Testing

• Testing by Programmers

• Testing @ Unit Level

• Testing Written Before Code


TDD vs. Test 1st

• In TDD code refactored to improve design. Skipped in Test 1st.• Test 1st says nothing about other activities in development cycle.• BIG DIFFERENCE with TDD – In TDD tests drive the design.

329

330

Refactoring• Refactoring – Process of changing existing

code to improve the way it functions.

• In XP you are not afraid of refactoring.

• Refactoring is part of your regular work & not a separate task.


Extreme Programming

Types of Refactoring• Yuck – You look at code and it works, but is

unsatisfactory. This is about making small improvements.

• The Not Understood – Code that you look at and cannot understand what it is doing. You must make code easier to understand.

• New Insights – When new functionality needs to be added, or you learn something.


Extreme Programming

331

332

Types of Refactoring• Planned Refactoring – Actually adding refactoring

to your project plan as a deliverable.

– M. Fowler says it should hardly ever be done, because it represents a failure of the team to do the refactoring in small enough pieces to be constant.

– Planned refactoring almost always requires justification.

– Is evidence that you are not doing enough of the other types of refactoring.


Extreme Programming

Types of Refactoring• Long Term Refactoring – Trying to get closer to

some large future goal. Get some vision of where you want things to be in the future.

– Must be done gradually.

– Does not require significant planning.

– The essence is doing small steps.


Extreme Programming

333

334

Refactoring• Is refactoring just wasteful rework?


Extreme Programming

Good Design

No Design

M. Fowler’s Design Stamina Hypothesis

…Useful up here there’s noUseful trade‐off.

Down here it may be worth trading offDesign quality for time to market…

Extreme Programming

• Quality

• Clean Code

• Professionalism

• It’s the right thing to do

• Simple Economics – It allows you to deliver more functionality more quickly and is the only reason you should be refactoring.


Why Refactor?

335

336


Problem Solving

• Basic problem solving

– Gather data

– Generate insights

– Decide what to do



Problem Solving – Gather Data• Timeline – Think about the project from a time‐based

perspective.• Triple Nickels – Top 5 ideas are elaborated by 5 groups 5

times.• Color Code Dots – Group affinity clustering technique.• Mad, Sad, Glad – Explore the emotive elements.• Locate Strengths – Look at what went well.• Satisfaction Histogram – Review feelings through the

project.• Team Radar – Multidiscipline assessment tool.• Like to Like – A strength diagnostic tool.


337

338


Problem Solving – Generate Insights

• Brainstorming

• Five whys

• Fishbone

• Prioritize with dots

• Identify themes




5 Whys

• Used to determine the root cause of problems

• Developed by Sakichi Toyoda

• 2 Techniques used:

– Tabular Format

– Fishbone Diagrams

339

340


Cause and Effect Diagram(Ishikawa or Fishbone Diagram)


MajorDefect

Time Machine Method Material

Energy Measurement Personnel Environment Effect

Potential Causes


Problem Solving ‐ Decide What to Do

• Short Subjects

• SMART Goals – Specific, Measurable, Attainable, Relevant, & Timely

• Retrospective Planning Game

• Circle of Questions


341

342

Problem Detection & ResolutionShort Subjects

• Give team members 3‐5 minutes to reflect privately on the iteration and write notes.

• Brainstorm and record ideas. Keep going until all the comments team members think are important have been posted on the charts.

• Ask the team to identify the top 20% of the items‐those items they believe have the potential for the greatest benefit. Then vote with dots.

• If there are more than 2‐3 high priority items, reduce the issues for action to a manageable few.

• Keep the brainstormed lists for review to help identify areas of persistent issues.


Problem Detection & ResolutionSMART Goals

• Specific ‐ Vague promises of improvement usually don't generate results. Think of the 5 W's: who, what, when, where, and why.

• Measurable ‐ Attainment of our specific example goal might be validated by answering some questions: What was the average number of stories completed within two to three days? How many stories did not complete in this time?

• Attainable ‐ It's important that a team can check off completed goals, to reinforce the sense of achievement. Obviously goals that your team can complete in an iteration best meet this criterion, but you don't want to have only short‐term goals. There's nothing wrong with long‐term goals; just make sure there's a way to measure incremental progress.

• Relevant ‐ Too many trivial goals can give a bloated sense of achievement. Shortening daily stand‐up meetings by limiting them to five minutes might seem beneficial, but does it really change anything?

• Time bound ‐ Like stories, many teams tend to have a problem with letting things creep past iteration boundaries. "We just need a little more time."


343

344


Retrospective Planning Game• Work as individuals or in pairs.

• Ask each pair to write one task per card or sticky, leaving the bottom half blank.

• Compare tasks, eliminate duplicates and write any new tasks you realize are missing.

• Invite the group to post and cluster the tasks on a whiteboard or wall.

• Compare, look for duplicates, and add any new tasks that the team realizes are missing.

• Leave room on the left side of the wall or whiteboard. The team will use this in the next step when they order the tasks.

• Order the cards. Ask: “Which task must be done first?” Move that task to the extreme left of the working surface. Then ask, “Are there any tasks that can be done simultaneously with this task?” Place those above or below the first task.

• Ask which task needs to be done next. Place that to the right of the first task.

• Invite team members to sign up for tasks by writing their names on the bottom half of the task cards.


Problem Detection & ResolutionCircle of Questions

• Invite team members to sit in a circle. Introduce the activity.

• Turn to the person on your left and ask a question. “From your perspective, what is the highest priority for us to try in the next iteration?” The team member answers, from his or her perspective, to the best of his or her knowledge and ability.

• That team member becomes the questioner, turning to the person on his or her left to ask a question that extends the previous discussion or starts a new one.

• The new respondent answers and, then in turn, asks a question and so on around the circle until the group is satisfied that their questions about the topic have been heard and considered, and a consensus for action has emerged.


345

346


Continuous ImprovementDomain Tasks

1. Tailor & adapt the project process by periodically reviewing & integrating team practices, organizational culture, & delivery goals in order to ensure team effectiveness within established organizational guidelines & norms.

2. Improve team processes by conducting frequent retrospectives & improvement experiments in order to continually enhance the effectiveness of the team, project, & organization.

3. Seek feedback on the product by incremental delivery & frequent demonstrations in order to improve the value of the product.

4. Create an environment of continued learning by providing opportunities for people to develop their skills in order to develop a more productive team of generalizing specialists.

5. Challenge existing process elements by performing a value stream analysis & removing waste in order to increase individual efficiency & team effectiveness.

6. Create systemic improvements by disseminating knowledge & practices across projects & organizational boundaries in order to avoid re‐occurrence of identified problems & improve the effectiveness of the organization as a whole.


347

348

Continuous ImprovementRetrospectives Are Key

• Improved productivity

• Improved capability

• Improved quality

• Improved capacity



Retrospectives Steps• Set the stage

– Check‐in– Focus on/focus off– ESVP – Participants anonymously associate themselves with an

identity on slip of paper Explorer, Shopper, Vacationer, Prisoner– Working Agreements

• Gather data• Generate insights• Decide what to do• Close the retrospective

– Plus/delta – Franklin T– Helped, hindered, hypothesis– Return on time invested– Appreciations


349

350

Continuous ImprovementFocus On/Focus Off

• Draw attention to the Focus On/FocusOff poster and briefly read through it.

• Form small groups, with no more thanfour people per group. Ask each group to take one pair of words to define and describe.

• Ask each group to discuss what their two words mean and what behaviors they represent. Have them describe the impact each would have on the team and the retrospective.

• Each group reports on their discussion v. 10.2 ‐ © Copyright and all rights reserved – 2020


Continuous ImprovementESVP

• Explain that you are taking a poll to learn about how people view their participation in the retrospective.

• Show the flip chart and define the terms: – Explorers are eager to discover new ideas and insights. They want to learn everything they can about

the iteration/release/project.

– Shoppers will look over all the available information, and will be happy to go home with one useful new idea.

– Vacationers aren’t interested in the work of the retrospective, but are happy to be away from the daily grind. They may pay attention some of the time, but they are mostly glad to be out of the office.

– Prisoners feel that they’ve been forced to attend and would rather be doing something else.

• Distribute slips of paper or small index cards for people to record their attitude toward learning in the retrospective today. Instruct people to fold their paper in half for privacy.

• As people finish writing and folding, collect the slips and shuffle them.

• Ask one of the participants to make tick marks on the histogram as you read the slips. After you read each slip, put them in your pocket. When you’ve read all the slips, tear them up and throw them away. Be conspicuous about this so people know that no one will try to identify who responded with what from the handwriting.

• Ask the group, “What do you make of this data?” Then lead a brief discussion about how the attitudes in the room will affect the retrospective.

• Debrief by asking “How are these categories like our attitudes toward daily work?”


351

352

Continuous ImprovementSample Working Agreement

• Always– Product Owner is responsive to team requests for information– Team will close higher priority stories first. To do so, we limit the number of stories in progress at any one

time. NOTE: Rule of thumb is to put as many people on the highest priority story that is still efficient.– Team members use information radiators (sprint burndown) to help determine whether we're on track with

commitment.– All agile ceremonies are time boxed. This means that they start on time and end on time. To maximize the

effectiveness of these ceremonies team members show up on time and are committed to being completely focused and dedicated to the task at hand.

– We use the retrospective to continually inspect, adapt, and therefore improve our work together.– Core hours are established between 11:00am and 4:00pm where no non‐agile meetings with Team

members maybe set up. Informal conversations between team members are ALWAYS fine.

• Planning– We believe in in the value of planning collectively as a team – Product Owner respects teams estimates coming out of release planning / sprint planning– Product Owner keeps the backlog up to date. – Team contributes to product backlog in advance of planning sessions.

• During Sprint– Team members attend daily scrum at 9:30am– Should a team member have a conflict, s/he updates the board in advance of the meeting and sends an

email with updates for the team. – Task board is updated during daily stand up meeting so team members can refer to the specific tasks they

are working on or completed.– Team members may add new tasks any time.– Communicate impediments to Scrum Master such as dependencies, issues, waiting, and so on– Stories completed to Definition of Done and Product Owner agrees acceptance criteria of story is met.


Continuous ImprovementHelped, Hindered, Hypothesize

• Show three flip charts, that represent things about this retrospective that helped you to think as a group and learn about the iteration, things that hindered or got in the way of your thinking or learning, and what hypothesis you might have about things I could do differently to improve our next retrospective.”

• Use the sticky notes to write your feedback. When you are done please put your initials on each note, and stick them on the appropriate flip chart.

• End by thanking the team for helping you to improve. Ask whether you may contact team members later if you need clarification


353

354


Pre‐Mortem• Retrospective tool to solve problems BEFORE

project is complete.

• Rules:

– Set aside 2 hours of uninterrupted time.

– All stakeholder MUST be present.

– The Pre‐Mortem must be a face‐to‐face meeting.

– One person does nothing but take notes.



Pre‐Mortem Process• Spend 1st hour listing every possible problem.

• Pick top 10 problems.

– Focus on show‐stoppers.

– Pick problems likely to happen.

– Discard problems you have no control over.

• Spend the second hour creating solutions.

– Create a proactive solution for problems.

– Define a backup plan.v. 10.2 ‐ © Copyright and all rights reserved – 2020


355

356

Stacey Complexity ModelContinuous Improvement

Simple Complicated

Complicated

Anarchy

Complex

Far FromAgreement

Close toAgreement

Close toCertainty

Far FromCertaintyv. 10.2 ‐ © Copyright and all rights reserved – 2020


ACP Exam PrepMartin [email protected]

357

358

lookingglassdev.com · table of contents pmi—acp exam preparation student guide v10.2 ©2020...

Documents