Send the link below via email or IMCopy
Present to your audienceStart remote presentation
- Invited audience members will follow you as you navigate and present
- People invited to a presentation do not need a Prezi account
- This link expires 10 minutes after you close the presentation
- A maximum of 30 users can follow your presentation
- Learn more about this feature in our knowledge base article
Agile Project Management
Transcript of Agile Project Management
The Scrum Framework
Traditional vs. Agile
Introduction to Agile Project Management
Introduction to Agile
No flexibility when the market, business direction and budgets are always changing.
Nearly impossible to define all requirements before development commences (on an average project 35% of requirements change).
Fixed requirements encourage the impression they are all must-haves.
Focus is on business value and quality.
Scope, time and cost are managed constraints to deliver maximum value.
Requirements are flexible depending on the clients changing requirements.
Although quality is key, this can be flexible depending on priorities (e.g. a small iteration would have lower quality expectations).
Simplicity is essential.
Knowledge sharing and concise documentation are encouraged.
Visibility of key aspects of the process is helped by smaller, broken down development cycles.
The process must be made significantly visible for those responsible for the outcomes.
Every aspect of the process must be inspected frequently to detect unacceptable variances.
Requirements are reviewed with the customer regularly to ensure they are still relevant.
Adjustments must be made as quickly as possible to minimise further deviation.
Empirical Process Theory
Empiricism (i.e. learning by doing) is the theoretical foundation of Scrum.
The rules, roles, events and artifacts are mandatory in order to ensure inspection and adaptation are supported.
Planning & Estimating
Estimations at the start of the project are almost always wrong. The earlier these are given, the less likely they are to be accurate.
Agile planning is focused on the short term, rather than high level master plans.
Making changes is welcomed.
Designed to accommodate change and embrace new learning.
Feature driven, rather than activity driven (i.e. the time involved in developing a feature is estimated, rather than separate estimates for Design... build...)
Places business value to the forefront.
Activity: Animal Points
Assign Story Points to each of the following to establish their relative sizes.
Hint: Assign a value to the smallest first.
Debrief: Animal Points
Size is a holistic measure. Judgement can be based on:
Similarly a software feature's size could involve:
Lines of code
Estimation is more difficult, the bigger the item being investigated. Therefore it is better to break big pieces into smaller ones for estimation.
Traditional Requirements Management approaches rely on levels of management control. This generally involves;
Reams of requirements documentation
Majority of work done up front
Finalised and signed off prior to development commencing.
It is important to develop and agree a 'Business Value Model' with the Customer. Financial value is not necessarily the only measure. Other factors include:
Timeliness of delivery to market
Customers' external business relationships
Legal and regulatory compliance
The key difficulty occurs the Customer insist all features have equal priority.
The Agile approach says it is impossible to define all requirements up front, as software systems are complicated and liable to change.
Instead ‘barely-sufficient’ up-front requirements are produced (enough to start development). These then continuously evolve.
The rule in Agile is to estimate the size; then derive the plan. Estimating and planning are completely separate.
Size is measured in two ways:
Elapsed time (e.g. days) – Difficult to predict, varies depending on the individual’s skill set.
Abstract relative measures – Estimate the relative size of features and the effort to implement, no direct relationship to the clock.
Velocity is the measure of a team's rate of progress.
Often worked out by taking the average of sprints. E.g. if a team is, on average, able to implement seven 5-point user stories in a Sprint, then their velocity is 35.
Velocity can increase or decrease depending on factors within the team.
Unlike mass manufacturing which is well suited to master planning, software development is dominated by
Software development includes a
as knowledge is acquired throughout the life of a project.
Agile succeeds by
planning for learning
Criteria for judging 'good' stories
Start small and use success to generate momentum
The big bang approach is too disruptive
Use knowledge sharing / pair programming to develop skills as most individuals will initially be specialists.
Start using Agile tool sets / testing suites.
Planning for Learning
The more risk and uncertainty that a project fares, the more likely Agile methods are suitable to ensue success.
Benefits can be gained by simply bringing Agile into the Software Development function.
However changes to the top-down command processes can threaten management silos, causing tension in the wider organisation
Consider changes to the office layout
Review the traditional roles:
There is still a need for a Programme Office, however they will carry out slightly different work (e.g. creating burn down charts and road maps, managing mini-projects such as implementing the improvement backlog).
Make full use of the ScrumMaster’s role as an Agile coach.
Develop Product Owners – this skill is most likely to be in short supply.
Review use of fixed price contracts
Test driven development (TDD) is a well known Agile technique.
Products are driven by the tests they must pass.
Developers think of a required behaviour, and write a test for it.
They then write barely sufficient code to pass the test
Both the tests and the code are refractors as the requirements evolve - this results in emergent design.
Test Driven Development
Acceptance Test Driven Development (ATDD) includes customer-facing tests. Here the whole team collaboratively discuss acceptance criteria, with examples, and then distills them into a set of concrete acceptance tests before development begins.
This approach helps the team to ensure they have the same shared understanding of what it is that is actually building.
It will also help agree and grow the "Definition of Done".
ATDD integrates a number of ideas:
Workshops for clarifying requirements
Tests as requirements, requirements as tests.
Concurrent engineering (analysis, design, build, test etc. all done in tandem
Prevention, instead of detection, or errors.