1. Agile Project Management
Geoffrey Withnell
BAE Systems
Presented to ASQ511 Northern Virginia
September 14, 2016

2. Project Management
Initiating Planning Executing Monitoring and Controlling Closing

3. Waterfall Development

4. Manifesto for Agile software product Development
We are uncovering better ways of developing
software product by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software product over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.

5. Principles behind the Agile Manifesto
We follow these principles: Our highest priority is to satisfy the customer through early and continuous delivery of valuable software product. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. Deliver working software product frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

6. Principles behind the Agile Manifesto
Business people and developers must work
together daily throughout the project.
Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.
The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation.
Working software product is the primary measure of progress.

7. Principles behind the Agile Manifesto
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. Continuous attention to technical excellence and good design enhances agility. Simplicity--the art of maximizing the amount of work not done--is essential. The best architectures, requirements, and designs emerge from self-organizing teams. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

8. How Work Gets Done! Plan-Driven
Often phase-oriented, delivers results at the end
SDLC, Waterfall, RUP, PERT, Critical Chain, Prince2

9. How Work Gets Done! Agile with Planning
Planning and execution are epicyclic, repeated at different scales for nested time horizons 
Scrum, XP, CBPM 

10. How Work Gets Done! Agile without Planning
Agile without Planning
Processes unpredictable requests efficiently, for types of work where planning is not possible or required
Kanban

11. Understand the Adaptive Spectrum!
Certainty
Predictive
Predictive
processes
Emphasize efficiency
Perform poorly when
uncertainty is high
Plan Driven
Waterfall
SDLC
Adaptive processes
Emphasize adaptability to
rapid change
Enable detailed planning
Scrum XP
Reactive processes
Don’t require planning
Handle unpredictable work
well
Kanban
Uncertainty
Reactive

12. Iterative Developement

13. Deming Cycle

14. Scrum History
History
In 1986, Hirotaka Takeuchi and Ikujiro Nonaka described a new approach to commercial product development that would increase speed and flexibility, based on case studies from manufacturing firms in the automotive, computer, photocopier, and printer industries.[1] They called this the holistic or rugby approach, as the whole process is performed by one cross-functional team across multiple overlapping phases, where the scrum (or whole team) "tries to go the distance as a unit, passing the ball back and forth".[1]
In 1991, DeGrace and Stahl first referred to this as the scrum approach.[2] In the early 1990s, Ken Schwaber used such an approach at his company, Advanced Development Methods, and Jeff Sutherland, with John Scumniotales and Jeff McKenna, developed a similar approach at Easel Corporation, and were the first to refer to it using the single word Scrum.[3]

15. Requirements Management
Requirements Types
Architectural Requirements
Structural Requirements
Behavioral Requirements
Functional Requirements
Non-functional Requirements
Performance Requirements
Design Requirements
Derived Requirements
Allocated Requirements
Copy distributed to participants. DO NOT READ!!!!
Architectural requirements explain what has to be done by identifying the necessary system architecture of a system.
Structural requirements explain what has to be done by identifying the necessary structure of a system.
Behavioral requirements explain what has to be done by identifying the necessary behavior of a system.
Functional requirements explain what has to be done by identifying the necessary task, action or activity that must be accomplished. Functional requirements analysis will be used as the toplevel functions for functional analysis.[1]
Non-functional requirements are requirements that specify criteria that can be used to judge the operation of a system, rather than specific behaviors.
The extent to which a mission or function must be executed; generally measured in terms of quantity, quality, coverage, timeliness or readiness. During requirements analysis, performance (how well does it have to be done) requirements will be interactively developed across all identified functions based on system life cycle factors; and characterized in terms of the degree of certainty in their estimate, the degree of criticality to system success, and their relationship to other requirements.[1]
The “build to,” “code to,” and “buy to” requirements for products and “how to execute” requirements for processes expressed in technical data packages and technical manuals.[1]
Requirements that are implied or transformed from higher-level requirement. For example, a requirement for long range or high speed may result in a design requirement for low weight.[1]
A requirement that is established by dividing or otherwise allocating a high-level requirement into multiple lower-level requirements. Example: A 100-pound item that consists of two subsystems might result in weight requirements of 70 pounds and 30 pounds for the two lower-level items.[1]

16. Scrum Process
Requirements

17. User Stories
I want to use _______ to do ________ because ________. What do our customers want? Requirements should tie back to this. User stories create the feature list that becomes the Product Backlog. The portion of the Product Backlog that the team believes can be do in one iteration becomes the Sprint Backlog.

18. PMBOK Waterfall

19. Agile
Delivered Product

20. Manifesto for Agile Product Development
We are uncovering better ways of developing product by doing it and helping others do it. Through this
work we have come to value:
Individuals and interactions over processes and tools
Processes and tools that enable individuals and interactions are to be encouraged.
Working product over comprehensive documentation
Customers (and future developers) have a right to enough documentation to understand the product
Customer collaboration over contract negotiation
Collaboration is easier when the expectations for Agile Development are negotiated in the contract
Responding to change over following a plan
Responding to change is easier when one has planned how to do so.
We value the items on the left, and we value the items on the right as they contribute to the success of the
items on the left.

21. Agile Project Principles
We follow these principles:
Our highest priority is to satisfy the customer through early and continuous delivery of valuable product.
Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
Deliver working product frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

22. Agile Project Principles
Business people and developers must work together daily throughout the project.
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
Working product/process improvements are the primary measure of progress.

23. Agile Project Principles
Agile processes promote sustainable improvements. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Continuous attention to technical excellence and good design enhances agility.
Simplicity--the art of maximizing the amount of work not done--is essential.
The most effective improvements emerge from self-organizing teams.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly