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
- Individuals over process
- Collaboration over negotiation
- Planning over following a plan
- Software over documentation
CONCEPT: 12 Guiding Principles
- Early and continuous delivery
- Deliver software frequently
- Daily interaction between business and developers
- Sustainable pace
- Build teams around self-motivated individuals
- Welcome change
- Face-to-face communication
- Working software is the primary means of progress
- Self-organizing teams
- 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
CONCEPT: Project Management Process groups
- Monitor and Control
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
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
- For (target customer)
- Who (statement of need)
- The (product name) is a (product category)
- That (key benefit)
- Unlike (primary competitive alternative)
- 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:
- Drive a formal project charter document | Visioning Meeting
- Formal documentation | “Barely Sufficient”
- Project Plan | Communicate the agile process and framework
- Separate Change Control Process | Integrate change control
- 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.
- 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
- 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
- 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
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]
- Red/Yellow/Green Indication
- Executive Brief
- Work in Progress
- Upcoming Activities
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)
- Intrinsic schedule flaw : Overly optimistic estimates : Shown quickly invalid by burndown charts.
- Specification Breakdown : Building the wrong thing : One Product Owner
- Scope Creep : Additional requirements : Stopping points to discuss
- Personnel Loss : People leave : Sustainable pace leads to higher morale
- Productivity variance : Progress not what was estimated : Burndown charts
CONCEPT: Risk Response Planning (DeMarco-Lister)
- Obstacles – Issues
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
- 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
- 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
CONCEPT: Agile Unified Process
- Simplified RUP
- Inception, elaboration, construction, and transition