Agile Certification Prep Notes

Origins of Agile: From Defense Contracting and Japanese Industry Evolution

Why Agile?

  • Differed change lists can be troublesome because they build up.
  • Locking the changes creates waste and devalues the project
  • Feature Driven Development as an agile approach can help resolve this problem.
  • Walter Schuhart: Continuous Improvement Cycle
    • Invented in the 1930’s: Plan Do Act Learn
  • Post WW2
    • US decimates Japan and uses them as a labour force
    • Japan suffers a number of setbacks over next 30 years with regards to manufacturing and quality and reacts by adopting new models – Schucart’s PDAL
    • Plan Do Act Learn -> Evolves into IID in 1950-70: Iterative Incremental Development
      1. Lean Software Development came from IID
      2. Critical Chain Methods: Eli Goldrath

IID is broken down into 5 unique models (Royce, 1970, Westcon).

  • Even Royce, the creator of the waterfall methodology is quoted as saying, “No significant project can be completed using this model”
  • He would say that the waterfall methodlogy can be effective it completed numerous times within a project lifecycle.

The first Agile Methods evolved out of IID during the early nineties.

  • RAD and DSDM (Rapid Application Development and Dynamic System Development Model)

 

 

Aligning Agile to Corporate Governance

CorpGovernance

Agile Requirements Gathering

  • Do detailed requirements AS LATE AS POSSIBLE
  • JIT documentation (Just In Time)
  • Requirements are documented in Backlogs
    • Project Backlog
      1. Is the Scope of the Project NOT THE PRODUCT BACKLOG
    • Product/Project Backlog
      1. Is not the scope of the project. There are things there that will not be implemented!
    • Sprint/Iteraton Backlog
      1. Contains tasks similar to the WBS

Agile Documentation

Reasons for Documentation

  • To clarify ideas
  • To communicate something to another person in another place
  • To communicate something to another person in the future
  • Stakeholders require it

Three Principles of Agile Documentation

  1. Don’t document if you don’t have to
    • Challenge the need to document
    • Estimate the cost of documentation and communicate it to the stakeholders
  1. Document as informally as is acceptable
    1. Think about the consumer first
      1. Information needs
      2. Familiarity with the content
      3. Level of expertise of subject
      4. Position within the organization
    2. Are there legal requirements?
    3. How informal is acceptable while satisfying requirements
  2. Procrastinate, procrastinate, procrastinate so you don’t document until you need to.

Early documentation in the project introduces risk

  • Not everyone is on the same page
  • As the project progresses there is more alignment of ideas

Variable Scope with Fixed Budgets and Schedule

Planning makes all the difference -> How you Plan not the amount of planning!

The best plans allow for what-if decisions.

Traditional planning fails in high change environments because…

  • Feature Usage Within Deployed Applications
    • *Statistics show that up to 50% of features are never used in the final output
    • Example: MS Excel has over 400 calculation features, but 99.9% only use the top 10.
  • Undesired or low value features create waste and are highly costly.
  • Traditional planning is based on tasks and do not leave room for lessons learned within the project plan
    • If you learn lessons during the project that tell you the tasks are no longer effective, then what?
    • Task-based plans get so complex they are difficult to update/change
    • Parkinsons’s law
      1. Tasks rarely get completed rarely
    • **Multi-tasking more than two tasks have been shown to decrease efficiency radically, by up to 50%
      1. Multi-tasking can cause risk in the project
    • A task that includes contingency rarely is finished early. The person doing the task soaks up all the contingency to do the task.
  • Delays in task completion roll apply the entire schedule
  • Features in traditional planning are not typically developed by priority

*Source: Chaos Report V3, www.standishgroup.com

**Source: K. Clark and S. Wheelwright, Managing New Product and Process Development: Text and Cases. The Free Press, 1993

 

Contracts: Fixed Price Variable Scope

  • Divide the product backlog on the must haves and nice to haves
    • Must have features are deep-dived and estimated, even managed using waterfall methods: Manadatory Scope with a defined budget.
    • Other items are Variable Scope
    • E.g. 1 year contract for $1.2 million
      1. Mandatory Scope is planned for 6 months
      2. Variable Scope is planned for 6, one month sprints and is based on the product backlog that has the story points assigned
        • At the beginning of each sprint, the client signs a work order for x number of story points
        • Team builds out the features based on priority
        • Client is allowed to trade out features at will as long as the story point count remains the same.
        • If they want more features than what is in 6 months, then sign another work order.

Change Control and Management

  • Formal change requests are required for…
    • Adding or removing an iteration
    • Changing resources/schedules/budgets/feature lists
    • Changes that change the business case objectives
    • Descoping
    • Usually a c.r. is generated at the end of an interation that includes all changes and an updated release plan.

Financial Tracking

  • Using velocity can be used in a similar way as Earned Value. The calculations are made differently but it provides the same kind of measurement

How to Plan Agile

  • The activity of planning is what is important, not the artifact that is the ‘project plan’
  • The Project Plan document is going t change, so design them so they can be updated easily and support change
  • Plan using a multi-diciplinary team
  • Plan throughout the project, not just at the beginning

Types of Agile Plans

  • Release Plan
    • High-level timing of deliverables used to communicate to Business Owners and the team.
    • Does not include any tasks whatsoever.
    • Does include timelines, number of sprints etc.
    • Includes estimates
  • Iteration Plans
    • Task based plan that includes tasks for the team. This is similar to a mini work breakdown structure that can be applied to a Sprint.
    • Includes estimates
  • Day Plans
    • Informal plan that is established during the morning SCRUM

Release Plans and Product Backlog Creation

  • Includes number of iterations and their start and end dates
  • Release start and end dates, and the features that are going to be in the iterations
  • Includes Milestones
  • Includes relationships with other projects
  • Includes initial stories and features for each release (not tasks)
  • How to:
    • Organize the Product Backlog into Releases
    • Lobby the sponsor to address higher risk features/stories first
    • Identify the non-functional requirements and add them to a constraints document
      1. Distribute some of the constraints throughout the Project Backlog in order to ensure checks and balances.
    • Get approval from the Sponsor
    • Estimate the project backlog using story points and include the people doing the work, don’t include people who are not involved in the work.
      1. Ideal Days
        • Estimates can be made using ideal days, but be careful there is no such thing as an ‘ideal day’
        • Estimating in days is slower
        • Estimating in days takes more analysis
        • Easier to explain to outsiders but there is a risk of comparing ideal days to calendar days.
        • My ideal day is different than another person’s perception of an ideal day.
      2. Story Points
        • A pure measure of size
        • Help drives cross-functional behavior
        • Faster than estimating ideal days
        • Estimates do not degrade over time
        • Allow people who are not doing the work to provide accurate assessments of the work
    • Complexity = Effort + Risk
      1. Add risk to the plan to identify: Targeted contingencies for known and identifiable risks
      2. Keep the original estimation excluding risk in order to remove it if the risk is eliminated

Iteration Planning and Team Velocity

  • New teams to agile require longer iterations
  • As the team gains experience, the iteration can be smaller
  • Iteration Lengths
    • Common iteration is 2-4 weeks
    • No magic number but consistency is important
    • Factors to consider include
      1. Nature of the work and the need for feedback
      2. Size of features
      3. Team experience level
      4. Available automation tools

Estimating Velocity

  • Velocity is the number of points per iteration that can be completed
    • Accuracy of velocity in planning stage is not as critical as consistency
    • Consistent estimates measuring velocity over the first few iterations will allow us to prepare a more reliable schedule
  • Simple Method (How many points can my team do during an iteration)
    • We know the iteration length: 2 weeks
    • We know the team: 4 full time equivalents
    • Steps
      1. Identify Capacity: (4 people X 10 days) X (8 hrs per day X 80% Efficiency)
        • = 250 hrs available in a two week sprint.
      2. Select a handful of backlog items that represent the range of work that is involved in the project.
        • Write down the backlog item numbers and have the b.a. do a deep dive into the requirements of the items in order to get a very granual estimate. Consider Design, Build, Test phases to get the total number of hours.
      3. Select the best combination of the estimated backlog items in order to fill the capacity that is available to the iteration (plus – minus 10%).
        • Try to get at least three stories
      4. Gather the story points for all of the backlog
        • Add the storypoints together in order to get the velocity
      5. Double check the math using iteration #1 as an example
        • The first iteration is always the most challenging, so the velocity may not match up. If it doesn’t match up, then you should break it into multiple sprints; choosing the best combination.
  • Advanced Method (In book) is used when you don’t know your resources yet.
    • Look at the most constrained resource role and follow steps 2 based on their capacity
      1. E.g. 50% of a designer

Schedule/Release Planning

  • Involve the team in the exercise
  • Once you have the velocity, you can carve out iterations from the project backlog
  • Always keep [at least] one iteration at the end so there is a buffer
  • Map the iterations out on a calendar and double check the storypoints per iterationm
    • If it is on a large calendar or whiteboard, you can write feature and storypoints on a sticky-note so it can easily be manipulated
  • Check resource calendars and adjust features and storypoints per iteration based on the vacation/holiday schedules of the team
  • Consider the dependencies
  • Identify milestones and then send the team home
  • Stakeholder Management
    • Involve the sponsor and other stakeholders to ratify the plan
    • They can move sticky notes into another iteration as long as they replace it with another one.

Lessons Learned

  • What did we do well?
  • How can we improve?
  • Where did we screw up?

Iteration Planning

  • Do a deep dive for requirements and testing for the first iteration during the release planning stage. This way, the developers can be coding and the q.a. and s.a. team can be working on the very next iteration.
  • This is helpful in siloed organizations that use distinct functional groups.
  • Apply a waterfall method within the sprint and define the critical path

Cost Planning

  • Once you know the cost of one iteration (as described in determining velocity) you can calculate the labour costs for the entire project

Exam Prep

Defined Processes:

  • Processes that we are very familiar with, highly effective if we know the requirements, goals etc.
  • Chances of success in high change projects is lower because of moving targets

Empirical: Less planning upfront, more frequent checkpoints and feedback so client/sponsor can direct the project to stay on target in the face of changing requirements.

Terminology

  • Project Backlog vs Product Backlog
    1. Product Backlog is the life plan of the product
    2. Project Backlog is the scope of a project

 

  • Backlog Grooming: The process of prioritizing the product backlog
    1. Columns:
      1. Business Priority (sponsor)
      2. Dependency (team)
      3. Estimates (team)
      4. Complexity (team)
  • Shadow Backlog: list of features that are not ready to estimate but prioritized, once estimated the feature will be added to the main Project Backlog
  • Defect Backlog: list of defects, once estimated and prioritized they move to the Project Backlog
  • Sprint Defect Backlog: Grows as the sprint’s defects are applied and then shrinks down to nothing as the sprint is completed. Any remaining defects get moved to the main defect backlog and may possibly be added to the project backlog.
  • Use Case: Defines a business need or problem
  • User Story: Describes a step in the solution to the problem
  • Feature: Describes a step in the solution to the problem
  • Technical Debt: A term that describes all of the deferred defects and items to refactor.

SCRUM:

At the end of each sprint:

  • Did we get it right?
  • Is this still what you need?

At the Beginning of each Day, SCRUM Meeting: Three Questions

  • What did you do yesterday / Were there any issue completing your work yesterday?
  • What are you doing today?
  • What are the barriers for this Iteration or the Project?
    1. Document issues in the issue log if they can’t be resolved immediately

Estimating:

  • Story points/Complexity Points
  • Ideal Days (a full one person day)

XTREME Programming: 12 Principles

Requirements Gathering   

What will you use to measure success of features? What is the definition of done?

Collective Ownership  Anyone can work on anything and update anything
Consistent Coding Standards  Tools can be used to enforce consistent standards
Refactoring Continuous refactoring until the code is released. Any can refactor anything.
Continuous Integration Enforces standards and alignment of varied development practices. Tools can be used to check-in, build and keep integration tight.
Commitments and Measurements involve the entire team The team succeeds as a team and is measured as a team. This enforces the
Design Metaphor The high-level design that is done in the planning phase of a project
Test Driven Development Developments write the unit test cases before building and define the definition of done
Paired Programming Almost eliminates the cost of change within a project.Best applied to the most critical areas of a project.
Customer tests the work
Small Releases Build small and often

 

FDD: Featured Driven Development

  1. Develop an overall model (requirements)
  2. Build a feature list (product backlog)
  3. Plan by feature (Business Case)
  4. Design/Build/Test by feature
  5. Iteration based: 2 weeks or less

DSDM: Dynamic Systems Development Method

  • High Level Requirements and Business Case
  • Ratify cases by prototyping
  • Build the rest
  • Deploy
  • Review

Lean – Principles

  1. Customer satisfaction is the highest priority
  2. Provide best value for money
  3. Active customer participation breeds success
  4. Every project is a team effort
  5. Everything is changeable
  6. Domain solutions, not point solutions
  7. Complete, do not construct
  8. 80% today instead of 100% tomorrow
  9. Minimalism is essential
  10. Let needs determine technology
  11. Product growth is feature growth, not size growth
  12. Never push Lean Development beyond its limits

For PMI-ACP Exam review the Lean Philosophy

Earned Value Management

  • SPI and CPI is used to determine EVM and this leads to being able to forecast budget and schedule early.
  • EVM is deterministic.

Storming Forming Norming and Performing – Performing should happen at 20% into the project.

PMI-ACP Exam Particulars:

  • Review XTreme programming
  • Review Lean theory and practice

Systems Development Approaches

Three step decision process to decide what type of methodology to use

  1. Do I need lots of feedback for success?
  2. What is the delivery strategy? Big bang or phased.
  3. Do I need enhanced quality or not?

 

  • Waterfall
    1. Low quality approach, requires a team with exceptionally high skill.
    2. Problematic because there is little opportunity for feedback
    3. A big bang approach because business value is delivered at the end.
  • Iterative (Feedback)
    1. A big bang approach
    2. Takes the whole solution and
    3. like waterfall but with additional points of feedback)
    4. Sooner opportunities for feedback
    5. Like waterfall but overlapping phases, still considered low quality with delayed testing to the end of the project.
    6. Design and Build can be done at the same time.
    7. User Centric Design in order to model the end result
    8. Delayed sign-off
    9. Stronger p.m. resources required. Higher complexity and risk than waterfall
  • Incremental (Prioritization)
    1. Prioritization to realize benefits sooner
    2. Often used in Program Approach
    3. Finish A before B, but when building B, test A.
    4. Four primary benefits
    5. Phased delivery of value: Faster ROI
    6. Potential to efficiently cut scope to save time and money
    7. Dramatically improved quality through continuous testing and regression testing
    8. Reduced Risk, “Early reduction of technical and design risk”
    9. Secondary Benefits
      1. Visibility in project status
      2. Resource leveling
      3. Moral is higher due to higher rewards through achieving success
  • IID/Agile (Iterative and Incremental)
    1. A lightweight version of IID

Agile Manifesto: 2001

IID becomes: Agile which has 4-5 guiding principles

  • Individuals and Interactions over Processes and Tools
    1. Good teams create good projects
  • Working software over Comprehensive Documentation
    1. How to measure success – customer focus
  • Customer Collaboration over Contract Negotiation
    1. Keep the relationship with the client
  • Responding to Change over Following a Plan
    1. There is no perfect plan, so don’t stick to it

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

 

Take-Aways

  • Concept fo Change Control (CCB) is false. Change Management is possible.
  • Bi-Modal I.T. (Gardner) states that companies need two models
    1. Waterfall or Agile
  • Agile Applications
    1. There are four significant models that can be applied.
  • Agile can proceed with a ROM Estimate but if a hard estimate is required then a waterfall method should be used.
  • Agile requires more planning hours that are spread across the lifespan of the project
  • Barry Banes: Cost of Change Curve:
    1. Agile testing budgets are higher but they save cost of change
    2. Reduces risk and provides higher quality
  • OpenUP: Free Agile Methodology. Eclipse.org
    1. CIBC methodology is based on OpenUP
  • SCRUM: Origins in 1986: “The New New Product Game”
    1. Harvard Business Review
    2. Extreme SCRUM on Amazon: Scaling Scrum to Enterprise level
      1. Using Scrum of Scrum

Adopting Agile: Stealth Methodology Adoption (Book by Kevin Aguanno)

  • Adopt techniques into your existing methods rather than adopting new methods
  • The way you describe them makes all the difference
  • Think of the techniques as tools you use to fix specific problems