Summary

This books attempts to sync up the PMBOK with Agile.  I think the two sync up about as well as the Dark Side of the Moon and the Wizard of Oz.  Yes, there are strong correlations occasionally, but when they diverge, they just say they are different.  The book expends a lot of effort in mapping one term to the other, which is the premise of the book.  It seems to me that the book is a attempt (and a good one) at translating what knowledge and skills people learned in pursuing a PMP into the Agile world.  I think it is better to have never stepped foot into the PMP world.  The more I read about the PMP world the more I am glad I do not live in it and see the value of Agile as a force to defeat the dark side.  I read how things are mapped and I look at the PMP way and just have to say, well no wonder people are looking for a better way to build software.  I guess I could sum everything up by saying in PMP, the information is done by small groups or an individual and then placed into an information refrigerator whereas in Agile the work is done by the team and then placed into an information radiator.  While it might seem that I don’t like the book, I do.  It is well written and structured and helps me understand better the *why* behind what I do and the motivations of the people who have grown up in this world.  The more I read the more I find out activities that should be done, but are done differently in Agile.  While that seems obvious, too often that process or activity is not done, which isn’t good.  I’m thinking that taking the activities listed in the book and creating a checklist and see how the teams are doing against that checklist.

Top 3 Things I learned

• I like the checklist below on the items for a Sprint Review, though they might be better at a Sprint Retrospective, or something at the beginning of the Retro or after.  It’s a mix of things the team needs and the product owner needs.
• The 5 values of Scrum (commitment, openness, focus, courage, and respect) and XP (communication, feedback, simplicity, courage, and respect)
• I like the Risk Planning Board discussed in the Risk Management section.

---

Notes: Chapter 1: What is Agile?

SUMMARY: Discusses Agile Manifesto and the 12 Guiding Principles

CONCEPT: Scrum: Get everyone working together to move the ball in one direction versus handing the ball of to the next person

CONCEPT: Lean: Focus on elimination of waste through continuous process improvement

CONCEPT: Agile Manifesto: Discovering new ways to create great software

1. Individuals over process
2. Collaboration over negotiation
3. Planning over following a plan
4. Software over documentation

CONCEPT: 12 Guiding Principles

1. Early and continuous delivery
2. Reflect
3. Deliver software frequently
4. Daily interaction between business and developers
5. Sustainable pace
6. Build teams around self-motivated individuals
7. Welcome change
8. Face-to-face communication
9. Working software is the primary means of progress
10. Simplicity
11. Self-organizing teams
12. Continuous attention to technical excellence

---

 Notes: Chapter 2: Mapping from the PMBOK Guide to Agile

SUMMARY:  Introduces the term project lifecycle and then show how Agile supports that definition

TERM: Project Lifecycle.  Collection of generally sequential project phases whose name and number are determined the by control needs of the  organization(s) involved in the project

CONCEPT: Sequential does not equal waterfall

NOTE: Key difference between PMBOX and Agile is the customer involvement through the project

CONCEPT: Continous improvement

1.  Plan
2. Do
3. Check
4. Act

CONCEPT: Project Management Process groups

1. Initiate
2. Planning
3. Execution
4. Monitor and Control
5. Closing

---

Notes: Chapter 3: Agile Project Lifecycle in Detail

SUMMARY:  Outline of what is a project, release, iteration, and daily work.

CONCEPT: Agile is value-driven s. plan driven

MAP:  Releases to phases

MAP: A release to a milestone

CONCEPT: Project

1. Plan
2. Release
3. Review

MAP: iteration to subphases

MAP: Release plan to project schedule

---

Notes: Chapter 4; Integration Management

SUMMARY: A comparison of certain PMBOK activities to Agile for Integration Management (whatever that is)

CONCEPT: Planning meetings should have good chaos

CONCEPT: Barely sufficient is good enough

TERM: Elevator Statement.  A brief statement designed to impart the intent of the project in 2 minutes.

TECHNIQUE: Elevator Statement

1. For (target customer)
2. Who (statement of need)
3. The (product name) is a (product category)
4. That (key benefit)
5. Unlike (primary competitive alternative)
6. Our Product (statement of primary difference)

TECHNIQUE:  Design the box

MAP: Project charter to Preliminary Scope Statement

TECHNIQUE: Team working agreements, 5-10 items, revisit at retrospectives

MAP: Project management plan to Roadmap and Charter

CONCEPT: Traditional command and controll vs. Agile collaborative Servant leadershi

MAP: Project execution and control: guide vs. control

KEY DIFFERENCE:  Process owned by team, changes owned by customer

KEY DIFFERENCE:  Integrated change control: Control vs. Welcome

TECHNIQUE: Hardening sprint at the end, not a bug fixing sprint

OLD vs NEW:

1. Drive a formal project charter document | Visioning Meeting
2. Formal documentation | “Barely Sufficient”
3. Project Plan | Communicate the agile process and framework
4. Separate Change Control Process | Integrate change control
5. Lessons Learned | vs Project Retrospective

---

Notes: Chapter 5; Scope Management

SUMMARY:  Tries to map scope to PMBOK but they are so different this mostly cermony and foolish.

CONCEPT: 

• TRADITIONAL: Fix Scope, Flex Resources and Schedule
• AGILE: Fix Resources and Schedule, Flex Scope

TERM: Last Responsible Moment.  When failing to make a decision eliminates an alternative

DIFFERENCE: No WBS

---

Notes: Chapter 6: Time Management

SUMMARY: Differnece between traditional and agile on schedules and activities

CONCEPT:  Schedule Approach

• TRADITIONAL: Industrial works well for a repeatable process with a predictable outcome
• AGILE: Build, learn, build again, learn more

CONCEPT: Schedule

• TRADITIONAL: End date is the end of an activitiy
• AGILE: End of a feature

TERM: Sprint 0 and Sprint H (Hardening) are minimal bookends for work that is not explicitly new development

CONCEPT: Activity Definition

• TRADITIONAL: Id and document work to be done
• AGILE: Define user stories and tasks

CONCEPT: Work Packages

• TRADITIONAL: Individual tasks
• AGILE: Features

CONCEPT: Activity Sequencing

• TRADITIONAL: PM ID and Document at the beginning
• AGILE: Team handles in an iteration

CONCEPT: Activity Resource Estimating

• TRADITIONAL: Define activity then resources
• AGILE: Resources up front

CHECKLIST:  At Sprint Review (some of this seems like it would come out of a sprint retrospective)

• What features did the team(s) complete this iteration?
• Was the iteration accomplishment more or less than what was expected?
• Is the team able to fully test the features? If not, what work remains, and how does that impact our release plan?
• What is the team’s observed velocity?
• Is this velocity increasing over tie? Decreasing?
• What are the factors bringing about the increase or decrease?
• How might this impact the other iterations in the release?
• Should we ask for more iterations? Do we need an iteration to integrate or reun performance tests? Or should we remove the lowest-priority features from the release and put them back into the product backlog?
• How does the team feel about the plan based on observed results?

---

Notes: Chapter 7: Cost Management

SUMMARY: Cost estimating and control

CONCEPT: Cost Estimating

• TRADITIONAL: PM –> From tasks, sum up activities and work packages (bottom up)
• AGILE: Team –> From Features and story points

CONCEPT: Change

• TRADITIONAL: Scope change / creep
• AGILE: Expected Change

TERM: Performance Measurement Baseline (PMB)

• TRADITIONAL: Sum all work package estimates
• AGILE: Story Point total

TERM: Schedule baseline

• TRADITIONAL: Sum all work packages for each time period for the total duration
• AGILE: Total number of planned iterations multiplied by sprint length

TERM: Budget at Complete (BC)

• TRADITIONAL: Planned budget for the release
• AGILE: Planned budget for the release

TERM: Planned Percent Complete (PC)

• TRADITIONAL: Completion at point in time / baseline
• AGILE: Number of Sprints complete / total number of sprints

TERM: Actual Percent Complete (APC)

• TRADITIONAL: Dollar value of work complete / total dollar value of project
• AGILE: Story Points Completed / Total number of Story Points

---

Notes: Chapter 8: Quality Management

SUMMARY: Explains Quality Assurance (QA) and Quality Control (QC) and points out that much of what is said to be “QA” is really “QC”.

QUOTE:  Quality is planned, designed, and built in — not inspected.

QUOTE:  Customers pay only for what is of use to them and gives them value.  Nothing else is quality.

TERM: Technical debt occurs when a system isn’t functioning properly and yet new features are added rather than fixing.

---

Notes: Chapter 9: Human Resources Management

SUMMARY:  Discusses soft skills in managing people

CONCEPT: 5 values of scrum and XP

1. Scrum
   1. Commitment
   2. Openness
   3. Focus
   4. Courage
   5. Respect
2. XP
   1. Communication
   2. Feedback
   3. Simplicity
   4. Courage
   5. Respect

CONCEPT: Theory X (employees are lazy and must be managed) vs. Theory Y (employees are motivated and want to achieve)

---

Notes: Chapter 10: Communications Management

SUMMARY: Repeats one concept across the chapter: Traditional: Plan and Document; Agile Facilitate.

CONCEPT:  Iteration Delta Table

Kickoff | Story

1 | As..

1 | As..

2 | As..

2 | As..

3 | As..

Now | Kickoff | Story

1 | 1 | As..

1 | 1 | As.

2 | 2 | As..

2 | New | As..

3 | 2 | As…

Backlog | 3 | As ..

CONCEPT: Iteration status report

• [Project Name] Status Report for Iteration [n] Ending [Date]
• Distribution
• Red/Yellow/Green Indication
• Executive Brief
• Accomplishments
• Work in Progress
• Upcoming Activities
• Issues.

---

Notes: Chapter 11; Risk Management

SUMMARY: Plan, ID, manage, analyze risk.  Throughout the chapter you see the traditional approach of these activities done at specified times by a small group of people that the information gets put into a document versus Agile where it is a daily discussion by all and highly visible.

CONCEPT: 5 Core Risk Areas (DeMarco-Lister)

1. Intrinsic schedule flaw : Overly optimistic estimates : Shown quickly invalid by burndown charts.
2. Specification Breakdown : Building the wrong thing : One Product Owner
3. Scope Creep : Additional requirements :  Stopping points to discuss
4. Personnel Loss : People leave : Sustainable pace leads to higher morale
5. Productivity variance : Progress not what was estimated : Burndown charts

CONCEPT: Risk Response Planning (DeMarco-Lister)

1. Obstacles – Issues
2. Risks
   1. Mitigating
   2. Containing
   3. Evading
   4. Avoiding

---

Notes: Chapter 12: Procurement Management

SUMMARY:  Contract management does not change much between traditional and agile.

CONCEPT: Target Cost Contracts: Agree to cost, share overruns.

FOLLOW-UP: IEEE P1648 Recommended Practices for Establishing and Managing Software Development Efforts Using Agile Methods

---

Notes: Chapter 13: How will my responsibilities change?

SUMMARY: A chapter almost void of content.  It can be summarized by saying, do your best, play nicely with others, and when all else fails, do barely sufficient.

---

Notes: Chapter 14: How will I work with other teams who aren’t agile

SUMMARY: Another content free chapter.  Busy work for an agile PMO shop is you have one.

---

Notes: Chapter 15: How can a PMO Support Agile?

SUMMARY: Also content free.  Busy work for the PMO, if you have one

---

Notes: Chapter 16: Selling the benefits of Agile

SUMMARY:  Discussion on bringing Agile into an organization.  Very few new concepts or terms.  Lists challenges and solutions from different paoints of view: team, management, customer, etc

TERM: Architecture runway: Foundation to take off to the next iteration

---

Notes: Chapter 17: Common Mistakes

SUMMARY: Discusses some pitfalls and and solutions

---

Notes: Appendix A:

SUMMARY: Cliff Notes on Agile methodologies

CONCEPT: Scrum

• Iterative, incremental process for developing any product or managing any work.  It produces a potentially shippable set of functionality at the end of every iteration.
• Facilitates the emergence of product based on empirical learning
• 3 roles: product owner, delivery team, scrummaster
• Created by Jeff Suterland and Ken Schwaber based on Hirotaka Takeuchi and Ikujiro Nonaka: The New New Product Development Game

CONCEPT: XP

• 12 engineering practices
• Small teams, no more than 10, co-located
• Kent Beck created

CONCEPT: Dynamic Systems Development Method (DSDM)

• Pre-project, project lifecycle, post-project

CONCEPT: Crystal Methods

• Focus is people over process
• Frequent delivery, reflective improvement, close communication
• If a process helps people work together, then the team should keep it — and if it isn’t helping, they should discard it

CONCEPT: Lean Software Development

• Lean Manufacturing
• eliminate waste, amplifying learning, deciding as late as possible, delivering as fast as possible, empowering the team, building integrity in, seeing the whole

CONCEPT: Feature Driven Development

• Focus is the domain model
• Develop an overall model, build a list of features, plan by feature, design by feature, and build by feature
• <action> <result><object>
• Prefers individual code ownership and seeks to avoid refactoring by focusing on domain modeling

CONCEPT: Adaptive Systems Management

• Continuous adaptation to change as a result of learning
• Speculate-Collaborate-Learn

CONCEPT: Agile Unified Process

• Simplified RUP
• Inception, elaboration, construction, and transition